Subject: TSV-DIR review of draft-ietf-6man-ipv6-atomic-fragments-03

From: Allison Mankin <[email-masked]>
Date: Wed, 23 Jan 2013 19:33:06 -0500

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 [email-masked] 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 (MTU<1280)

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
---------------------------------
T"0   A to B:    v6-dgram --->

T"1  E to A:    ICMPv6 Too Big (MTU<1280)

T"2  A to B:     switch to v6-atomic-fragment, ID=X, Offset=0
T"2a B:           deliver A's datagram to ULP

T"3  E to B:     blind-inserted overlapping v6-atomic-fragment, ID=X,
Offset=0
T"3a B:           deliver E's overlapping datagram to ULP

T"4:  B:           TCP attack mitigated by RFC 5722 looks possible again
[see Note 3].

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 the larger context, I agree that what's in
this draft has a part - on its own, not sure it stands.

Notes
---------
[1] (Digression) I'd love to call for a Law of Kludges that says that if
you are gatewaying two protocols, the one that is older should always be
the one that graciously accepts the kludges; I'm not deeply enough into
this all to understand why the gateway's IPv4 side needs the IPv6 side to
supply it with a Fragmentation header - why it couldn't create fragments
into IPv4 independent of the original IPv6?

[2] To a point problem...

[3] In RFC 5722, the crux of why B has to drop overlapping IPv6 fragments
is these paragraphs:

   The TCP header has the following values of the flags: S(YN)=1 and
   A(CK)=1.  This may make an inspecting stateful firewall think that it
   is a response packet for a connection request initiated from the
   trusted side of the firewall.  Hence, it will allow the fragment to
   pass.  It will also allow the following fragments with the same
   Fragment Identification value in the fragment header to pass through.

   A malicious node can form a second fragment with a TCP header that
   changes the flags and sets S(YN)=1 and A(CK)=0.  This can change the
   packet on the receiving end to consider the packet as a connection
   request instead of a response.  By doing this, the malicious node has
   bypassed the firewall's access control to initiate a connection
   request to a node protected by a firewall.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 24 Jan 2013 03:58:12 -0300

Hi, Allison,

Thanks so much for your feedback! -- Please find my comments in-line....

On 01/23/2013 09:33 PM, Allison Mankin wrote:
> 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.
> 
> 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

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: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Joe Touch <[email-masked]>
Date: Thu, 24 Jan 2013 11:35:05 -0800

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

---

From: Fernando Gont <[email-masked]>
Date: Thu, 24 Jan 2013 18:24:01 -0300

Joe,

>       received ICMPv6 error messages, as recommended in Section 5.2 of

Are we fine if I remove "and [RFC5927]"? -- Because RFC4443 does
recommend that ICMPv6 messages be validated.

> 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,

---

From: Joe Touch <[email-masked]>
Date: Thu, 24 Jan 2013 16:19:32 -0800

> recommend that ICMPv6 messages be validated.

Sure.

> [RFC4443] and documented in [RFC5927]"

That might do it, but it would be useful if another pair of eyes would 
check.

Joe

---

From: Allison Mankin <[email-masked]>
Date: Thu, 24 Jan 2013 20:57:09 -0500

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

check.

---

From: Joe Touch <[email-masked]>
Date: Thu, 24 Jan 2013 17:59:00 -0800

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:
> 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" <[email-masked]
> <mailto:[email-masked]>> wrote:
>  >
>  >
>  >
>  > That might do it, but it would be useful if another pair of eyes
> would check.
>  >
>  > Joe
>  >
>  >>
>  >> Thoughts?
>  >>
>  >> Thanks,
>  >>
>