Subject: Re: I-D Action: draft-ietf-6man-predictable-fragment-id-01.txt

From: Ray Hunter <[email-masked]>
Date: Tue, 06 May 2014 10:52:02 +0200

I have read this draft and think thatit is very well written and that it 
is important work. Detailed comments below.

[email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>   This draft is a work item of the IPv6 Maintenance Working Group of the IETF.
>
>          Title           : Security Implications of Predictable Fragment Identification Values
>          Author          : Fernando Gont
> 	Filename        : draft-ietf-6man-predictable-fragment-id-01.txt
> 	Pages           : 16
> 	Date            : 2014-04-29
>
> Abstract:
>     IPv6 specifies the Fragment Header, which is employed for the
>     fragmentation and reassembly mechanisms.  The Fragment Header
>     contains an "Identification" field which, together with the IPv6
>     Source Address and the IPv6 Destination Address of a packet,
>     identifies fragments that correspond to the same original datagram,
>     such that they can be reassembled together at the receiving host.
>     The only requirement for setting the "Identification" value is that
>     it must be different than that employed for any other fragmented
>     packet sent recently with the same Source Address and Destination
>     Address.  Some implementations use simple a global counter for
>     setting the Identification field, thus leading to predictable values.
>     This document analyzes the security implications of predictable
>     Identification values, and updates RFC 2460 specifying additional
>     requirements for setting the Identification field of the Fragment
>     Header, such that the aforementioned security implications are
>     mitigated.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-6man-predictable-fragment-id/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-6man-predictable-fragment-id-01
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-predictable-fragment-id-01
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>

A potential DoS attack is described in section 3.

> Finally,
>    the attacker send forged IPv6 fragments to the Host B, with their
>    IPv6 Source Address set to that of Host A, and Identification values
>    that would result in collisions with the Identification values
>    employed for the legitimate traffic sent by Host A to Host B. If Host
>    B discards fragments that result in collisions of Identification
>    values (e.g., such fragments overlap, and the host implements
>    [RFC5722]), the attacker could simply trash the Identification space
>    by sending multiple forged fragments with different Identification
>    values, such that any subsequent packets from Host A to Host B are
>    discarded at Host B as a result of the malicious fragments sent by
>    the attacker.
Comment 1.
Would this attack also be applicable to any middleware boxes that track 
session progress at the fragmentation level?

DoS attacker Host C could create a race condition by sending spoofed 
packets from A to B with forged fragment ident values, and the 
middelware box would potentially forward (or attempt to re-assemble) 
these packets in preference to the real next fragments arriving from A.

s/If Host B discards fragments /If Host B, or any intermediate 
middleware box tracking the session, discards fragments/ ?

Comment 2.
/The Identification value of the Fragment Header MUST NOT be predictable 
by an off-path attacker./

I think there should be more of a constraint on what is "good enough"

Is this not a s/MUST NOT/SHOULD NOT/?

Nothing actually breaks immediately if the advice is ignored.

Comment 3.
I have a concern with the ability of implementations to be able to 
comply with this requirement.

The effective field length is apparently only 16 bits when used in 
combination with IPv6/IPv4 translation (according to Section 5).

Sending 2^16 attack packets is not a big ask.

And it will be far fewer if the attacker relies on birthday type 
collisions to only disrupt 1 in n packets. e.g. if there are many 
packets in the stream and the aim of the attacker is to occasionally 
disrupt the stream they only need to send a fraction of the number of 
attack packets needed to disrupt every single packet.

So I think I also have to ask "is the fragment ident itself sufficiently 
long/ protected to be resistant to birthday type attacks, especially in 
combination with RFC6415 IPv6/IPv4 translation?"

Comment 4.
Do we also need to mandate /Nodes SHOULD also implement ICMP specific 
attack countermeasures as described in [RFC 5927] / in section 4, to 
prevent an off-path attacker being able force use of fragmentation in 
the first place?

-- 
Regards,
RayH

---

From: Fernando Gont <[email-masked]>
Date: Wed, 07 May 2014 05:17:12 -0500

Hi, Ray,

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

On 05/06/2014 03:52 AM, Ray Hunter wrote:
> is important work. 

Thanks!

> session progress at the fragmentation level?

It certainly would. Question: do these voxes just "monitor" the traffic
(i.e., just snoop it), or do they actually receive-inspect-filter-if
appropriate)?   -- If the former, the attack could result in "evasion".
If the later, the attack would result in DoS.

> these packets in preference to the real next fragments arriving from A.

Agreed. That's, for instance, the DNS data-injection attack referenced
in the I-D.

> middleware box tracking the session, discards fragments/ ?

I'd personally have the middleware stuff as a separate section or
paragraph.. what do you think?

> Nothing actually breaks immediately if the advice is ignored.

I agree with the "nothing breaks" (and could certainly live with a
"SHOULD NOT")... although I'd note that it's pretty common to use
"MUST"s for security reasons... --- as in "the secret key MUST NOT be
known to possible attackers" or the like..

Another view is that if you include a "SHOULD NOT" (rather than MUST),
you should include cases where an implementer might decide to go against
the advice... but I don't see any reasons for that...

> Sending 2^16 attack packets is not a big ask.

I'd call that "brute forcing" rather than "predicting the ID".

> combination with RFC6415 IPv6/IPv4 translation?"

It's certainly long enough. In this case, the problem is really in IPv4,
that has a far shorter Frag ID. I'd also say that I don't quite
understand why the translators expect to learn a sensible IPv4 Frag ID
from the IPv6 frag ID.  For instance, if the NAT64 box shares the same
IPv4 address among many IPv6 nodes, then, it may even lead to
collissions.  -- e.g.:

Host A   -----------
2001:db8::1         \+--------+
                     |        | 100.0.0.1
                     | NAT 64 +------------------ Host C
Host B   ------------|        |                   8.8.8.8
2001:db8::2          +--------+

Host A sends a packet "to 8.8.8.8" with frag ID 0xaaaa11111. Host B
sends a packet "to 8.8.8.8" with Frag ID 0xbbbb1111. Now both packets
employ the tuple (src 100.0.0.1, dst 8.8.8.8, frag id 0x1111) thus
resulting in a colision of Frag IDs.

> prevent an off-path attacker being able force use of fragmentation in

I think they should -- also referencing RFC5927 in such a way would be a
down ref 8bcp/std track mandating an informational document). The only
caveat is: If the header chain is long enough (>1280 bytes), then the
transport protocol header will not be available in the ICMPv6 error.

(Unfortunately, mmany implementations don't even validate it when it's
available)

Thoughts?

Thanks!
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1