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

[Bob Hinden <[e-mail]>]

Fernando,

> On May 19, 2015, at 10:05 AM, Fernando Gont <[e-mail]> wrote:
> 
> Hi, Bob,
> 
> On 05/18/2015 09:59 AM, Bob Hinden wrote:
>> Fernando,
>> 
>> Thanks for making the changes.  I note that the latest draft still
>> shows Windows 8 incorrectly.
> 
> Oops.. that was the result of an error while editing. Fixed. Thanks!

Thanks!

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

I agree.

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

Thanks,
Bob