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

[Fernando Gont <[e-mail]>]

On 12/19/2014 09:52 AM, Brian Haberman wrote:
>> That said, I'm not sure I follow what you say above. This
>> document has a requirement that the IP ID must not be
>> predictable, and
> 
> How does one determine a value is not predictable?  How would the 
> predictability of the IP ID value affect interoperability?
> 
> Nothing that I see in this document impacts interoperability.

So... does that mean that the only kind of requirements that we can
issue in protocol specs are those that affect interoperability?


>> implementation advice on how to achieve that. The current status
>> of the ID is std track for the former, not for the later. As far
>> as this document is concerned, RFC2460 could already be advanced
>> on the stndards track, since there are at least four different
>> and interoperable implementations: FreeBSD, OpenBSD, Linux, and
>> OpenSolaris.
>> 
>> While the (un)predicatability of the IP ID certainly does not
>> affect interoperability, I guess the same applies to lots of
>> other specs related to security (for instance, the choice of
>> accepting a non-authenticated packet/chunk_of_data when
>> authentication mechanisms are place probably does not affect
>> interoperability.... yet we have plenty of these (for obvious
>> reasons) in the corresponding specs).
> 
> I think you are conflating issues here.  Authentication requires
> both ends to use the same mechanism (hence the need for
> interoperability since there are multiple authentication
> mechanisms).

But once you are employing an auth method, there's the question of
what to do if you receive an un-authenticated packet/chunk_of_data.
The policy of dropping or accepting such a packet/chunk is one of
security rather than of interoperability. But, for obvious reasons,
you'd specify to drop such packets/chunks. If we just specify for
interoperability, then this question would remain unaddressed.



>> That said, and as noted above, I have no issues with proceeding
>> as you suggested if that's deemed as the right way to go.
> 
> The WG needs to decide which way to go.

Yep.

Thanks!

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