Date: Fri, 28 Jun 2013 18:15:51 -0700 From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <jinmei@isc.org> To: "Mark Felder" <feld@feld.me> Cc: freebsd-net@freebsd.org Subject: Re: Making net.inet6.ip6.v6only=0 default Message-ID: <m2ppv5k988.wl%jinmei@isc.org> In-Reply-To: <op.wzet4vr234t2sn@tech304.office.supranet.net> References: <op.wzet4vr234t2sn@tech304.office.supranet.net>
next in thread | previous in thread | raw e-mail | index | archive | help
At Fri, 28 Jun 2013 17:30:21 -0500, "Mark Felder" <feld@feld.me> wrote: > Later after a bit more digging and discussion I've come to learn that the So, you've gone through the literature on this topic including http://tools.ietf.org/html/draft-cmetz-v6ops-v4mapped-api-harmful-01 ? > security aspect may simply be "unexpected behavior -- the binding to ipv6 > sockets and endusers not realizing it, thus creating a security hole for > environments with only an ipv4 firewall". > > We ship a dual stack firewall by default, and now since FreeBSD 9 we have > the rc.conf setting ipv6_activate_all_interfaces="YES" which seems > sufficient to mitigate this; the user would have to know they're enabling > ipv6 and what its consequences could be. I'm afraid it's a bit too optimistic. We also need to rely on either application programmers being careful enough to write code like this: - sin6 = (struct sockaddr_in6 *) sa; - inet_ntop( AF_INET6, (void *) sin6->sin6_addr.s6_addr, addr, sizeof - addr ); - /* If it's an IPv4 mapped address, drop the leading '::ffff:' */ - if ( IN6_IS_ADDR_V4MAPPED( &(sin6->sin6_addr) ) ) - strncpy( wrapper_addr, addr + 7, sizeof wrapper_addr ); - /* otherwise surround the address with braces to hopefully match - what tcp wrapper expects */ - else sprintf( wrapper_addr, "%s", addr ); - } (taken from the FreeBSD port patch for rwhois) so a naive user can safely write a rule like deny 192.0.2.1 allow all or the user is careful enough to write ACLs like: deny 192.0.2.1 deny ::ffff:192.0.2.1 allow all In theory, people (either or both of programmers and users) can make it safe. In practice, I personally think it's sufficiently error prone. Admittedly, however, different people may have difference senses on the severity of this point. And (in my understanding) that's why relevant people failed to get a clear consensus at the time they discussed this API. In the end the "standard" default behavior was documented with leaving lots of controversy. Unfortunately, this also left portability problems. It's not only for FreeBSD; as far as I know NetBSD still keeps the same default as FreeBSD, and, as far as I know OpenBSD still even refuses to allow this usage of IPv4-mapped IPv6 addresses. And, I suspect some of them do so "religiously", and will never change the behavior no matter what the "standard" documentations state. So... > So I guess the question is: what do we do? It looks like we're in > violation of both RFC 3493, Section 5.3 and POSIX 2008, Volume 2, Section > 2.10.20*. ...aside from what FreeBSD should do for ip6.v6only, I personally believe that realistically this issue should be resolved at the application side, i.e., explicitly set the IPV6_V6ONLY socket option to 1 and use both AF_INET (for IPv4) and AF_INET6 (for IPv6, and only for IPv6) sockets. As far as I know this is the most portable behavior. Regarding the rwhois case, I'd first suggest updating the patch with this socket option setting. Hopefully it can be accepted by the upstream because it's most portable. If they still reject it because "it's against the standard" (and even if it's less portable in reality), my next suggestion is to explicitly set the IPV6_V6ONLY socket option to 0. This setting is "redundant" in the sense of standard purity, but hopefully less controversial for those preferring the standard compliance as it only requires a small change and will make it still more portable. Going back to the question of what FreeBSD should do for ip6.v6only: Personally, I'd still suggest keeping the same default because I agree this behavior is sufficiently safer (as noted above) *and* there'll be portability issues anyway (OSes using the different default "religiously" will never change it). But I also understand the argument that standard compliance is more important than debatable safety. In either case, it would help if we provide detailed discussion for the description of this sysctl knob. --- JINMEI, Tatuya Internet Systems Consortium, Inc.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m2ppv5k988.wl%jinmei>