Re: [DNSOP] BIG RRSETS EDNS0 and ipv6 framentation.
On 6/18/13 10:47 AM, sth...@nethelp.no wrote: Unfortunately the former are far too prevalent. It's undoubtedly too late, but unfortunately it might have been better to do the fragmentation within the UDP payload (i.e. inside DNS) somehow (c.f. http://tools.ietf.org/html/rfc5405#section-3.2). It is *never* too late. For IPv6 we are still in the very early days. but, what about the 'vast install base' ? There isn't a vast install base of firewalls (border routers). If there was we would have 99% IPv6 traffic instead of 1.6% IPv6 traffic. So I like the assumption that I should limit edns0 responses to something I don't have to fragment. My goal as it were was to look at if fragmentation were expected to work that I don't really want to expose myself to reciving a 4k response (via UDP) because the risk of an amplification attack becomes very large indeed. Even if I filter fragments (because I have to or as a product of limitations such an attack my be targeted at the infrastructure rather than the endpoint that's the notional target. I'm afraid I have to disagree. There is a significant installed base of border routers doing *stateless* firewall functions for various reasons. Some of these border routers already have IPv6 turned on, and many more of them *will* have IPv6 turned on in the near future. Changes to IPv6 handling that require new software for these routers is certainly possible - you only need to sell such a change to the vendors. Changes that require hardware replacement (and therefore significant capex) are obviously much harder. Steinar Haug, AS 2116 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] BIG RRSETS EDNS0 and ipv6 framentation.
On Jun 18, 2013, at 8:22 AM, Mark Andrews ma...@isc.org wrote: My goal as it were was to look at if fragmentation were expected to work that I don't really want to expose myself to reciving a 4k response (via UDP) because the risk of an amplification attack becomes very large indeed. Even if I filter fragments (because I have to or as a product of limitations such an attack my be targeted at the infrastructure rather than the endpoint that's the notional target. Yet fragmented packets work fine if you don't put a middle box in the middle that has a conniption when it sees a fragmented packet. This is practically every box on IPv6. Fragments REALLY don't work on IPv6. As for being exposed you really can't prevent being exposed. As for not replying with fragmented packets, that it self causes operational problems as you move the traffic to TCP which unless you have taken measures to reduce the sement sizes runs the risk of PMTUD problems. Some of the ORG servers limit the UDP size then don't do PMTUD well which is a real pain if you are behind a tunnel. IPv6 is much better on PMTU discovery than IPv4, and with IPv6, you can always just set to use the minimum IPv6 (1200B) MTU and bypass all PMTU discovery anyway. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] BIG RRSETS EDNS0 and ipv6 framentation.
In message 2791d081-1d23-4b72-a4e3-211bddb7c...@icsi.berkeley.edu, Nicholas Weaver writes: On Jun 18, 2013, at 8:22 AM, Mark Andrews ma...@isc.org wrote: My goal as it were was to look at if fragmentation were expected to work that I don't really want to expose myself to reciving a 4k response (via UDP) because the risk of an amplification attack becomes very large indeed. Even if I filter fragments (because I have to or as a product of limitations such an attack my be targeted at the infrastructure rather than the endpoint that's the notional target. Yet fragmented packets work fine if you don't put a middle box in the middle that has a conniption when it sees a fragmented packet. This is practically every box on IPv6. Fragments REALLY don't work on IPv6. Which is not correct given the successful IPv6 reassembly counters on my IPv6 boxes which are recursive servers. Yes there is a IPv6 firewall in front of and on these boxes. Hop-by-hop also cross the Internet fine. Remember most of the firewalls are dropping fragmented UDP because they can't identify if the fragment is part of a packet they are allowing through. Give the firewalls a way to identify that a UDP fragments is part of a such a packet and they will be allowed through / reassembled and allowed through if dpi is being done and dpi is often turned off on firewalls for DNS packets even when it defaults to on. 6 to 8 extra octets per fragment would allow this. Assuming this is the only hop-by-hop option and the fragment header is next one would add the following and the next header option in the IPv6 header would be zero. 440tbd,4,src-port,dst-port and tbd would start with 000 skip if unknown=00 and unchanging=0. Mark ip6: 1883580 total packets received 2604 fragments received 0 fragments dropped (dup or out of space) 68 fragments dropped after timeout 0 fragments that exceeded limit 1266 packets reassembled ok 976983 packets for this host 342821 packets not forwardable 1643642 packets sent from this host 32050 output packets discarded due to no route 254 output datagrams fragmented 508 fragments created 12 packets that violated scope rules 342753 multicast packets which we don't join Input histogram: hop by hop: 1055 TCP: 934449 UDP: 47301 fragment: 2604 ICMP6: 898170 Mbuf statistics: 319754 one mbuf two or more mbuf: lo0= 264312 1299514 one ext mbuf ip6: 805638 total packets received 831 fragments received 0 fragments dropped (dup or out of space) 11 fragments dropped after timeout 0 fragments that exceeded limit 410 packets reassembled ok 380419 packets for this host 409513 packets forwarded 4502 packets not forwardable 389337 packets sent from this host 4485 multicast packets which we don't join Input histogram: hop by hop: 271 TCP: 748570 UDP: 12234 fragment: 1060 ICMP6: 43503 Mbuf statistics: 575 one mbuf 805063 one ext mbuf source addresses on an outgoing I/F 159 node-locals 222 link-locals 30757 globals source addresses on a non-outgoing I/F 2 globals source addresses of same scope 159 node-locals 222 link-locals 30759 globals 568305 forward cache hit 232283 forward cache miss As for being exposed you really can't prevent being exposed. As for not replying with fragmented packets, that it self causes operational problems as you move the traffic to TCP which unless you have taken measures to reduce the sement sizes runs the risk of PMTUD problems. Some of the ORG servers limit the UDP size then don't do PMTUD well which is a real pain if you are behind a tunnel. IPv6 is much better on PMTU discovery than IPv4, and with IPv6, you can always just set to use the minimum IPv6 (1200B) MTU and bypass all PMTU discovery anyway. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] BIG RRSETS EDNS0 and ipv6 framentation.
In message 51bc6c18.3020...@bogus.com, joel jaeggli writes: I'm interested in the intersection between the requested payload size and the use of the v6 fragmentation header, 6891 I think is missing some advice to implementers that might reasonably prevent fragmented replies from being dropped and limit the degree of amplification that can be achieved with large RRsets. Fragments get dropped because of badly configured/designed firewalls and PMTUD. Setting IPV6_USE_MIN_MTU to 1 helps with the latter though it may result in a addition fragment being sent. If one really wants to play games you set IPV6_USE_MIN_MTU to 1 for DNS UDP responses bigger than 1432 octets and leave it at -1 for mesages 1432 octets and less. 1432 octets allows for both a IPv4 and IPv6 header over ethernet without fragmenting. There is still a lot of 6in4 and 6to4 tunnels. TCP should always set IPV6_USE_MIN_MTU to 1 as PMTUD takes too long for DNS and is unreliable. Except for a zone transfers the most it will add is 5 additional packets (+ possible acks) to the transaction and usually no more than 1. Are there thoughts about this based on experience? thanks joel ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] BIG RRSETS EDNS0 and ipv6 framentation.
On 16 June 2013 23:15, Mark Andrews ma...@isc.org wrote: In message 51bc6c18.3020...@bogus.com, joel jaeggli writes: I'm interested in the intersection between the requested payload size and the use of the v6 fragmentation header, 6891 I think is missing some advice to implementers that might reasonably prevent fragmented replies from being dropped and limit the degree of amplification that can be achieved with large RRsets. Fragments get dropped because of badly configured/designed firewalls and PMTUD. Setting IPV6_USE_MIN_MTU to 1 helps with the latter though it may result in a addition fragment being sent. Unfortunately the former are far too prevalent. It's undoubtedly too late, but unfortunately it might have been better to do the fragmentation within the UDP payload (i.e. inside DNS) somehow (c.f. http://tools.ietf.org/html/rfc5405#section-3.2). ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] BIG RRSETS EDNS0 and ipv6 framentation.
On Mon, Jun 17, 2013 at 10:19 PM, Mark Andrews ma...@isc.org wrote: In message cal9jlabek2eh2jejmm2rjrugj6ctqtfzojyhkrp7hzjtefq...@mail.gmail.com, Christopher Morrow writes: On Mon, Jun 17, 2013 at 8:49 PM, Mark Andrews ma...@isc.org wrote: Unfortunately the former are far too prevalent. It's undoubtedly too late, but unfortunately it might have been better to do the fragmentation within the UDP payload (i.e. inside DNS) somehow (c.f. http://tools.ietf.org/html/rfc5405#section-3.2). It is *never* too late. For IPv6 we are still in the very early days. but, what about the 'vast install base' ? There isn't a vast install base of firewalls (border routers). If there was we would have 99% IPv6 traffic instead of 1.6% IPv6 traffic. I forgot my :) in my comment. anyways... -chris ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] BIG RRSETS EDNS0 and ipv6 framentation.
Lets just say if you think the IPv4 fragmentation problem is bad, IPv6 makes it look positively benign by comparison on the IPv6 kit deployed today. Basically, use a 1400B EDNS0 mtu, and failover to TCP. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
