Subject: rfc2460bis and Frag ID generation

From: Fernando Gont <[email-masked]>
Date: Thu, 4 Feb 2016 16:00:08 -0300

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?

Thanks!

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

---

From: Bob Hinden <[email-masked]>
Date: Thu, 4 Feb 2016 11:24:18 -0800

Fernando,

> On Feb 4, 2016, at 11:00 AM, Fernando Gont <[email-masked]> wrote:
> 
> Bob/folks,
> 

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.

Other comments?

Thanks,
Bob

---

From: Fernando Gont <[email-masked]>
Date: Thu, 4 Feb 2016 16:36:44 -0300

Hi, Bob,

On 02/04/2016 04:24 PM, Bob Hinden wrote:
>> ---- 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 ----
>> 
>> 
>> ---- 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 ----
>> 
>> -- 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,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 4 Feb 2016 16:42:08 -0300

[....]
> do it, so an update like this would be OK.

BTW, please let me know if the current version will not be revised in
less than, say, 1 week, and I could do a full review....

Thanks!

Cheers,

---

From: Bob Hinden <[email-masked]>
Date: Thu, 4 Feb 2016 12:05:08 -0800

Fernanco,

> On Feb 4, 2016, at 11:42 AM, Fernando Gont <[email-masked]> wrote:
> 
> less than, say, 1 week, and I could do a full review….

Not sure, other than this possible change, I don’t have anything else queued up.

Bob

---

From: Fernando Gont <[email-masked]>
Date: Thu, 4 Feb 2016 17:16:32 -0300

> Not sure, other than this possible change, I don’t have anything else queued up.

I meant... if the I-D is going to be stable for a few days, I can do a
complete review. Otherwise I'd wait for the next rev, so that I review
the updated doc...

Cheers,

---

From: Bob Hinden <[email-masked]>
Date: Thu, 4 Feb 2016 12:33:28 -0800

> On Feb 4, 2016, at 12:16 PM, Fernando Gont <[email-masked]> wrote:
> 
> the updated doc…

I promise not to make any changes until next week :-)

More importantly, I doubt there will be any major changes going forward.

Bob

---

From: Fernando Gont <[email-masked]>
Date: Thu, 4 Feb 2016 17:36:30 -0300

> More importantly, I doubt there will be any major changes going forward.

Ok. :-) I'll send a full rev this weekend.

Thanks!

Cheers,