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] request draft-hardaker-dnsop-csync be adopted as a WG item
On Thu, 13 Jun 2013, Wes Hardaker wrote: Subject: [DNSOP] request draft-hardaker-dnsop-csync be adopted as a WG item A new version of I-D, draft-hardaker-dnsop-csync-00.txt has been successfully submitted by Wes Hardaker and posted to the IETF repository. This document specifies how a child zone in the DNS can publish a record that can indicate that a parental agent may copy and process certain records from the child zone. The existence and change of the record may be monitored by a parental agent to either assist in transferring or automatically transfer data from the child to the parent. Interesting draft. I'm not yet sure if I prefer this over the CDS draft or not, or whether this draft should exclude DNSKEY/DS sync. I like that this draft could potentially solve all parent-child record syncing. Comments: 2.1.1.1 talks about the serial in the CSYNC record. Why did you prefer a soft link between that and the SOA serial, instead of a hard link? Or why is there is a need for a serial? Shouldn't it directly relate to the SOA serial? You seem to think one would need a minimal SOA serial to process the CSYNC record, but wouldn't the CSYNC record always be correctin the _current_ zonefile? I don't see how prepublishing a CSYNC with a current serial + 1 would be of any benefit. The following CSYNC RR shows an example entry for example.com that indicates the NS, A and records should be processed for the zone using a minimum SOA serial number of 66. example.com. 3600 IN CSYNC 73 1 A NS Did you mean to write 66 in the RRDATA? Or did I misunderstand something? Since you later write 0x42, I think you mean 66 here. 2.2.1 talks about fetching the SOA, CSYNC, data and again SOA record. I think you need to state that you should also aboard if the CSYNC/SOA serial obtained is lower then a previously processed CSYNC/SOA action. This will prevent flipflopping when one NS server is out of sync and presenting old data. This section should also indicate processing MUST be aborted if there was no full path of trust from the parent to the child (ie. we need DNSSEC authenticated data) 2.2.2.1. The NS type It should note that parent policy might result in rejecting the proposed change at the child, for example if only 1 NS record would be left. 2.2.2.4. The DS type I kinda lost track here. It's pretty confusing. Also because the DS type would really need to query DNSKEY, as the child is not publishing DS records. (eg Queries should be sent to the child zone for all the DS records is wrong) It talks quite a bit about whether to sync (C)DS or DNSKEY. In some sense, perhaps to facilitate parents that insist on creating the DS from DNSKEY, and parents that insist on getting a DS RRdata from child, to split the DS type here into CDS and DNSKEY type, where the latter means create DS from DNSKEY. Although that would mean large parts of the CDS draft would not really be used, if the CSYNC scheduling part is used. 2.3.3. support at parent. If it is important that we know if the parent supoprts CSYNC and with what parameters, should be define a RRtype for that which the parent can publish? I'm hesitant to state in a protocol document that we need something and suggest adding a human/manual procedure for that, when it can be avoided. Paul ___ 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
