netdev - 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: <20140306070250.GC26307@order.stressinduktion.org>
Date:	Thu, 6 Mar 2014 08:02:50 +0100
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	Simon Schneider <simon-schneider@....net>
Cc:	netdev@...r.kernel.org
Subject: 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