Re: [Sks-devel] IPv4 vs. IPv6? -- Reconciliation attempt from unauthorized host, but host is authorized

[Phil Pennock]

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