On 08/19/2014 07:47 PM, Mark Andrews wrote: >> Since Section 5.2 is in the draft, let me offer a more informal and >> practical explanation: >> >> 1) It is known that filtering of packets containing IPv6 Extension >> Headers (including the Fragment Header) is widespread (see our I-D above) >> >> 2) Let us assume that Host A is communicating with Server B, and that >> some node filters fragments between Host A and Server B. > > Some node is performing a Denial Of Service attack on the communications > between Host A and Server B. The logical thing is to remove/reconfigure > the node performing the denial of service attack. Note the box > that is dropping the fragments is almost certainly controlled by > the owners of A or the owners of B.
Not necessarily. Please see our measurement results in <http://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-in-real-world-00.txt> regarding the percentage of packet drops that happen in a different AS other than the destination AS. >> 3) An attacker sends a spoofed ICMPv6 PTB to server B, with a "Next Hop >> MTU<1280), in the hopes of eliciting "atomic fragments" (see >> <http://tools.ietf.org/rfc/rfc6946.txt>) from now on. >> >> 4) Now server B starts sending IPv6 atomic fragments... And since they >> include a frag header (and in '2)' above we noted that frags are dropped >> on that path), these packets get dropped (i.e., DoS). > > The PTB is not the problem. The Atomic fragments are not the > problem. The problem is the node that is filtering the packets. > Atomic fragements are easily identifiable. There is zero reason > to filter them and good reason to let them continue to exist. There's no problem with *processing* atomic fragments. The question here is what that of "including an FH in all subsequence packets in response to an ICMPv6 PTB<1280" buys us. As far as I can see, it only buys trouble. > Write up a CERT advisary and list all the known firewalls that fail > to pass atomic fragments. > > Write a RFC "Firewalls That Drop Atomic Fragments Considered Harmful". FWIW, they are dropping all fragments, not just atomic fragments. The only issue with atomic fragments is how their generation is triggered: they are (easily) triggered by a packet type (ICMPv6 PTB) that does not even require source address spoofing, and that is hard to validate. And even if you think you have everything under control in the sense of "I block all fragments, and artificially limit the MTU to 1280" you may get bitten. In the same way you will get bitten when a third party is dropping IPv6 fragments (as our measurements indicate). Cheers, -- Fernando Gont SI6 Networks e-mail: [email protected] PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
