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

[Brian E Carpenter <[e-mail]>]

Hi,

On 20/12/2014 05:45, Fernando Gont wrote:
> 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?

There are precedents the other way, for example RFC 4941 specifies
algorithms for pseudo-random IIDs at SHOULD level, and RFC 7217 has a
MUST. But for the flow label (RFC 6437), we chose not to specify an
algorithm; we just specified that the values SHOULD be chosen from a
uniform distribution.

   Brian C

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