In message <[email protected]>, joel jaeggli writes: > On 6/18/13 10:47 AM, [email protected] 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.
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. 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. > > 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 > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
