On 2013-12-02 at 01:30 -0500, Daniel Kahn Gillmor wrote: > On 11/27/2013 04:30 PM, Phil Pennock wrote: > > If you're free to do so on this box, you can change the global state > > with the `net.ipv6.bindv6only` sysctl; set it to 1 from 0. > > hm, this seems like it would have cascading effects over other listening > services on this machine, including the reverse proxy, whose > configuration i would need to change if i was to diverge from the system > defaults.
Thus "free to do so" -- apparently, you're not. > well, i'm certainly fine with depending on ocaml 3.11 for modern > versions of sks. But it seems like there are two approaches that could > be taken to fix it, and only one of them ought to rely on IPV6_V6ONLY: > > a) sks could set IPV6_V6ONLY on all listening sockets, and require the > administrators to explicitly list IPv4 addresses differently from IPv6 > addresses, or No, the point of IPV6_V6ONLY is that you don't need to explicitly list all addresses. If you do explicitly list addresses, then you don't have :: listening, so you don't have IPv4-mapped IPv6 addresses appearing. > b) sks could simply realize that ::ffff:XX.YY.ZZ.WW is the same as > XX.YY.ZZ.WW when doing comparison testing for IP-address-based > authorization. This seems like it would be a change in same_inet_addr > in membership.ml, and wouldn't require either system re-configuration, > service re-configuration, or new versioned dependencies. > > doesn't (b) seem like the more conservative approach to resolve the > concern raised here for dual-stack hosts? or are there other reasons > why (a) might be necessary? It encodes a lot of protocol-specific knowledge and canonicalisation. The basic issue is that there are sockets which are multi-protocol, which was probably a design mistake. The options are: 1. handle multi-protocol, try to unwind compatibility layers and fudge things about later. 2. bind a socket per address family, ensure the address families remain distinct, let people run with "defaults", of "0.0.0.0 and ::". 3. be broken by default and require people to have manual configuration to fix it, but it is at least then really "fixed", by being worked around. SKS currently uses approach 3. You have to explicitly configure the addresses, to make things work. No maintstream software is this broken, but it does have the advantage of ensuring SKS knows which source IP address to use, so on systems with IPv6 privacy extensions the recon source filtering can still work. Your (b) corresponds to approach 1. Eww, no. The normal software approach for robust production-grade applications is 2. The only downside is that it assumes that source IP addresses are equivalent, which will break recon filtering if there's a system with multiple IP addresses. That's the downside of using source IP address as a security mechanism in a world of IPv6, where the designers assumed people would have outgrown that. It's also not a reason to keep things as they are, since people clearly are running with the defaults, and on systems which don't set v6only on IPv6-accepting sockets, it appears to work fine. So we have _some_ systems being pushed into explicit configuration, based on local system defaults, and _all_ systems requiring explicit address configuration, per recon and the line of argument which says you must configure addresses manually. I do address this in the Peering document, I do state "You should explicitly set all public addresses used" and the document has (for a long time now) explicitly warned about ::ffff:0:0/96 addresses. IMO, SKS should either set v6only on the accepting sockets explicitly, or remove the defaults and treat :: and 0.0.0.0 as a configuration error, since the status quo uses inconsistent logic to defend its stance. On 2013-12-03 at 12:11 +0100, Karl Schmitz wrote: > maybe you should suggest adding the IPv4 compatibility DNS record (i.e., > *sks-peer AAAA ::ffff:94.142.241.93*) to the administrator of > sks-peer.spodhuis.org. Not going to happen. The idea of AAAA is to return an IPv6 address which can be used over an IPv6 connection. The use of an IPv6 socket to handle an IPv4 connection is a local implementation detail. I don't know why <http://tools.ietf.org/html/draft-itojun-v6ops-v4mapped-harmful-02> never made any more progress than it did, but the points (as was normal, for itojun (RIP)) were valid. -Phil _______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel