Re: rfc2460bis and Frag ID generation

[Fernando Gont <[e-mail]>]

Hi, Bob,

On 02/04/2016 04:24 PM, Bob Hinden wrote:
> Fernando,
> 
>> On Feb 4, 2016, at 11:00 AM, Fernando Gont <[e-mail]>
>> wrote:
>> 
>> Bob/folks,
>> 
>> The current text regarding frag ID generation in rfc2460bis says:
>> 
>> ---- cut here ---- *  "recently" means within the maximum likely
>> lifetime of a packet, including transit time from source to
>> destination and time spent awaiting reassembly with other fragments
>> of the same packet.  However, it is not required that a source node
>> know the maximum packet lifetime.  Rather, it is assumed that the 
>> requirement can be met by maintaining the Identification value as a
>> simple, 32-bit, "wrap-around" counter, incremented each time a
>> packet must be fragmented.  It is an implementation choice whether
>> to maintain a single counter for the node or multiple counters,
>> e.g., one for each of the node's possible source addresses, or one
>> for each active (source address, destination address) combination. 
>> ---- cut here ----
>> 
>> 
>> I suggest changing the text to:
>> 
>> ---- cut here ---- *  "recently" means within the maximum likely
>> lifetime of a packet, including transit time from source to
>> destination and time spent awaiting reassembly with other fragments
>> of the same packet.  However, it is not required that a source node
>> know the maximum packet lifetime.  Rather, it is assumed that the 
>> requirement can be met by implementing an algorithm that results in
>> a low identification reuse frequency. [RFC7739] discusses possible
>> algorithms that can meet this requirement while avoiding possible
>> security and privacy issues. ---- cut here ----
>> 
>> (where the ref to RFC7739 is obviously informative, rather than
>> normative).
>> 
>> -- Bottom-line is that rfc2460bis shouldn't suggest algorithms
>> that have known issues, and it's better to have an informative
>> reference to RFC7739, where possible algorithms are discussed.
>> 
>> Thoughts?
> 
> I looked at this earlier and also thought the 32-bit wrap around
> counter text was dated.  I am OK with something similar to what you
> proposed.  My read of the current text is that it is describes the
> 32-bit wrap around counter as an example, as opposed the only way to
> do it, so an update like this would be OK.

That's my take as well. So this change would essentially just remove the
current example, and point to RFC7739 for examples, where different
algorithms and pros/cons of each of them are analyzed.

Thanks!

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