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

From: Bob Hinden <[email-masked]>
Date: Mon, 18 May 2015 15:59:01 +0300

Fernando,

Thanks for making the changes.  I note that the latest draft still shows Windows 8 incorrectly.

A few comments on your comments below.

Bob

> On Mar 9, 2015, at 1:44 AM, Fernando Gont <[email-masked]> wrote:
> 
> 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.

It’s great you are reaching out to OS developers.  That seems to be why it is getting fixed, I am not so sure that publishing an RFC will help that much.  I do agree there will be new IPv6 implementations.

> 
>> 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).

Yes, if it knows the address of the other side of the connection.  The attacker would have to be on link, or monitoring the traffic between the two hosts.  This make this attack much harder in practice for an off link attacker.  If on link, then there are so many better attacks.  Hence my comment of the problem being overstated.

> 
> 
>> 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).
> 

Same as above.

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

Good!

> 
> 
>> [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.
> 
> 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.

Thanks, the problem was that the document was not accessible.

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

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

---

From: Fernando Gont <[email-masked]>
Date: Tue, 19 May 2015 04:05:19 -0300

Hi, Bob,

> shows Windows 8 incorrectly.

Oops.. that was the result of an error while editing. Fixed. Thanks!

>>> 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.
> 
> It’s great you are reaching out to OS developers.  That seems to be
> why it is getting fixed, I am not so sure that publishing an RFC will
> help that much.  I do agree there will be new IPv6 implementations.

It will certainly help in documenting what OSes do, and will certainly
be of help for new implementations, which an learn about the problem of
predictable I-Ds and also find possible approaches to avoid them.

>>> 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, if it knows the address of the other side of the connection.
> The attacker would have to be on link, or monitoring the traffic
> between the two hosts.  This make this attack much harder in practice
> for an off link attacker.  If on link, then there are so many better
> attacks.  Hence my comment of the problem being overstated.

It is trivial to know the IPv6 addresses involved for many scenarios.
e.g. BGP peer to BGP peer, secondary DNS to primary DNS, SMTP server to
SMTP server, etc.

Thanks!

Best regards,

---

From: Bob Hinden <[email-masked]>
Date: Tue, 19 May 2015 11:40:21 +0300

Fernando,

> On May 19, 2015, at 10:05 AM, Fernando Gont <[email-masked]> wrote:
> 
> Hi, Bob,
> 

Thanks!

> predictable I-Ds and also find possible approaches to avoid them.

I agree.

> e.g. BGP peer to BGP peer, secondary DNS to primary DNS, SMTP server to

That’s my point.  It’s trivial only if you know the addresses of both side of the connection.  It effects well known nodes.  It does not affect the vast majority of hosts on the Internet.  Hence, I think the text should accurately describe the risk.  I think the current text overstates the problem.  You could say something like you did above.

Thanks,
Bob

---

From: Fernando Gont <[email-masked]>
Date: Fri, 29 May 2015 05:15:37 -0300

Hi, Bob,

On 05/19/2015 05:40 AM, Bob Hinden wrote:
>>>>> Identification valuesâ.  The problems listed seem to us to
>>>>> be overstated.  As the draft notes later, the issue with 
>>>> Yes, but you can trigger fragmentation for any traffic flow
>>>> (see draft-ietf-6man-deprecate-atomfrag-generation).
>>> 
>>> 
>>> Yes, if it knows the address of the other side of the
>>> connection. The attacker would have to be on link, or monitoring
>>> the traffic between the two hosts.  This make this attack much
>>> harder in practice for an off link attacker.  If on link, then
>>> there are so many better attacks.  Hence my comment of the
>>> problem being overstated.
>> 
>> It is trivial to know the IPv6 addresses involved for many
>> scenarios. e.g. BGP peer to BGP peer, secondary DNS to primary DNS,
>> SMTP server to SMTP server, etc.
> 
> That’s my point.  It’s trivial only if you know the addresses of both
> side of the connection.  It effects well known nodes.  It does not
> affect the vast majority of hosts on the Internet.  Hence, I think
> the text should accurately describe the risk.  I think the current
> text overstates the problem.  You could say something like you did
> above.

I've added text along these lines and rev'ed the I-D.

P.S.: Ready to ship now?

Thanks so much!

Cheers,

---

From: Bob Hinden <[email-masked]>
Date: Fri, 29 May 2015 08:21:30 -0700

Fernando,

> On May 29, 2015, at 1:15 AM, Fernando Gont <[email-masked]> wrote:
> 
> Hi, Bob,
> 

I will take a look.  This was the last issue I had.

Thanks,
Bob

---

From: Fernando Gont <[email-masked]>
Date: Fri, 29 May 2015 12:38:59 -0300

Hi, Bob,

> I will take a look.  This was the last issue I had.

FWIW, the text says:

---- cut here ----
   The scenarios in which an attacker may successfully perform the
   aforementioned attacks depend on the specific attack type.  For
   example, in order to DoS communications between two hosts, an
   attacker would need to know the IPv6 addresses employed by the
   aforementioned two nodes.  Such knowledge may be readily available if
   the target of the attack is the communication between two specific
   BGP peers, two specific SMTP servers, or one specific primary DNS
   server and one of its secondary DNS servers, but may not be easily
   available if goal of the attack is to DoS all communications between
   arbitrary IPv6 hosts (e.g. the goal was to DoS all communications
   involving one specific node with arbitrary/unknown hosts).  Other
   attacks, such as performing stealth port scans to a third-party or
   determining the packet rate at which a given system is transmitting
   information, only require the attacker to know the IPv6 address of a
   vulnerable implementation.
---- cut here ----

Thanks!

Cheers,