ietf
[Top] [All Lists]

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

2013-01-24 00:59:19
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
---------------------------------
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]. 

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: fgont(_at_)si6networks(_dot_)com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492