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

[Daniel Kahn Gillmor]

On 11/27/2013 04:30 PM, Phil Pennock wrote:
> On 2013-11-27 at 12:57 -0500, Daniel Kahn Gillmor wrote:
>> i'm running sks 1.1.4 on Debian GNU/Linux, wheezy, amd64 (x86_64)
>> platform.
>>
>> I see the following situation in the logs of the recon process (this is
>> just an example, it seems to happen to all my IPv4 peers):
>>
>> 2013-11-27 12:37:17 address for sks-peer.spodhuis.org:11370 changed from [] 
>> to [<ADDR_INET [2a02:898:31:0:48:4558:73:6b73]:11370>, <ADDR_INET 
>> [94.142.241.93]:11370>]
>> 2013-11-27 12:37:17 Reconciliation attempt from unauthorized host <ADDR_INET 
>> [::ffff:94.142.241.93]:54518>.  Ignoring
> 
> This to me smells of a binding issue, where your v6 sockets are
> accepting IPv4 addresses but SKS isn't handling that pattern.

yep, i think that's probably the case.

> 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.

> If my recollection is accurate, when we were discussing IPv6 in SKS and
> I provided my patches and commented upon Kim's (the ones which went in),
> the O'Caml runtime did not support accessing the `setsockopt(2)` call
> needed to tune this on a per-socket basis.  You're looking for the
> `IPV6_V6ONLY` socket option at `IPPROTO_IPV6` level.
> 
> google(SKS IPV6_V6ONLY) yields:
>   https://lists.nongnu.org/archive/html/sks-devel/2009-03/msg00170.html
> 
> So, if I was right in 2009, then with O'Caml 3.11 you can fix this.

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

 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?

        --dkg

signature.asc
Description: OpenPGP digital signature