Re: [1904.4 TF] [**EXTERNAL**] RE: 1904.4 Consensus call

Thread Links	Date Links
Thread Prev	Thread Next	Thread Index	Date Prev	Date Next	Date Index

Yeah, we could add the DER-encoded certs in the examples – well, a hex dump of the DER encoding – if you think it’s useful.

From: Glen Kramer <glen.kramer@xxxxxxxxxxxx>
Date: Tuesday, September 17, 2024 at 1:05 PM
To: Craig Pratt <c.pratt@xxxxxxxxxxxxx>, STDS-1904-4-TF@xxxxxxxxxxxxxxxxx <STDS-1904-4-TF@xxxxxxxxxxxxxxxxx>
Subject: RE: [1904.4 TF] [**EXTERNAL**] RE: 1904.4 Consensus call

Hi Craig,

Thank you for posting.

A question on the CertSize formula below:

Our certificate examples in Annex 11A show only PEM format. This is 25% less efficient than BER/DER format, that is, the same certificate is 25% larger in PEM format than in DER. Should we add DER examples too?

Should we mandate a specific certificate encoding for the Install and retrieve OAMPDUs?

Thanks,

Glen

From: Craig Pratt <000025f75ba9ec80-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Monday, September 16, 2024 11:03 PM
To: STDS-1904-4-TF@xxxxxxxxxxxxxxxxx
Subject: Re: [1904.4 TF] [**EXTERNAL**] RE: 1904.4 Consensus call

Hey all,

Sorry – missed the request. Here’s the table:

Note that 1 cert will typically have 1 public key and 1 signature – and they don’t have to be from the same algorithm. So the math for cert size is:

CertSize = sizeof(public key) + sizeof(signature) + sizeof(ASN.1 BER-encoded x509 cert metadata)

My hunch is that there will be very good options that are under 12K total.

From: stds-1904-4-tf@xxxxxxxxxxxxxxxxx <stds-1904-4-tf@xxxxxxxxxxxxxxxxx> on behalf of Glen Kramer <000006d1020766de-dmarc-request@xxxxxxxxxxxxxxxxx>
Date: Thursday, September 12, 2024 at 3:22 PM
To: Marion, Jc <jmarion@xxxxxxxxx>, stds-1904-4-tf@xxxxxxxxxxxxxxxxx <stds-1904-4-tf@xxxxxxxxxxxxxxxxx>
Subject: RE: [1904.4 TF] [**EXTERNAL**] RE: 1904.4 Consensus call

Thank you, JC.

I put this suggestion into slides. There are several corner case behaviors we need to agree on. But overall, this seems a workable solution.

Let’s discuss this on the reflector, unless someone would prefer another call.

Craig – please, post on the reflector the key/signature size table you presented on the last call.

Thank you,

Glen

From: Marion, Jc <jmarion@xxxxxxxxx>
Sent: Wednesday, September 11, 2024 12:57 PM
To: Glen Kramer <glen.kramer@xxxxxxxxxxxx>; STDS-1904-4-TF@xxxxxxxxxxxxxxxxx
Subject: Re: [1904.4 TF] [**EXTERNAL**] RE: 1904.4 Consensus call

I agree to leave the software download alone.

As for the size of incoming cert(s), why don’t we replace the sequence number field with a 4 bytes field that specifies the number of bytes that are to come after this current message? We would use the high bit (bit [31] to specify that this is the first message).

The receiver of the cert(s) allocates a receive buffer upon reception of first message with bit[31] set or deny/abort the request.

The receiver can also detect any loss of message during transfer:

If first message received does not have bit[31] set.

If “number of bytes to come” from message N-1 != (“number of bytes to come” + “certificate length”) from message N

Thanks,

From: Glen Kramer <glen.kramer@xxxxxxxxxxxx>
Date: Wednesday, September 11, 2024 at 11:56 AM
To: Marion, Jc <jmarion@xxxxxxxxx>, STDS-1904-4-TF@xxxxxxxxxxxxxxxxx <STDS-1904-4-TF@xxxxxxxxxxxxxxxxx>
Subject: RE: [1904.4 TF] [**EXTERNAL**] RE: 1904.4 Consensus call

Thank you, JC.

Yes, given the sizes of emerging keys and signatures, pacing the transfer by the receiver would be useful.

It probably would be a cleaner solution to specify a generic file transfer from the start. But it was specified only for the FW image transfer and the OLT and ONU state diagrams are very big and combine the download, verification, and activation functionalities all together. Extracting the download portion of the state diagram into a separate generic file transfer sub-clause is a lot of work. Also, as you said, we will need to specify a reverse process for file retrieval. Unless we have a strong reason to mess with the software download, I’d leave it alone. (But there might be such a reason. I will clarify in a separate email.)

Certificate download into ONU:

The easiest fix for pacing the transfer is to specify that ONU has to acknowledge every eOAM_Certificate_Request by a separate eOAM_Certificate_Response, and that the OLT shall not issue a new eOAM_Certificate_Request, until the previous one has been acknowledged. To pace the downstream transfer, the ONU would delay the response for up to 1 second (OAM timeout). However if the pause needs to be even longer, ONU should send an eOAM_Certificate_Response with code “Busy”. Then to resume transfer, ONU would send another eOAM_Certificate_Response with code “Ready”. When the OLT indicates that it has sent the last segment, the ONU sends a response containing the summary of the whole operation, i.e., ActionStatus and CertificateStatus.

Certificate retrieval from ONU:

Pacing the upstream data during the certificate retrieval can be done in a few ways. One way is to burden the DBA with pacing the MLID grants. But it probably would be better if we make US and DS transfers more or less symmetric. That means the OLT would request each block separately, and the ONU would only send one block (one eOAM_Certificate_Response) per each block request (eOAM_Certificate_Request). The Sequence field in eOAM_Certificate_Response would tell the OLT if there are more blocks available for retrieval.

I still don’t have a good suggestion on how to inform the recipient of the total size of the incoming file. It needs to be done once at the beginning of transfer and I don’t like the idea of including this field in every message. Making this field present only in the first message in a sequence complicates the parsing.

Should we have a separate message CertificateWriteRequest (similar to FileWriteRequest), where the OLT tells ONU to prepare to receive a file of a given size, and ONU either ACKs or NACKs that request, based on available memory? For the retrieval, the OLT will start with CertificateReadRequest, and the ONU will respond with CrtificateReadResponse containing the total length of the requested certificate?

Glen

From: Marion, Jc <000020b191edabf4-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Tuesday, September 10, 2024 5:11 PM
To: STDS-1904-4-TF@xxxxxxxxxxxxxxxxx
Subject: Re: [1904.4 TF] [**EXTERNAL**] RE: 1904.4 Consensus call

Dear IEEE chatmates,

After our discussion regarding transfer of cert and chain of certs, I realized that we may have an issue with the B1 (or B2) approach.

In short, how do we ensure that the receiver of data (ONU for a install and OLT for a retrieve) is not overflowing its receive buffer?

While we did not come up with actual size estimates for the cert (or chain of), we certainly talked about hundreds of kB.

I believe we need to have a way for the receiver to pace the transmission. Either we introduce a new action code (e.g. transmit ack) or we have another look at the file transfer.

During the call, we looked at it and put it aside for 2 reasons:

It does not offer the capability to retrieve a file.

There is no convention for file name. What file name should we use for NAC, DAC?

If we were to revisit the file transfer idea, I believe we would also need to add the indication of total size. So that the receiver of data can prepare a receive buffer or deny the transfer.

Thanks,

From: stds-1904-4-tf@xxxxxxxxxxxxxxxxx <stds-1904-4-tf@xxxxxxxxxxxxxxxxx> on behalf of Glen Kramer <000006d1020766de-dmarc-request@xxxxxxxxxxxxxxxxx>
Date: Monday, September 9, 2024 at 11:24 AM
To: stds-1904-4-tf@xxxxxxxxxxxxxxxxx <stds-1904-4-tf@xxxxxxxxxxxxxxxxx>
Cc: Hajduczenia, Marek <Marek.Hajduczenia@xxxxxxxxxxx>, Marek Hajduczenia <mxhajduczenia@xxxxxxxxx>, Craig Pratt <c.pratt@xxxxxxxxxxxxx>
Subject: [**EXTERNAL**] RE: 1904.4 Consensus call

Attached is a set of slides for tomorrow. There are 4 alternative methods (plus some options) presented, all different in their capabilities, efficiency, and impact on the draft.

Each method supports certificate chains that are arbitrarily large. However, these methods differ in allowing the individual certificates to be larger than 1489 bytes.

Glen

-----Original Appointment-----
From: Curtis Knittle <C.Knittle@xxxxxxxxxxxxx>
Sent: Monday, September 9, 2024 8:14 AM
To: STDS-1904-4-TF@xxxxxxxxxxxxxxxxx
Cc: Glen Kramer; Hajduczenia, Marek; Marek Hajduczenia; Craig Pratt
Subject: 1904.4 Consensus call
When: Tuesday, September 10, 2024 4:00 PM-5:00 PM (UTC-07:00) Mountain Time (US & Canada).
Where: https://cablelabs.zoom.us/j/91945986243?pwd=RQN8CawUwQEmi4E990LYjt6qYnNHZP.1&from=addon

Glen will have a few slides to go over several alternatives for removing the certificate size constraint, as we discussed under comment #8. Zoom info down below.

Curtis Knittle (CableLabs) is inviting you to a scheduled Zoom meeting.

CableLabs meeting requests should include a GRIP to identify the goals, the roles, the behavioral expectations and the process/agenda that will be followed. See below for details:

(G)oals of this meeting:
(R)oles for the participants:
(I)nterpersonal norms:
(P)rocess/Agenda:

CableLabs Secure Zoom Meeting
https://cablelabs.zoom.us/j/91945986243?pwd=RQN8CawUwQEmi4E990LYjt6qYnNHZP.1&from=addon
Meeting ID: 919 4598 6243
Password: 192152

CableLabs is hosting this Secure Virtual Meeting for invited participants. See the options below to join this secure meeting.

Zoom Client: For a full-featured and fully encrypted connection, use the above link to join the meeting via your Zoom client.

Browser-Only: Use the link below to "join from your browser" if you do NOT wish to download or utilize the Zoom client.
https://zoom.us/wc/join/91945986243#

Audio-Only Dial-In: Use the available phone numbers. You will be prompted for the meeting ID and password before joining.
One tap mobile
+17209289299,,91945986243#,,#,192152# US (Denver)
+12532158782,,91945986243#,,#,192152# US (Tacoma)

Dial by your location
+1 720 928 9299 US (Denver)
+1 253 215 8782 US (Tacoma)
+1 346 248 7799 US (Houston)
+1 669 900 6833 US (San Jose)
+1 301 715 8592 US (Washington DC)
+1 312 626 6799 US (Chicago)
+1 646 558 8656 US (New York)
+91 22 48 798 004 India
+86 10 8783 3177 China
Password: 192152
Find your local number: https://cablelabs.zoom.us/u/am95WDcR9

Join by SIP: Connect via audio-only from an remote conference room system.
91945986243@xxxxxxxxxxx

Join by H.323: Connect via full audio and video from a remote video conference room system.
162.255.37.11 (US West)
162.255.36.11 (US East)
69.174.57.160 (Canada)
Password: 192152

For more information on CableLabs Secure Virtual Meeting go to:
https://www.cablelabs.com/virtual_meeting

To unsubscribe from the STDS-1904-4-TF list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-1904-4-TF&A=1