Hi JC,
You are exactly right. Options 3 and 4 are exactly the same, because the eOAM spec only defines attributes and associated TLVs. There is no mentioning in the spec of how the OAM clients must group the TLVs into OAMPDUs, except the requirements that the context TLV must precede the associated variable descriptors or variable containers within the same OAMPDU. So, both options 3 and 4 would be equally compliant.
An alternative approach that would nail down the exact OAMPDU format and avoid a TLV size limit is to define a new OAMPDU opcode, as was done for software download OAMPDUs. The Key exchange in 1904.1 and in DPoE also relied on a special OAMPDU opcode that didn’t use any TLVs.
In my mind, using dedicated OAMPDU formats is a less preferred solution, because it requires custom parsing rules. If the key negotiation is possible using our generic TLV parsing rules then we should do it this way, IMO.
Glen
From: Marion, Jc <jmarion@xxxxxxxxx>
Sent: Tuesday, October 10, 2023 10:19 AM
To: Glen Kramer <000006d1020766de-dmarc-request@xxxxxxxxxxxxxxxxx>; stds-1904-4-tf@xxxxxxxxxxxxxxxxx
Subject: Re: [**EXTERNAL**] Update on eOAM attributes for the initial key exchange
Hi Glen.
Good catch! I agree that using sequence TLV would be cumbersome.
Between option 3 and 4, I would favor 3 because option 4 is a special case of 3 where the set requests are factorized into one OAMPDU. Which is something that can be done with all requests of same type (SET/GET). Assuming the error handling is done properly.
If we present option 3, an implementation using option 4 would be compliant with the spec.
If we present option 4, it can give the impression that the two set requests must be inside same OAMPDU. And an implementation using option 3 could be seen as NOT be compliant with the spec.
Thanks,
Jc
From: stds-1904-4-tf@xxxxxxxxxxxxxxxxx <stds-1904-4-tf@xxxxxxxxxxxxxxxxx> on behalf of Glen Kramer <000006d1020766de-dmarc-request@xxxxxxxxxxxxxxxxx>
Date: Monday, October 9, 2023 at 5:56 PM
To: stds-1904-4-tf@xxxxxxxxxxxxxxxxx <stds-1904-4-tf@xxxxxxxxxxxxxxxxx>
Subject: [**EXTERNAL**] Update on eOAM attributes for the initial key exchange
Hi All,
I wanted to give you a brief update on the work on defining attributes for the initial key exchange. On 9/15 I shared the aInitialKeyMethod attribute. The attached document contains that attribute again (but with some updates) plus an attribute called aInitialKeyParameters.
These two attributes represent the Option #5 of the key exchange, as we discussed in https://www.ieee1904.org/4/meeting_archive/2023/08/tf4_2308_kramer_4_handshake.pdf.
This option, it turns out, has a complication. One of the elliptic curves requires to exchange points, each of which consists of two 512-bit values. Thus, one such point occupies a maximum TLV size. We cannot pack a point together with a curve ID into one TLV (without complicating the parsing operation by using the sequence TLVs). Thus, it seems we have to switch to options #3 and #4. In other words, the Curve ID and points (public keys) will be in separate attributes and will be carried in different TLVs. These TLVs can be sent in one OAMPDU (option #4) or in separate OAMPDUs (option #3).
Let me know if you have any feedback on this.
Thank you,
Glen
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
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