netdev - Aw: Re: Link-local source IPv6 address in unicast Neighbor Solicitation towards global destination

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <trinity-e0e97e3d-2c6a-4f81-bd27-f7151a67b303-1394097503168@3capp-gmx-bs05>
Date:	Thu, 6 Mar 2014 10:18:23 +0100
From:	"Simon Schneider" <simon-schneider@....net>
To:	"Hannes Frederic Sowa" <hannes@...essinduktion.org>
Cc:	netdev@...r.kernel.org
Subject: Aw: Re: Link-local source IPv6 address in unicast Neighbor
 Solicitation towards global destination

Hi Hannes,
thanks, checking that would be good.

Another point here (probably a bit academic): without link-local address on the interface (just the global one), the unicast NS for NUD is not sent at all.

The neighbor cache entry is in DELAY state for some time, unicast NS is not sent, then the entry is moved to FAILED rather quickly.

best regards, Simon


> Gesendet: Donnerstag, 06. März 2014 um 08:02 Uhr
> Von: "Hannes Frederic Sowa" <hannes@...essinduktion.org>
> An: "Simon Schneider" <simon-schneider@....net>
> Cc: netdev@...r.kernel.org
> Betreff: Re: Link-local source IPv6 address in unicast Neighbor Solicitation towards global destination
>
> Hi Simon!
> 
> On Wed, Mar 05, 2014 at 03:00:29PM +0100, Simon Schneider wrote:
> > I noticed something I don't quite understand in a very basic scenario.
> > 
> > Two machines connected to each other, say A and B.
> > 
> > Both have their automatically configured link-local IPv6 addresses on the interface, plus one global IPv6 interface address.
> > 
> > A pings the global address of B.
> > 
> > What happens:
> > 1) Address resolution from A to B. B creates a neighbor cache entry for A's address in STALE state. Since B sends Neighbor Advertisement back to A, the entry moves to DELAY and the delay_first_probe_time timer (5s) is started.
> > 
> > 2) After successful resolution, echo request / reply are exchanged.
> > 
> > 3) After delay_first_probe_time at B expires, B transmits a unicast Neighbor Solicitation to A's global address (reachability check). 
> > 
> > All good so far.
> > 
> > However, although the destination address of the NS has global scope, B uses its link-local address as source.
> > 
> > I don't think this is correct. According to the source address selection rules in RFC3484, chapter 5, Rule 2 should match and B's global interface address should be used as source.
> 
> Plain RFC3484 cannot be used to select source address for NS, as we
> must be sure to select an IPv6 address belonging to the interface and
> RFC3484 does not gurantee that (Rule 2 would filter out link-local address
> in case of global scope while only Rule 5 later would prefer to select
> an address belonging to the interface). It would be possible to try RFC3484
> source selection, check if the address belongs to the interface and fallback
> to LL address in case it does not. I'll test if it improves things.
> 
> > In this simple example, it leads to a sequence of further reachability checks for the link-local addresses of A and B. I don't think these are necessary and they could be avoided if B had used its global interface address as source in the first NS.
> > 
> > Observed under kernel version 3.11.
> > 
> > Is this a bug or do I miss something?
> 
> Always using link-local address in this scenario is in my opinion totally
> valid but maybe not the best choice.
> 
> Greetings,
> 
>   Hannes
> 
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html