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

[Ray Hunter <[e-mail]>]

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

[e-mail] 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