Re: [Sks-devel] IPv4 vs. IPv6? -- Reconciliation attempt from unauthorized host, but host is authorized
Hi Daniel and Phil, maybe you should suggest adding the IPv4 compatibility DNS record (i.e., *sks-peer :::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 [:::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 :::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 Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] IPv4 vs. IPv6? -- Reconciliation attempt from unauthorized host, but host is authorized
Daniel Kahn Gillmor writes: 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 But this *is* the approach that SKS uses, except that it does not have to set IPV6_V6ONLY. Like I wrote in a previous answer, SKS requires the administrator to list all addresses, IPv4 and IPv6. As an alternative you can use the hostname. But I do not recommend this as you then have to be sure that all your DNS system is working fine at SKS startup time. b) sks could simply realize that :::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. One of the first pass at IPv6 was done like that. But it lead to unneeded complexity. The final SKS code is network protocol agnostic. It does not include any IPv6 specificity. Is this b) functionnality really desirable? Note that there is no real operational problem to fix in SKS with regard to IPv6. It works fine for many (all?) people. The only annoyance I know is that you cannot use the catchall :: address on systems that provide IPv4-mapped addresses by default, like Linux. If you still have problem with SKS and IPv6 please provide us with your sksconf. -- Kim Minh ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] IPv4 vs. IPv6? -- Reconciliation attempt from unauthorized host, but host is authorized
On 12/03/2013 06:11 AM, Karl Schmitz wrote: maybe you should suggest adding the IPv4 compatibility DNS record (i.e., *sks-peer :::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. I tested this by adding duplicate records to /etc/hosts on zimmermann.mayfirst.org for a couple of IPv4-only keyservers that zimmermann is peering with. even after touching /etc/sks/membership, the sks recon process did not pick up the new addresses, but it did pick them up when i restarted sks recon. This does appear to work for me. I included both the normal IPv4 and the IPv6-translated addresses for the hosts in question. for example: 204.13.164.120 keys.indymedia.org :::204.13.164.120 keys.indymedia.org the downside to this approach seems to be that i can't actually connect to those peers on the :::W.X.Y.Z address, since they do not have an IPv6 stack set up. It seems unlikely that people with a non-IPv6 setup would want to publish that record, since it won't work for communicating with them. It also seems like a bad idea for me to keep these addresses hard-coded in /etc/hosts, since DNS assignments might change. One approach to fix this would be to consider :::W.X.Y.Z the same as W.X.Y.Z. Here's a clunky way to do that (i'd be happy to see a better mechanism proposed by someone who really knows ocaml): diff -r 0b577212aab4 membership.ml --- a/membership.ml Tue Sep 17 16:40:47 2013 -0400 +++ b/membership.ml Tue Dec 03 11:53:02 2013 -0500 @@ -156,9 +156,16 @@ let (m,mtime) = !membership in membership := (m,0.) +let compare_v4_v6 a b = + let a_s = Unix.string_of_inet_addr a in + let b_s = Unix.string_of_inet_addr b in + let prefix = ::: in + a_s = prefix ^ b_s || b_s = prefix ^ a_s + let same_inet_addr addr1 addr2 = match (addr1,addr2) with - (Unix.ADDR_INET (ip1,_), Unix.ADDR_INET (ip2,_)) - ip1 = ip2 + (Unix.ADDR_INET (ip1,_), Unix.ADDR_INET (ip2,_)) - +ip1 = ip2 || compare_v4_v6 ip1 ip2 | _ - false let rec choose () = --dkg signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] IPv4 vs. IPv6? -- Reconciliation attempt from unauthorized host, but host is authorized
On 12/03/2013 11:41 AM, Kim Minh Kaplan wrote:
But this *is* the approach that SKS uses, except that it does not have
to set IPV6_V6ONLY. Like I wrote in a previous answer, SKS requires the
administrator to list all addresses, IPv4 and IPv6. As an alternative you
can use the hostname. But I do not recommend this as you then have to be
sure that all your DNS system is working fine at SKS startup time.
ah, i'm finally understanding your suggestion, Kim. thanks for persisting.
Indeed, when i change zimmermann's recon_address from :: to an explicit
list of all public IP addresses, things seem to work as expected.
Note that there is no real operational problem to fix in SKS with regard
to IPv6. It works fine for many (all?) people. The only annoyance I know
is that you cannot use the catchall :: address on systems that provide
IPv4-mapped addresses by default, like Linux.
Could we update the wiki to include that suggestion? attached is a
patch for Peering.wiki.
--dkg
diff -r 389b4e01f450 Peering.wiki
--- a/Peering.wiki Mon Dec 02 21:27:55 2013 +
+++ b/Peering.wiki Tue Dec 03 12:06:22 2013 -0500
@@ -53,14 +53,14 @@
You probably want a DNS hostname of ##keyserver## or ##sks## or ##pgp-keys## in your domain. Eg, ##keyserver.example.com##. You need that hostname to resolve to the IP on which your SKS server listens **and** which will be used for outbound TCP connections. You want to use a dedicated hostname for this, so that you can move the SKS service independently of other services (the SKS peering protocols do not support hacks like HTTP redirects).
-If your machine has more than one IP address, it may be wise to set the ##hkp_address## and ##recon_address## options in your ##sksconf## file. Both options should be set to the same value(s). For example, assuming you have IPv6 connectivity and want to provide service on both IPv4 and IPv6:
+If your machine has more than one IP address, it may be wise to set the ##hkp_address## and ##recon_address## options in your ##sksconf## file. You should explicitly set all public addresses used, and avoid relying on the :: catchall. Unless you are using a reverse proxy (see below), both options should be set to the same value(s). For example, assuming you have IPv6 connectivity and want to provide service on both IPv4 and IPv6:
{{{
hostname: keyserver.example.com
hkp_address: 192.0.2.42 2001:DB8::1:42
recon_address: 192.0.2.42 2001:DB8::1:42
}}}
-(Strictly speaking: every address in ##recon_address## needs to be in ##hkp_address##, or covered by a wildcard address in ##hkp_address##, but they don't need to be the same. But part of using recon involves making connections to the hkp port on the same host.)
+(Strictly speaking: every address in ##recon_address## needs to be in ##hkp_address##, or covered by a wildcard address in ##hkp_address##, or mapped back to an address in ##hkp_address## via a reverse proxy, but they don't need to be the same. But part of using recon involves making connections to the hkp port on the same host.)
Note that ##recon_address## serves two purposes: it defines which addresses your recon server will //listen// on, and defines preferred source IP addresses for //outbound// connections too. For instance, if you specify one IPv4 address in the option, then outbound IPv4 connections will use that source address, while outbound IPv6 connections will use the system default.
@@ -323,4 +323,4 @@
== Editorial bias note ==
-This wiki page was written by someone who'll peer with almost anyone, but who really is happy when he sees a keyserver showing that it has a full keydump, as he's been bitten a couple of times by this issue.
\ No newline at end of file
+This wiki page was written by someone who'll peer with almost anyone, but who really is happy when he sees a keyserver showing that it has a full keydump, as he's been bitten a couple of times by this issue.
signature.asc
Description: OpenPGP digital signature
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] IPv4 vs. IPv6? -- Reconciliation attempt from unauthorized host, but host is authorized
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 12/03/2013 06:08 PM, Daniel Kahn Gillmor wrote: On 12/03/2013 11:41 AM, Kim Minh Kaplan wrote: But this *is* the approach that SKS uses, except that it does not have to set IPV6_V6ONLY. Like I wrote in a previous answer, SKS requires the administrator to list all addresses, IPv4 and IPv6. As an alternative you can use the hostname. But I do not recommend this as you then have to be sure that all your DNS system is working fine at SKS startup time. ah, i'm finally understanding your suggestion, Kim. thanks for persisting. .. Could we update the wiki to include that suggestion? attached is a patch for Peering.wiki. Thanks, I've pushed a slightly modified version of the patch explicitly mentioning the IPv4-IPv6 mapping wrt using catchall :: - -- - Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - Credo quia absurdum I believe it because it is absurd -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJSnhJyAAoJEAt/i2Dj7frjFZYP/3Xo8FztXzrSkd1Sq/C+GleA Z3iQyDoMT1TcADX8Vycvz9T1dETRrMDY/J1VpQKdKQQSxhzUabYwrn3wroIccLz+ WcS8+TH5NG5uINxMlxtRdk/kPBstrwAoRToCJL2LxGJkL3NxM2V2uPddgVxvhsIF 0V6Y+FAq06ZvR2jwnZKvTMCSDNflyJJutU1ezpjb3EFvf+736fKoawV/Qz00zsjT vfJf0jJ4IPyBZ/YI0kPElVRvZfCJ3ZkkCcF/iWOc6W88iFz+/a0U5IRKpt3PNOXl ms0naTLgeBzIvqVj1KujeWlgZMgbFIgs/ytLekTKSYW+4qS5n/DlOFwR3PKXd6UI fEgQiYBwXQTe+RpctGqYOZ2n0ENVmsX9cMrUVMzb1cs40ewVh0tvL0h17GO4HNx5 gr7FzwSn4fg+zZ7iu5Te/PMEHwj024+hpuFgLOGO7aNBYLdw54vaWabcms7vTanU 81FFi2aiqhOuWjxr+08YW3aSfjvdmGlDFzV/UZKsVSIFJznczkDsVrGP0lGSwAzA dnHErHDO+1WLaEg0fxE/lwy9FLtwD4UwI5hVX4+TQ3McmsCI9HPSmiXG9wTWygwg xOu9cTNxLe3T3311iVIPIpzA+K48kZ+4yI/a+hoXNxBAcB21ZM3EzycnaynQuw7B 59wMl0jxu24xbKHlhao4 =kVFR -END PGP SIGNATURE- ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] IPv4 vs. IPv6? -- Reconciliation attempt from unauthorized host, but host is authorized
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 :::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 :::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 :::94.142.241.93*) to the administrator of sks-peer.spodhuis.org. Not going to happen. The idea of 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
Re: [Sks-devel] IPv4 vs. IPv6? -- Reconciliation attempt from unauthorized host, but host is authorized
On 12/03/2013 12:34 PM, Phil Pennock wrote: 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. I like these suggestions. Thanks for the in-depth response and the link to itojun's draft. --dkg signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] IPv4 vs. IPv6? -- Reconciliation attempt from unauthorized host, but host is authorized
Daniel Kahn Gillmor wrote: 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 [:::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: From the file ANNOUNCEMENT in the 1.1.4 tree: Prerequisites There are a few prerequisites to building this code. You need: * ocaml-3.10.2 or later. Get it from http://www.ocaml.org ocaml-3.12.x is recommended, ocaml-4.x is not recommended at this time * Berkeley DB version 4.6.* or later, whereby 4.8 or later is recommended. You can find the appropriate versions at http://www.oracle.com/technetwork/database/berkeleydb/downloads/index.html It's been this way for quit a number of years. I'm perfectly fine with bumping the minimums to Ocaml 3.12.1 and BDB 4.8. I've been using Ocaml 4.00.1 and BDB 5.3/6.0 for some time now with no issues. -- John P. Clizbe Inet: John (a) Gingerbear DAWT net SKS/Enigmail/PGP-EKP or: John ( @ ) Enigmail DAWT net FSF Assoc #995 / FSFE Fellow #1797 hkp://keyserver.gingerbear.net or mailto:pgp-public-k...@gingerbear.net?subject=HELP Q:Just how do the residents of Haiku, Hawai'i hold conversations? A:An odd melody / island voices on the winds / surplus of vowels signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] IPv4 vs. IPv6? -- Reconciliation attempt from unauthorized host, but host is authorized
John Clizbe : I'm perfectly fine with bumping the minimums to Ocaml 3.12.1 Reading http://caml.inria.fr/distrib/ocaml-3.11/notes/Changes apparently IPV6_ONLY is available since Objective Caml 3.11.0. -- Kim Minh ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
