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,
TSV-DIR review of draft-ietf-6man-ipv6-atomic-fragments-03
Transport Directorate review of
https://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-atomic-fragments
I've reviewed this document as part of the transport area directorate's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the
document's authors for their information and to allow them to address any
issues raised. Please always CC tsv-...@ietf.org if you reply to or
forward this review.
Summary
-
This draft is on the right track but has issues, described in the review,
that call for a bigger picture.
In addition to reading the draft, I read over the documents it references,
and I also read through the AD Review thread about the 02 version of the
draft, on the 6man mailing list.
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.
I've tried to make a schematic of the problem and solution described by the
draft.
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).
ORIGINAL ATTACK
---
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
T3 E to B: blind-inserted overlapping v6-fragment, ID=X, Offset=0
T4 B: A's T2 data should have gotten through. But E's T3
fragment forces silent drop.
DRAFT'S SOLUTION
-
The draft says that B MUST process atomic fragments in isolation, not in
relation to the fragment queue. Further discussion in next section.
T'0-T'3: same as T0-T3 above.
T'4 B: receive and process A's atomic fragment, with no regard
to E's insertion.
RESIDUAL RISK?
-
In the AD Review thread, Brian Haberman asks the WG if the solution
actually creates an attack vector on receiving hosts. A roll-up of the
several-message exchange between Haberman and Fernando Gont, the draft
author, can be found in
http://www.ietf.org/mail-archive/web/ipv6/current/msg16807.html. From a
Transport point of view, I agree that there could be a new attack vector on
the receivers.
Consider first that E successfully got a spoofed fragment onto B's fragment
queue. What if E turns that fragment into an atomic fragment.
Post-mitigation, E's datagram no longer causes A's datagram to be blocked,
but does the processing of E's atomic fragment in isolation introduce a
greater chance than before that E's datagram can pass from B successfully
to the ULP?
It depends on what processing an atomic fragment in isolation means
specifically. The draft says this:
A host that receives an IPv6 packet which includes a Fragment
Header with the Fragment Offset equal to 0 and the M bit equal
to 0 MUST process such packet in isolation from any other packets/
fragments, even if such packets/fragments contain the same set
{IPv6 Source Address, IPv6 Destination Address, Fragment
Identification}. A received atomic fragments should be
reassembled from the contents of that sole fragment.
And this:
Additionally, if any fragments with the same set {IPV6 Source
Address, IPv6 Destination Address, Fragment Identification} are
present in the fragment reassembly queue when the atomic fragment
is received, such fragments MUST NOT be discarded upon receipt of
the colliding IPv6 atomic fragment, since IPv6 atomic fragments
MUST NOT interfere with normal fragmented traffic.
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:
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
