Re: 6MAN WG Last Call: draft-ietf-6man-predictable-fragment-id-01

[Fernando Gont <[e-mail]>]

Hi, Ole,

On 12/08/2014 03:16 PM, Ole Troan wrote:
> <nohat>
> 
> let me offer a contrarian view. I don't think we should publish this 
> document. why? because I don't think it is worth the effort required 
> by the community. I think we've pushed the needle too far in 
> publishing 'micro updates'.

FWIW, this document does three things:

* Requiring that the IP ID be unpredictable
* Providing guidance to achieve that
* Document the implications of predictable fragment IDs

At this point, I'd argue that most of the work has been done --
including getting reviews from folks from other communities that have
been dealing with issues associated with predictable IDs for a long time.



> RFC2460 does not have normative language in how the Identification 
> value should be generated. therefore I see no need to update 
> RFC2460.

That's, actually, one of the reasons for publishing it. The implications
of predictable fragment IDs are, as you'll note in the document itself,
non-trivial.

Similar work has happened elsewhere for other protocols. For example,
RFC6056 for port number randomization or RFC6528 (originally RFC1948)
for TCP sequence numbers.

The price of not doing what needs to be done can be seen in the DNS
spoofing attacks that got widely publicized years ago.

Despite, our previous IPv4 experience, we still have IPv6 stacks
employing predictable fragment IDs. This document has already helped a
few implementations change their IPv6 ID generators, and having a proper
requirement will help to avoid the pain -- which tends to result in way
more effort and damage than getting a document published.



> I think the advice may be useful, I'd be happy to see it in an
> RFC2460 update, or an update to the IPv6 Node requirement document.
> or more generally you could see a document in intarea titled "IP
> protocol fields must not be predictable.".

While I will not rehash this discussion (which we did had at the time),
I should note that !alternative paths" were suggested for
<http://tools.ietf.org/id/draft-gont-6man-slaac-dns-config-issues-00.txt> too,
and we haven't achieved anything in that area. IN this particular case,
there's a concrete an mature document that probably just need a few more
looks and a bit of polishing.

Thanks!

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