Re: [DNSOP] Fwd: New Version Notification for draft-mekking-dnsop-kasp-00.txt
On 07/28/2014 07:55 AM, Jerry Lundström wrote: Hi, On fre, 2014-07-25 at 19:07 +0200, 神明達哉 wrote: I have just one very minor comment at this moment. While the draft says in Section 1.2 as follows: A key and signing policy can be expressed in any format. This document uses XML as example. there's only one XML example in it. Actually most examples use YANG. Thanks for the comment, I have noted it down in an issue [1] and we will change it for the next document version. The document was started with the current policy data structure used in OpenDNSSEC and that is represented in XML, later we switch to YANG so I think there are a few more places we need to change the text to reflect that. YANG is not used as an example. It is used here as the *modeling* language for the policy. XML is an example *markup* language that can be used to write down the policy. Best regards, Matthijs Cheers [1] https://github.com/matje/dnsop-kasp/issues/6 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] DNS, fragmentation, and IPv6 extension headers
Folks, (Apologies if this has been debated to death already). At the last IEPG meeting we presented some results regarding the filtering of packets that employ IPv6 extension headers (please see: http://www.iepg.org/2014-07-20-ietf90/iepg-ietf90-ipv6-ehs-in-the-real-world-v2.0.pdf). The packet drop rates range from 10% to over 50%, depending on the dataset (FWIW, these packets drops have nothing to do with DNS-specific packet-drops caused by sloppy firewalls or the like). This essentially raises the question of What's the plan for transporting DNS queries/responses in IPv6? At different venues (including the IETF), I've received/listened_to different opinions. Quite a few folks usually argue oh, that's simple: we'll use TCP, while others tend to argue that one should be careful when thinking about relying on TCP for DNS queries/responses (e.g. see http://www.iepg.org/2013-11-ietf88/2013-11-Time-Value-DNS.pdf). While this issue/question may be currently masqueraded by the fact that we still have IPv4, I wonder what's the plan for the IPv6 case (at some point, we'll have to rely on whatever such plan is). If the answer is fall-back to TCP if UDP doesn't work, my next question would be does popular DNS server software implement mitigations for TCP-based attacks? (zero-windows, FIN-WAIT-X flooding, etc.) Thoughts? Thanks! -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS, fragmentation, and IPv6 extension headers
On Mon, Jul 28, 2014 at 08:24:59AM -0400, Fernando Gont ferna...@gont.com.ar wrote a message of 43 lines which said: The packet drop rates range from 10% to over 50%, depending on the dataset Annoying. This essentially raises the question of What's the plan for transporting DNS queries/responses in IPv6? Why do we need a plan? We serve DNS over IPv6 for now ten years and it works (not I think it works but it is monitored so I'm certain it works). The problem with extension headers is annoying but, today, they are not used (of course, it's partially a chicken and egg problem, similar to the problm of IPv4 options: they are not transported reliably so people don't use them, so there is no motivation to make them reliable, etc). Quite a few folks usually argue oh, that's simple: we'll use TCP, There are many good reasons to use TCP but, in that case, I do not see why we need it. First, IPv6 users typically don't use extension headers and, second, if the problem is in IP, why would changing from UDP to TCP work? does popular DNS server software implement mitigations for TCP-based attacks? (zero-windows, FIN-WAIT-X flooding, etc.) Is it something that should be done in every application, and not in TCP itself? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS, fragmentation, and IPv6 extension headers
On Jul 28, 2014, at 8:42 AM, Stephane Bortzmeyer bortzme...@nic.fr wrote: Quite a few folks usually argue oh, that's simple: we'll use TCP, There are many good reasons to use TCP but, in that case, I do not see why we need it. First, IPv6 users typically don't use extension headers and, second, if the problem is in IP, why would changing from UDP to TCP work? Because the big issue is fragments: The IPv4 net decreed “Fragment’s don’t really work”. The IPv6 net has decreed “No, really, FRAGMENTS DO NOT WORK”. The solution is to detect and fallback on EDNS0 MTU to retry at 1400B first (rather than directly down to 512b), and properly handle truncation. But you do that, and things do work. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS, fragmentation, and IPv6 extension headers
Hi, Stephane, Thanks so much for your prompt response. Comments in-line... On 07/28/2014 08:42 AM, Stephane Bortzmeyer wrote: This essentially raises the question of What's the plan for transporting DNS queries/responses in IPv6? Why do we need a plan? We serve DNS over IPv6 for now ten years and it works (not I think it works but it is monitored so I'm certain it works). Just curious: How do you check that the UDP-based DNS replies actually get to the node that sent the query? The problem with extension headers is annoying but, today, they are not used (of course, it's partially a chicken and egg problem, similar to the problm of IPv4 options: they are not transported reliably so people don't use them, so there is no motivation to make them reliable, etc). Agreed. Quite a few folks usually argue oh, that's simple: we'll use TCP, There are many good reasons to use TCP but, in that case, I do not see why we need it. First, IPv6 users typically don't use extension headers and, How do you send responses larger than , say, ~1500 bytes without fragmentation? second, if the problem is in IP, why would changing from UDP to TCP work? Because TCP can avoid fragmentation. does popular DNS server software implement mitigations for TCP-based attacks? (zero-windows, FIN-WAIT-X flooding, etc.) Is it something that should be done in every application, and not in TCP itself? There are some mitigations that can be implemented in the kernel, while others make more sense to implement at the app (yes, it'd be ugly to duplicate code in multiple apps, but) Thanks, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS, fragmentation, and IPv6 extension headers
On 07/28/2014 08:48 AM, Nicholas Weaver wrote: There are many good reasons to use TCP but, in that case, I do not see why we need it. First, IPv6 users typically don't use extension headers and, second, if the problem is in IP, why would changing from UDP to TCP work? Because the big issue is fragments: The IPv4 net decreed “Fragment’s don’t really work”. The IPv6 net has decreed “No, really, FRAGMENTS DO NOT WORK”. The solution is to detect and fallback on EDNS0 MTU to retry at 1400B first (rather than directly down to 512b), and properly handle truncation. But you do that, and things do work. Is this standard behavior, or rather an implementation thing? (ie.., t what extent may one expect this mechanism to be widely implemented?) Thanks, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS, fragmentation, and IPv6 extension headers
Hi, On Jul 28, 2014, at 5:48 AM, Nicholas Weaver nwea...@icsi.berkeley.edu wrote: The IPv6 net has decreed “No, really, FRAGMENTS DO NOT WORK”. This could be a bit of an issue when the DNSSEC root key is rolled. Could someone point me to a writeup and/or data as to how we know the above decree? (I'm not disagreeing, I just haven't really been following this for a while). The solution is to detect and fallback on EDNS0 MTU to retry at 1400B first (rather than directly down to 512b), and properly handle truncation. How many shipping resolvers actually do this? Regards, -drc signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS, fragmentation, and IPv6 extension headers
David Conrad d...@virtualized.org wrote: On Jul 28, 2014, at 5:48 AM, Nicholas Weaver nwea...@icsi.berkeley.edu wrote: The solution is to detect and fallback on EDNS0 MTU to retry at 1400B first (rather than directly down to 512b), and properly handle truncation. How many shipping resolvers actually do this? I don't know what Unbound does. BIND 9.9 and earlier have three states in the default configuration: EDNS 4096, EDNS 512, and no-EDNS. It would start at the top and work down in response to failures. There is a knob to adjust the starting buffer size. BIND 9.10 changes the first state to do variable-size probing: it will try 512, 1232, 1432, and 4096, starting at the bottom and working up and down depending on what works. The middle numbers come from the minimum IPv6 MTU minus space for headers, and the ethernet MTU minus v4 and v6 headers to allow for tunneling. The (fixed) EDNS 512 and no-EDNS states remain. Unfortunately starting with a UDP size of 512 provokes masses of horrible truncation bugs in authority servers which causes more breakage (in my experience) than fragmentation does. It is particularly unfortunate when BIND decides to send no-EDNS queries for DNSSEC zones :-( I've hacked my BIND to drop the fixed EDNS 512 state and to start the variable-size probing at 1232 which seems to work a lot better. http://dnssec-deployment.org/pipermail/dnssec-deployment/2014-July/007080.html Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Trafalgar: Cyclonic 4 or 5, becoming northerly 5 to 7 in north. Slight or moderate, becoming moderate or rough in north. Fog patches at first in east. Moderate or good, occasionally very poor at first in east. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS, fragmentation, and IPv6 extension headers
On Mon, Jul 28, 2014 at 08:52:06AM -0400, Fernando Gont ferna...@gont.com.ar wrote a message of 60 lines which said: Just curious: How do you check that the UDP-based DNS replies actually get to the node that sent the query? 1) Because, otherwise, we would see retransmissions by the client. 2) Because we tested from various places (see a trace attached). 3) Because nobody complained (the weakest argument...) How do you send responses larger than , say, ~1500 bytes without fragmentation? I really did not understand your point at all: when you said extension headers, I did not think of fragmentation but of Destination Options, things like that. I thought that your point was that extension headers do not work. So, your point is actually that fragmentation does not work? If so, there are other solutions such as decreasing the buffer size of the server, under the MTU (.com name servers do it). This also helps against amplification attacks. % dig -6 @d.ext.nic.fr ANY fr ; DiG 9.8.4-rpz2+rl005.12-P1 -6 @d.ext.nic.fr ANY fr ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 48851 ;; flags: qr aa rd; QUERY: 1, ANSWER: 20, AUTHORITY: 0, ADDITIONAL: 3 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;fr.IN ANY ;; ANSWER SECTION: fr. 172800 IN SOA nsmaster.nic.fr. hostmaster.nic.fr. ( 549502 ; serial 3600 ; refresh (1 hour) 1800 ; retry (30 minutes) 360; expire (5 weeks 6 days 16 hours) 5400 ; minimum (1 hour 30 minutes) ) fr. 0 IN RRSIG NSEC3PARAM 8 1 0 20140914071832 ( 20140716071832 47116 fr. frc2CPwNg8uhi79qD7HRRuLHHc9tBIUebEOOHxRqnq0H v5hYZCxahoZ2ZyO4oIf4uqjAIrB3IF8YUdebujJkhYiZ v0vcS5eHrnZRbWhn0tZEdxBYPaD51zGNrKENrQhdApbR iWUVL9ZjkfOPKAHvtgvSlQlCUhDamxpvOkmeAFM= ) fr. 0 IN NSEC3PARAM 1 0 1 33629585 fr. 172800 IN RRSIG DNSKEY 8 1 172800 20140914071832 ( 20140716071832 20122 fr. V47KfKfpCkwh0oC13es9Tr/dqNrG63SRLyhWYdwDWTXH +wRMQNrIXLDVWRk7ZqwFadYABP2ler5PTMQ7bM0sjMAa NmPou3Pj+xOr7mT9MAvIXzVNKehETh4dN9MtlTzLLAmO wCv9yBxby0197w+wDZYjkTTBMzVgXuUkj5ymWwENQmIU F9fs6RuTRY9ZNweczjWMQmQDwL9FBgLOHtO3o7fmYMOR 3oSUlFpXvg1U4ou8z28euz7+hoX4N4rKClSzwzdkQSWj es2nI+DB/QqhXAnkL0UxH3sYd953ejbzxAv8MtZG1up7 nNZb117VRmnL+eMe6AG0fuE/OSFaUBv6xw== ) fr. 172800 IN RRSIG DNSKEY 8 1 172800 20140914071832 ( 20140716071832 47116 fr. e1Yka0xOaumQgPgyvwhjlYxVTre+m1b9KmM1jvCyT0HV g80llLLzZVq8Ndj/iR+UXH7Ba2VxMZ47WhzdnQ67s/QR cVcXDNILHdurIurPiIpqZuixI3s+nylWYRhUpzaznIKH BznIXCgqIOVFnVowFaBMUvnMiSW2/yvv2jiPtxg= ) fr. 172800 IN DNSKEY 257 3 8 ( AwEAAa2sILZ4XD/QqobSU6NKFRzXwBV3OpHn21LWcGgz 84+g9emlizfjWv51lwsERFSgK+AqmKpYegptTY/PQJrg rCAvOEoQBZi3WvnjZFmMvqnZpeFlymIAiRgfAsHdF+Nx o/5eItUoJv3YjquFXcSQXpZJz5w6S/I2n+7W44GuWv3A iNuVJNG6qsy7sEZRc2SpOgM8RPtAQpwcA+YHPuMdIdba O7BEzlnmUN6bOSguVRz1SQR6+5xcLciZ264+whSTKtOy fjLvrrbTyZtXu8s++5xJkDQ8U/yUpBbtNaUVtlKeLFTe Ad8K6xd3ggAR2qLvUMp2XZYBBKF7Lfwn6fcEq6E= ) ; key id = 20122 fr. 172800 IN DNSKEY 256 3 8 ( AwEAAbSTCfGdqPiLkqwzc1MTj0lpXSTS0yKfhgeRXeaO VmDCzSJ2Xo4pWb0ByV6OA9qefTriLiwvXCiPnh3l9rEd T6qBo5AqnMaFhM723DebNr1BVLSZcZP5hadMLTMFexLH +ysquEbPgszN5ZqXTLtcuA9B0wmuX8a/66qq6xUIDq51 ) ; key id = 63211 fr. 172800 IN DNSKEY 256 3 8 ( AwEAAaxxBitg7Axk/Ra7HliE/AFvaGqZ49qMpQDPB/lo Ba2/VuswG3IrDqnWzkV/Gdex6MoIFEf9ty6yfdPhwdOh T9sr8auuN/BxMhB0pd7ZkZYYaVzDxN9Zl0k/90BmCNuh
Re: [DNSOP] Fwd: New Version Notification for draft-mekking-dnsop-kasp-00.txt
At Mon, 28 Jul 2014 10:17:51 +0200, Matthijs Mekking matth...@nlnetlabs.nl wrote: I have just one very minor comment at this moment. While the draft says in Section 1.2 as follows: A key and signing policy can be expressed in any format. This document uses XML as example. there's only one XML example in it. Actually most examples use YANG. Thanks for the comment, I have noted it down in an issue [1] and we will change it for the next document version. The document was started with the current policy data structure used in OpenDNSSEC and that is represented in XML, later we switch to YANG so I think there are a few more places we need to change the text to reflect that. YANG is not used as an example. It is used here as the *modeling* language for the policy. XML is an example *markup* language that can be used to write down the policy. Ah, okay. But the current draft looks quite awkward to me even if it's not incorrect, having just one XML example. Hopefully future versions have more XML examples corresponding to each modeling definition. Also, understanding the evolution of the document from full-XML to YANG+XML, it would be more helpful to explicitly clarify YANG is used for modeling. BTW, another minor comment: in Section 2.1.13 the RollType leaf node is used, but there's no description for it in the list at the end of the section. I'm not sure if it's intentional, but it generally seems to try to provide a comprehensive list of descriptions, so I guess this is probably overlooked. -- JINMEI, Tatuya ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS, fragmentation, and IPv6 extension headers
On Mon, Jul 28, 2014 at 10:05 AM, David Conrad d...@virtualized.org wrote: Hi, On Jul 28, 2014, at 5:48 AM, Nicholas Weaver nwea...@icsi.berkeley.edu wrote: The IPv6 net has decreed “No, really, FRAGMENTS DO NOT WORK”. This could be a bit of an issue when the DNSSEC root key is rolled. Could someone point me to a writeup and/or data as to how we know the above decree? (I'm not disagreeing, I just haven't really been following this for a while). As one data point, the current top DNSKEY response sizes for TLDs (all using UDP) are: xn--fiq228c5hs. 1669 xn--6frz82g. 1657 xn--3ds443g. 1657 rich. 1629 post. 1629 pink. 1629 info. 1629 blue. 1629 asia. 1629 red. 1625 org. 1625 onl. 1625 kim. 1625 sc. 1621 pr. 1621 mn. 1621 me. 1621 lc. 1621 in. 1621 gi. 1621 bz. 1621 ag. 1621 bg. 1567 xn--fiqz9s. 1505 xn--fiqs8s. 1505 am. 1479 cn. 1473 dk. 1459 All of the above result in IPv6 fragmentation, and nearly all also result in IPv4 fragmentation---both assuming a 1500-byte PMTU and a resolver using an EDNS UDP payload value sufficient to hold the entire payload. This list has changed over time, through key rollovers and such. Has there been empirical or anecdotal evidence to suggest that DNSSEC validation has been broken for these TLDs for some population? I'm not suggesting that fragmentation is pretty, and I'm quite aware of path problems with fragmentation (some of them having been worked around by resolver implementations and configurations, as Tony indicated). Casey ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Irony.
Oops. Mailer problems and obviously misdirected... (intended to be sent to someone with whom I worked on the name collision stuff :)) Sincere apologies. Regards, -drc On Jul 28, 2014, at 3:34 PM, Casey Deccio ca...@deccio.net wrote: I have to admit I have struggled to not respond to Casey (who works for VRSN) with: Well, there wasn't much empirical evidence that name collisions could cause problems, yet... :) Regards, -drc On Mon, Jul 28, 2014 at 10:05 AM, David Conrad d...@virtualized.org wrote: Hi, On Jul 28, 2014, at 5:48 AM, Nicholas Weaver nwea...@icsi.berkeley.edu wrote: The IPv6 net has decreed “No, really, FRAGMENTS DO NOT WORK”. This could be a bit of an issue when the DNSSEC root key is rolled. Could someone point me to a writeup and/or data as to how we know the above decree? (I'm not disagreeing, I just haven't really been following this for a while). As one data point, the current top DNSKEY response sizes for TLDs (all using UDP) are: xn--fiq228c5hs. 1669 xn--6frz82g. 1657 xn--3ds443g. 1657 rich. 1629 post. 1629 pink. 1629 info. 1629 blue. 1629 asia. 1629 red. 1625 org. 1625 onl. 1625 kim. 1625 sc. 1621 pr. 1621 mn. 1621 me. 1621 lc. 1621 in. 1621 gi. 1621 bz. 1621 ag. 1621 bg. 1567 xn--fiqz9s. 1505 xn--fiqs8s. 1505 am. 1479 cn. 1473 dk. 1459 All of the above result in IPv6 fragmentation, and nearly all also result in IPv4 fragmentation---both assuming a 1500-byte PMTU and a resolver using an EDNS UDP payload value sufficient to hold the entire payload. This list has changed over time, through key rollovers and such. Has there been empirical or anecdotal evidence to suggest that DNSSEC validation has been broken for these TLDs for some population? I'm not suggesting that fragmentation is pretty, and I'm quite aware of path problems with fragmentation (some of them having been worked around by resolver implementations and configurations, as Tony indicated). Casey signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS, fragmentation, and IPv6 extension headers
Tony Finch wrote: BIND 9.10 changes the first state to do variable-size probing: it will try 512, 1232, 1432, and 4096, starting at the bottom and working up and down depending on what works. The middle numbers come from the minimum IPv6 MTU minus space for headers, and the ethernet MTU minus v4 and v6 headers to allow for tunneling. Your assumption is that there is no extension headers exist. But, the problem of current IPv6 specification allows for very long extension headers (more than 60KB is allowed), some of which are automatically inserted not under transport/application layer control. So, as Fernando Gont wrote: While this issue/question may be currently masqueraded by the fact that we still have IPv4, I wonder what's the plan for the IPv6 case (at some point, we'll have to rely on whatever such plan is). The first thing to do is to obsolete extension headers and related gotcha in IPv6 specification. Even a fragmentation header has annoying requirement. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
