From owner-freebsd-net@freebsd.org Sun Apr 5 19:57:48 2020 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 90C94269158 for ; Sun, 5 Apr 2020 19:57:48 +0000 (UTC) (envelope-from fernando@gont.com.ar) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48wPbT1TB7z4Vfw for ; Sun, 5 Apr 2020 19:57:39 +0000 (UTC) (envelope-from fernando@gont.com.ar) Received: from [192.168.0.10] (unknown [181.45.84.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 0A3A580977; Sun, 5 Apr 2020 21:57:28 +0200 (CEST) Subject: Re: Revisiting FreeBSD-SA-08:10.nd6 (or: avoiding IPv6 pain) To: =?UTF-8?Q?Dennis_K=c3=b6gel?= , freebsd-net@freebsd.org References: <523BA6CF-C2C3-4E55-B81C-CB8816E56DDE@neveragain.de> From: Fernando Gont Message-ID: <327cf281-ca39-7c2f-3545-0edd3b40808f@gont.com.ar> Date: Sun, 5 Apr 2020 16:28:32 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <523BA6CF-C2C3-4E55-B81C-CB8816E56DDE@neveragain.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 48wPbT1TB7z4Vfw X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of fernando@gont.com.ar designates 91.239.96.14 as permitted sender) smtp.mailfrom=fernando@gont.com.ar X-Spamd-Result: default: False [-5.80 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[gont.com.ar]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[14.96.239.91.list.dnswl.org : 127.0.10.0]; IP_SCORE(-3.50)[ip: (-9.28), ipnet: 91.239.96.0/23(-4.64), asn: 198644(-3.61), country: SI(0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:198644, ipnet:91.239.96.0/23, country:SI]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2020 19:57:48 -0000 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