Re: TSV-DIR review of draft-ietf-6man-ipv6-atomic-fragments-03
FWIW, this document includes text that somewhat defeats the previous recommendations of TCPM regarding RFC5927. RFC5927 includes specific text indicating that the techniques described are being documented, but that the TCP standard was NOT being changed to include those ICMP validation checks. This document states that: Many implementations fail to perform validation checks on the received ICMPv6 error messages, as recommended in Section 5.2 of [RFC4443] and [RFC5927]. I.e., the second RFC does NOT recommend changes; it documents them. This document should be VERY carefully reviewed to ensure that it does not undo the previous TCPM concerns about these techniques. Joe
Re: TSV-DIR review of draft-ietf-6man-ipv6-atomic-fragments-03
Joe, On 01/24/2013 04:35 PM, Joe Touch wrote: FWIW, this document includes text that somewhat defeats the previous recommendations of TCPM regarding RFC5927. RFC5927 includes specific text indicating that the techniques described are being documented, but that the TCP standard was NOT being changed to include those ICMP validation checks. This document states that: Many implementations fail to perform validation checks on the received ICMPv6 error messages, as recommended in Section 5.2 of [RFC4443] and [RFC5927]. Are we fine if I remove and [RFC5927]? -- Because RFC4443 does recommend that ICMPv6 messages be validated. I.e., the second RFC does NOT recommend changes; it documents them. This document should be VERY carefully reviewed to ensure that it does not undo the previous TCPM concerns about these techniques. We can remove and [RFC5927] or change it to ...Section 5.2 of [RFC4443] and documented in [RFC5927] Thoughts? Thanks, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
Re: TSV-DIR review of draft-ietf-6man-ipv6-atomic-fragments-03
On 1/24/2013 1:24 PM, Fernando Gont wrote: Joe, On 01/24/2013 04:35 PM, Joe Touch wrote: FWIW, this document includes text that somewhat defeats the previous recommendations of TCPM regarding RFC5927. RFC5927 includes specific text indicating that the techniques described are being documented, but that the TCP standard was NOT being changed to include those ICMP validation checks. This document states that: Many implementations fail to perform validation checks on the received ICMPv6 error messages, as recommended in Section 5.2 of [RFC4443] and [RFC5927]. Are we fine if I remove and [RFC5927]? -- Because RFC4443 does recommend that ICMPv6 messages be validated. Sure. I.e., the second RFC does NOT recommend changes; it documents them. This document should be VERY carefully reviewed to ensure that it does not undo the previous TCPM concerns about these techniques. We can remove and [RFC5927] or change it to ...Section 5.2 of [RFC4443] and documented in [RFC5927] That might do it, but it would be useful if another pair of eyes would check. Joe Thoughts? Thanks,
Re: TSV-DIR review of draft-ietf-6man-ipv6-atomic-fragments-03
Joe and Fernando, I just looked at how RFC 5297 is handled in the draft, to be that other pair of eyes. The first fix is right, to remove reference to RFC 5297 from that sentence entirely. Allison On Jan 24, 2013 7:19 PM, Joe Touch to...@isi.edu wrote: On 1/24/2013 1:24 PM, Fernando Gont wrote: Joe, On 01/24/2013 04:35 PM, Joe Touch wrote: FWIW, this document includes text that somewhat defeats the previous recommendations of TCPM regarding RFC5927. RFC5927 includes specific text indicating that the techniques described are being documented, but that the TCP standard was NOT being changed to include those ICMP validation checks. This document states that: Many implementations fail to perform validation checks on the received ICMPv6 error messages, as recommended in Section 5.2 of [RFC4443] and [RFC5927]. Are we fine if I remove and [RFC5927]? -- Because RFC4443 does recommend that ICMPv6 messages be validated. Sure. I.e., the second RFC does NOT recommend changes; it documents them. This document should be VERY carefully reviewed to ensure that it does not undo the previous TCPM concerns about these techniques. We can remove and [RFC5927] or change it to ...Section 5.2 of [RFC4443] and documented in [RFC5927] That might do it, but it would be useful if another pair of eyes would check. Joe Thoughts? Thanks,
Re: TSV-DIR review of draft-ietf-6man-ipv6-atomic-fragments-03
Thanks - I wasn't positive about the second one. Glad to have it resolved quickly. Joe On 1/24/2013 5:57 PM, Allison Mankin wrote: Joe and Fernando, I just looked at how RFC 5297 is handled in the draft, to be that other pair of eyes. The first fix is right, to remove reference to RFC 5297 from that sentence entirely. Allison On Jan 24, 2013 7:19 PM, Joe Touch to...@isi.edu mailto:to...@isi.edu wrote: On 1/24/2013 1:24 PM, Fernando Gont wrote: Joe, On 01/24/2013 04:35 PM, Joe Touch wrote: FWIW, this document includes text that somewhat defeats the previous recommendations of TCPM regarding RFC5927. RFC5927 includes specific text indicating that the techniques described are being documented, but that the TCP standard was NOT being changed to include those ICMP validation checks. This document states that: Many implementations fail to perform validation checks on the received ICMPv6 error messages, as recommended in Section 5.2 of [RFC4443] and [RFC5927]. Are we fine if I remove and [RFC5927]? -- Because RFC4443 does recommend that ICMPv6 messages be validated. Sure. I.e., the second RFC does NOT recommend changes; it documents them. This document should be VERY carefully reviewed to ensure that it does not undo the previous TCPM concerns about these techniques. We can remove and [RFC5927] or change it to ...Section 5.2 of [RFC4443] and documented in [RFC5927] That might do it, but it would be useful if another pair of eyes would check. Joe Thoughts? Thanks,
Re: TSV-DIR review of draft-ietf-6man-ipv6-atomic-fragments-03
Hi, Allison, Thanks so much for your feedback! -- Please find my comments in-line On 01/23/2013 09:33 PM, Allison Mankin wrote: It is clearly valuable to call the community's attention to the atomic fragment in IPv6. This is an IPv6 datagram that is not actually fragmented, but has a Fragmentation Header (with an offset of 0 and the M bit set to 0). It seems the atomic fragment in IPv6 arose to accommodate translation gateways with MTUs of less than 1280 (the IPv6 minimum) on the IPv4 side [1]. The problem is that you can force a sender to generate atomic fragments instead of normal packets from an off-path node, if the sender doesn't filter ICMPv6 much. Note: 1) It's not a problem at all if you process atomic fragments as indicated. 2) You cannot filter ICMPv6 as appropriate: The ICMPv6 payload can always contain less information than needed to validate the ICMP error messages. A is the IPv6 sender that either does not or cannot filter incoming ICMPv6 very well and that chooses Fragmentation IDs in a predictable way when it must fragment. E is a blind attacker (or collaborating blind attackers), not on path/in the middle for A. B is the destination for A's traffic. B initially doesn't distinguish between atomic fragments and normal fragments. However, B has implemented another solution [2], RFC 5722, which requires that IPv6 fragments be dropped silently if they overlap (have the same IDs and carry material from the same offset+fragment length). FWIW, RFC5722 is a solution to the firewall evasion by overlapping fragments, but in this case can be of help for DoS purposes. ORIGINAL ATTACK --- [] FWIW, the scenario you sketched is 100% correct. RESIDUAL RISK? - [] So now a receiver is forced to process an atomic datagram even if there are overlapping fragments already there on the fragmentation queue. NEW ATTACK VECTOR - T0 A to B:v6-dgram --- T1 E to A:ICMPv6 Too Big (MTU1280) T2 A to B: switch to v6-atomic-fragment, ID=X, Offset=0 T2a B: deliver A's datagram to ULP T3 E to B: blind-inserted overlapping v6-atomic-fragment, ID=X, Offset=0 T3a B: deliver E's overlapping datagram to ULP T4: B: TCP attack mitigated by RFC 5722 looks possible again [see Note 3]. I fail to see why this scenario could be seen as an example of an attack RFC 5722 avoids. Simply put, what draft-ietf-6man-ipv6-atomic-fragments-03 says is: an atomic fragment is not really a fragment, but rather a complete packet that just happens to have a Frag Header -- hence, process it as such. RFC 5722 is meant to prevent attacks in which you can fool a firewall by sending overlapping fragments: the fragment allows the first fragment, but then a second fragment (which looks harmless) overwrites the initial fragment such that the reassembled packet becomes an attack packet. Atomic fragments do not fall in that category: A firewall has all the knowledge it needs to decide whether to filter (or not) what's in the atomic fragment. And if the firewall allowed the atomic fragment, that's exactly how the fragment is going t be delivered to the ULP. Conclusion --- There's an interesting table in the draft showing which sending stacks can be tricked into switching to v6-atomic-fragments and which receiving ones can be tricked into dropping them due to fragment overlap. Another way of looking at this table is that a lot of stacks need to be less predictable and more suspicious of spoofing traffic. The present draft is pragmatic/empirical and is interested in fixing a problem that exists (it can be brought on). But I wonder if it would be better to embed the discussion of atomic fragments and fragment overlap in a larger picture, a collected set of best practices against spoofers (of ICMPv6, of IPv6 fragments or otherwise). In this particular case, there's a specific standard that needs to be updated, and existing software relying on the feature (atomic fragments) that we're improving. I'm not sure what kind of document you have in mind... but my personal experience says that being able to tackle isolated problems separately (rather than work on a large document that tries to address a plethora of issues) is (by far) more doable. Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
