sks-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sks-devel] IPv4 vs. IPv6? -- Reconciliation attempt from unauthoriz


From: Karl Schmitz
Subject: Re: [Sks-devel] IPv4 vs. IPv6? -- Reconciliation attempt from unauthorized host, but host is authorized
Date: Tue, 03 Dec 2013 12:11:34 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10

Hi Daniel and Phil,

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.

To see if that'll work out, try adding an equivalent record to your /etc/hosts temporarily.

Just my two cents,

Karl

Am 02.12.2013 07:30, schrieb 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



_______________________________________________
Sks-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/sks-devel

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]