Date: Sun, 5 Apr 2020 16:28:32 -0300 From: Fernando Gont <fernando@gont.com.ar> To: =?UTF-8?Q?Dennis_K=c3=b6gel?= <dk@neveragain.de>, freebsd-net@freebsd.org Subject: Re: Revisiting FreeBSD-SA-08:10.nd6 (or: avoiding IPv6 pain) Message-ID: <327cf281-ca39-7c2f-3545-0edd3b40808f@gont.com.ar> In-Reply-To: <523BA6CF-C2C3-4E55-B81C-CB8816E56DDE@neveragain.de> References: <523BA6CF-C2C3-4E55-B81C-CB8816E56DDE@neveragain.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello, FWIW, I just skimmed through this email. The problem here seems to be this: ND messages are not routable. So Solictations must come from an address that is on-line. A link-local address is of link, of course. Or, if e.g. a global address is employed, and the nodes knos it's on-link (e.g. there was a PIO with th L flag set), then that's also okay. However, when a packet from an "off-link" network is employed, the sending node has no way of knowing where to send the packet, unless it simply swaps the src and dst mac addresses, and uses the source address of the packet as the destination addresses. As such, it would seem to me it would be okay to drop the packet... BUt... of course, if there's a buggy box and responding as described solves the problem.... Thanks, Fernando On 4/3/20 17:10, Dennis Kögel wrote: > Hi, > > I‘ve spent quite some time debugging weird intermittent IPv6 connectivity issues over the last few days. > > It turned out that net.inet6.icmp6.nd6_onlink_ns_rfc4861=1 fixed those problems. > > This flag was introduced in a 2008 Security Advisory, because "non-neighbors" could abuse Neighbor Discovery to potentially cause denial-of-service situations. > In my situation it caused valid Neighbor Solicitation packets from my provider to be silently dropped, making the connection effectively unusable. > > In the comments in nd6_nbr.c[0] it says that IETF discussion on this issue is still ongoing. > > In the meantime, 12 years have passed. There are several reports on similar connection issues over the years, each time due to this default setting. > > An OpenBSD discussion from 2013 [1] explains the effects in depth, but ultimately ends up nowhere. The key takeaway from this thread is RFC 4861 sect. 7.2.2, which states that any address "should" be used as source. > > Dragonfly decided to disable this protection by default in 2018 [2]. > > I‘d propose to do the same in FreeBSD, given that the issue 1) is rather hard to debug 2) breaks interop with RFC-compliant setups again and again and 3) I cannot see any harm here (Solicitation can only originate from the rather trusted local network, i.e. from a neighbor). > > What do you think? Am I missing something? > > Thanks, > - D. > > > [0]: https://github.com/freebsd/freebsd/blob/master/sys/netinet6/nd6_nbr.c#L188 > > [1]: http://openbsd-archive.7691.n7.nabble.com/OpenBSD-ignoring-RFC-compliant-IPv6-neighbor-solicitation-td223348.html > > [2]: https://www.mail-archive.com/commits@dragonflybsd.org/msg14496.html > > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?327cf281-ca39-7c2f-3545-0edd3b40808f>