Subject: Chairs Review on <draft-ietf-6man-predictable-fragment-id-02>

From: Bob Hinden <[email-masked]>
Date: Tue, 3 Mar 2015 12:49:48 -0800

The chairs have completed our review of this draft and have issues we would like to raise.  Some are for the author, and some are for for the working group.  Our comments range from serious to editorial.

Please review and send us your comments.

Thanks,
Bob & Ole

-------

Serious

The biggest issue is if advancing and publishing this draft is worthwhile.  We note that in Appendix B "Survey of Fragment Identification selection algorithms employed by popular IPv6 implementations”, of the implementation listed, all of the current ones (FreeBSD 9, Linux-current, OpenBSD-current) show unpredictable or random.  While there are many older obsolete operating systems that have issues, we aren’t going to fix these by publishing this draft.  The report does not list current versions of Windows (9 or 10), nor any mobile OS’s (though, IOS and Android are based on BSD and Linux respectively).  We wonder what will achieved by publishing this RFC since it appears that current shipping operating systems don’t have the issue.  This is a question for the working group.

Moderate

In Section 2 "Security Implications of Predictable Fragment Identification values”.  The problems listed seem to us to be overstated.  As the draft notes later, the issue with predictable fragment IDs in IPv6 is only an issue for IPv6 packets with the fragment header.  Traffic that doesn’t include a fragment header is, of course, immune.  This alone reduces the severity of the problems listed.  We don’t think the draft makes this clear.  We agree it is possible for an attacker to cause a host to respond with a fragmented packet making the Fragment ID visible to this won’t give the attacker any visibility into the non-fragmented traffic the host is sending.  The significantly reduces the severity of the items listed.

On Page 5 of Section 2, the draft cites problems with Linux 2.6.38-8.  This is an old version of the Linux kernel and we don’t think it justifies the problem, especially since according to the appendix it is fixed in later version of the Linux kernel.

In the second paragraph of Section 2., it says

 [CPNI-IPv6] contains a detailed analysis of possible vulnerabilities
 introduced by predictable Fragment Identification values.

This appears to be a significant part of the justification.  However, when looking at the reference it says:

 [CPNI-IPv6]  Gont, F., "Security Assessment of the Internet Protocol
              version 6 (IPv6)", UK Centre for the Protection of
              National Infrastructure, (available on request).

Including a reference that isn’t generally available, appears to be an issue to us if this is part of the justification for this work.  Has anyone in the working group reviewed it?  We suggest it be removed or the document referenced be made available on a stable web site.

Editorial

Abstract.
OLD:
Some implementations use simple a global counter for
setting the Identification field, thus leading to predictable values.

NEW:
Some implementations use a simple global counter for
setting the Identification field, thus leading to predictable values.

Issue #2:
Remove:  [I-D.ietf-6man-deprecate-atomfrag-generation] aims at deprecating the
generation of IPv6 atomic fragments.

Issue #3:
s/DoS/DoS attack/
"DoS" isn't a verb.

Issue #4:
OLD:
From a security standpoint, unpredictable Identification values are
desirable.  However, this is somewhat at odds with the "re-use"
requirements specified in [RFC2460].

NEW:
From a security standpoint, unpredictable Identification values are
desirable.  However, this is somewhat at odds with the "re-use"
requirements specified in [RFC2460], that specifies that an Identification
value must be different than that of any other fragment sent recently.

Issue #5:
Section 4.1 Add reference RFC4861 for "Destination cache"

Issue #6:
References: Remove [I-D.ietf-6man-deprecate-atomfrag-generation]

---

From: Fernando Gont <[email-masked]>
Date: Mon, 09 Mar 2015 00:44:13 +0100

Hi, Bob,

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

On 03/03/2015 09:49 PM, Bob Hinden wrote:
> 
> The biggest issue is if advancing and publishing this draft is
> worthwhile.  We note that in Appendix B "Survey of Fragment
> Identification selection algorithms employed by popular IPv6
> implementationsâ, of the implementation listed, all of the current
> ones (FreeBSD 9, Linux-current, OpenBSD-current) show unpredictable
> or random.  While there are many older obsolete operating systems
> that have issues, we arenât going to fix these by publishing this
> draft.

FWIW, I'd say that a number of OSes (including Linux and Solaris) were
fixed as a result of this I-D, indeed (some even reference the I-D in
the code or commit messages). The reason why this happened
earlier than the I-D became an RFC is that I usually socialize the I-Ds
I author/co-author with OS developers. However, there are other OSes
that still need to be fixed. And since we're talking about IPv6 (not
about IPv4), I'd expect new implementations to appear (the word can't
just be a handful of OSes, and I expect IPv6 to live long enough :-) )--
so this document would be of help to them.

> The report does not list current versions of Windows (9 or
> 10), nor any mobile OSâs (though, IOS and Android are based on BSD
> and Linux respectively). 

The list is not really meant to be exhaustive. However, I've just
augmented it (with 5+ OSes).

> Moderate
> 
> In Section 2 "Security Implications of Predictable Fragment
> Identification valuesâ.  The problems listed seem to us to be
> overstated.  As the draft notes later, the issue with predictable
> fragment IDs in IPv6 is only an issue for IPv6 packets with the
> fragment header.

Yes, but you can trigger fragmentation for any traffic flow (see
draft-ietf-6man-deprecate-atomfrag-generation).

> Traffic that doesnât include a fragment header is,
> of course, immune.  This alone reduces the severity of the problems
> listed.  We donât think the draft makes this clear.

Truth is that right now it is trivial to trigger the use of
fragmentation (just fire an ICMPv6 PTB<1280).

> On Page 5 of Section 2, the draft cites problems with Linux 2.6.38-8.
> This is an old version of the Linux kernel and we donât think it
> justifies the problem, especially since according to the appendix it
> is fixed in later version of the Linux kernel.

FWIW, Linux was fixed in response to this document.

> version 6 (IPv6)", UK Centre for the Protection of National
> Infrastructure, (available on request).
> 
> Including a reference that isnât generally available, appears to be
> an issue to us if this is part of the justification for this work.
> Has anyone in the working group reviewed it?  We suggest it be
> removed or the document referenced be made available on a stable web
> site.

The reference (now removed) just elaborated on the vulnerabilities.
Essentially, the problem is well known form the IPv4 world. The only
additional item to consider for th IPv6 case is that you can trigger the
use of fragmentation for any traffic flow, which in IPv4 you simply can't.

> Issue #2: Remove:  [I-D.ietf-6man-deprecate-atomfrag-generation] aims
> at deprecating the generation of IPv6 atomic fragments.

No issues with removing this. But isn't this really relevant?

[All other changes applied]

Thanks so much!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492