| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Thank you, Marek. You bring many good points that provide more food for thought. Please see below.
From: Marek Hajduczenia <mxhaj79@xxxxxxxxx>
Hi Glen, Some thoughts / feedback
[GK] I don’t have a strong argument for continued support of 128-bit key. I thought that it was possible that instead of generating keys in the OLT itself, operators will use some external security server. And that external infrastructure may or may not support 256-bit keys in various head ends. Maybe this is not the case. Just want to observe two things: 1) The 128 and 256 refers to only the key size. The AES engine itself is always 128 bit wide. 2) The newest ITU-T PON recommendation G.9804 includes encryption methods with both key sizes: AES-128 (mandatory), AES-256 (mandatory), Camellia-128, Camellia-256, and SM4(-128) Does anyone have any concerns with not supporting AES-128?
[GK] To use zero-overhead encryption, the ONU must first receive the full 48-bit extended MPCP clock from the OLT. Without this value, encryption cannot operate, so it cannot be enabled by default. Correspondingly, the OAMPDU that delivers the extended MPCP clock to the ONU signifies to the ONU that the NMS/OLT wants it to use encryption. I called this OAMPDU “Encryption Configuration”. It has only two fields: enable/disable flag and 48-bit MPCP clock. I think there must be a certain script or a sequence of configuration operations that is executed to configure new ONU before it can perform its duties. Rules, Queues, LLIDs, VLAN tags – all need to be provisioned. Enabling the encryption should be set as the first step in this process.
[GK] Yes, the broadcast traffic is never encrypted because every ONU must receive it. But this question asked a different thing. Just looking at the problem from the ONU perspective. When ONU receives an envelope header, it checks if it has one of ONU’s assigned LLIDs. If not, the envelope is ignored. If it is, then ONU checks the encryption enable flag. If encryption is enabled, the ONU checks the Key index and determines what key it should use to decrypt the envelope payload. But what should ONU do if the encryption flag is set to disabled? This could be a broadcast LLID or any LLID assigned to this ONU. This envelope arrived unencrypted. The ONU has to make a decision. It can drop this envelope, or it can process it without applying the decryption. I don’t think discarding such unencrypted envelope is the right approach. For example, it could be a multicast OAMPDU instructing ONUs to switch to protection path. If OLT took the trouble of sending it, ONU should not unilaterally decide that it was not important. Now, the follow-up question. When OLT switches from key 0 to key 1 and indicates this in the downstream envelope header, the ONU uses this indication to also switch the encryption from key 0 to key 1 in the upstream direction. Shouldn’t ONU similarly follow the OLT’s lead, if for a given LLID, the OLT changed the encryption enabled flag to encryption disabled? ONU can follow this lead and disable the encryption for the same LLID in the upstream direction (if it was bidirectional LLID). Alternatively, the ONU can ignore the flag it received from the OLT and continue encrypting this LLID in the upstream. To me, ONU always following the OLT lead seems like a more robust solution.
Regards Marek On 3/7/23 15:22, Glen Kramer wrote:
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 |
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature