[ippm] Re: Erik Kline's Discuss on draft-ietf-ippm-encrypted-pdmv2-09: (with DISCUSS and COMMENT)

["[e-mail]" <[e-mail]>]

Erik,
> From a Python interactive shell:
>>> 4294967296  / 83333.33
>51539.60961358438

>51,540 seconds, which is only about 14 hours.
>Also: if the packets are the smallest (say, 68) then the rollover time is even shorter (less than an hour).
Yes, sorry for the arithmetic error.  You are correct.   But, remember, there is also the 12bit unsigned EPOCH field.  When the PSNTP rolls over, the EPOCH field will be incremented.  When finally BOTH fields roll over, then we will stop collecting data for that session.
Remember again, this is performance and diagnostic data only.  The session itself will continue with no interruption.



Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
https://www.insidethestack.com
PresidentIndustry Network Technology Councilhttps://www.industrynetcouncil.org 

    On Monday, October 21, 2024 at 03:40:43 AM GMT+2, Erik Kline <[e-mail]> wrote:  
 
 

On Sat, Oct 19, 2024 at 11:56 PM [e-mail] <[e-mail]> wrote:

Erik,
Thanks for your comments.
> ### S3.3
> * The draft says "difference between the two types of headers is determined
>  from the Options Length value" but then shows two diagrams each with
>  22 bytes post-"Option Length"-field contents and also:

>   Option Length

>      0x22: Unencrypted PDM
>      0x22: Encrypted PDM


>  which would seem to amount to 34 bytes.

>  Possibly I'm just missing something obvious, or I've completely misread
>  diagrams and/or the text, but how does an implementation distinguish
>  between these two formats?

Sorry, that is a mistake.  I thought I had changed that everywhere.   The difference between unencrypted and encrypted PDMv2 is negotiated out of band (along with other registration attributes.)   This is left over from some previous thoughts we had had on distinguishing between the two options on the wire.

Ah, that makes more sense.  I'll look for updated text whenever you post a newer revision.  Thanks.

>### S5.1

>* If I understand this correctly a new SessionTemporaryKey MUST be
>  renegotiated every 2^32 packets.  Can you include a calculation to show
>  approximately how often this turns out to be?

>  I've probably done my math wrong, but assuming 1500 byte packets, a
>  1 Gpbs link, and host sending at line rate I'd estimate a rollover
>  about every 14 hours. If the packets are smaller the rollover is even
>  faster
I *think*  I have done the calculation correctly below:
1. A 32-bit counter can count from 0 to 2 ** 32.  Thus, the total number of unique values the counter can hold is 4294967296 packets

2. Each packet is 1500 bytes. Convert bytes to bits: 12000 

3. Link speed of 1 Gbps=1×10**9 bits/second

4. Packets per second= Link speed / Packet size in bits
or 1×10**9 bits per second / 12000 bits
This equals 83333.33 packets per second

5.  Time to overflow = Total packets possible in counter/ Packets per second
or
4294967296 packets / 83333.33 packets = 515396.07 seconds.

6. 515396.07 seconds is 143.2 hours or 5.95 days.
Please correct me if I am wrong.

>From a Python interactive shell:
>>> 4294967296  / 83333.33 
51539.60961358438

51,540 seconds, which is only about 14 hours.
Also: if the packets are the smallest (say, 68) then the rollover time is even shorter (less than an hour).

Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
https://www.insidethestack.com
PresidentIndustry Network Technology Councilhttps://www.industrynetcouncil.org 

    On Sunday, October 20, 2024 at 03:43:42 AM GMT+2, Erik Kline via Datatracker <[e-mail]> wrote:  
 
 Erik Kline has entered the following ballot position for
draft-ietf-ippm-encrypted-pdmv2-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ippm-encrypted-pdmv2/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

# Internet AD comments for draft-ietf-ippm-encrypted-pdmv2-09
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Discuss

### S3.3

* The draft says "difference between the two types of headers is determined
  from the Options Length value" but then shows two diagrams each with
  22 bytes post-"Option Length"-field contents and also:

  Option Length

      0x22: Unencrypted PDM
      0x22: Encrypted PDM


  which would seem to amount to 34 bytes.

  Possibly I'm just missing something obvious, or I've completely misread
  diagrams and/or the text, but how does an implementation distinguish
  between these two formats?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


# Internet AD comments for draft-ietf-ippm-encrypted-pdmv2-09
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### S5.1

* If I understand this correctly a new SessionTemporaryKey MUST be
  renegotiated every 2^32 packets.  Can you include a calculation to show
  approximately how often this turns out to be?

  I've probably done my math wrong, but assuming 1500 byte packets, a
  1 Gpbs link, and host sending at line rate I'd estimate a rollover
  about every 14 hours. If the packets are smaller the rollover is even
  faster



_______________________________________________
ippm mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]