| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Happy to bring in more discussion, Glen.
Please see inline in red
[mh0308] I personally think we should minimize the key size count, not add to the complexity of supporting different encryption schemes. I understand what the driver was on the ITU-T side, but I feel we do not have to deal with that honestly. My vote would be for 256b key only.Thank you, Marek. You bring many good points that provide more food for thought. Please see below.
From: Marek Hajduczenia <mxhaj79@xxxxxxxxx>
Sent: Tuesday, March 7, 2023 4:46 PM
To: STDS-1904-4-TF@xxxxxxxxxxxxxxxxx
Subject: Re: [1904.4 TF] [1904-ANWG] Slides used for discussion last night
Hi Glen,
Some thoughts / feedback
- I do not see much value in supporting 128b keys if 256b keys seem to be the new norm. Given both supported, I would default to 256b key anyway, because why not. Unless there is some substantial pro of still doing 128b keys, I am not sure what it buys us, really.
[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?
[mh0308] Are we still considering zero encryption as a viable option? Did I miss anything?
- I see value in allowing ONU to operate with the disabled encryption - there will be T/S cases where encryption will need to come down to be able to capture traffic in plain text. Encryption should be enabled by default, though, if that makes any sense.
- An explicit enable/disable message makes sense to me, especially since it is relatively low implementation cost and allows for more interoperable behavior between different implementations. The ONU should still use default enabled encryption, to avoid most misconfiguration problems (someone forgets to enable it, etc.)
[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.
[mh0308] In all honesty, the general trend in operator's world is to encrypt everything when we can just because we can (costs us zero, right). While I do not necessarily see the add-on value of encrypting encrypted traffic, most operators will likely opt for solution where everything, even broadcast, is encrypted, just because it eliminated potential security exposures. If we have encryption on already, it does not add to complexity, right? The counter-argument is that if everyone is within the same encryption group, that means also a potentially malicious ONU might be in on it.
- I am not sure I see much use for the mix of encrypted / unencrypted envelopes, unless we see much use case for transmitting multicast / broadcast accessible to all users. I am wondering, though, whether such partial encryption has any advantages. If I wanted to T/S link, I would just disable the encryption for the ONU altogether.
[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.
[mh0308] Why wouldn't we encrypt OAM as well? That is a potential security exposure.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.
[mh0308] I am not sure I follow the problem here - to me, as you said, ONU (is expected to) always do what the OLT tells it to. Encryption enabled, that would mean downstream and upstream. Disabled, the same thing. I do not see much value in doing downstream encryption only (seems like lot of implementation complexity for little gain).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.
- I do not have much input on when the encryption ought to be started, outside of "as soon as possible" once the link is established, providing that the ONU is not explicitly told to disable the encryption via the explicit control message.
Regards
Marek
On 3/7/23 15:22, Glen Kramer wrote:
Thank you Steve!
Based on this contribution and the discussion we had at the last meeting, I updated my slides. I removed slides that are not relevant anymore and tried to make the remaining slides look more like a proposal. There are still many questions that the WG need to resolve. They are summarized on the last 4 slides.
Let’s discuss the attached slides on the reflector first. Then we can have another call a week or two from now.
I moved this email from the WG reflector to TF4 reflector. All, please respond with your suggestions and concerns.
Glen
From: Steve Goeringer <s.goeringer@xxxxxxxxxxxxx>
Sent: Wednesday, March 1, 2023 8:18 AM
To: STDS-1904-WG@xxxxxxxxxxxxxxxxx
Subject: [1904-ANWG] Slides used for discussion last night
Let me know if you have questions. Thanks for inviting me contribute to the discussion.
Steve Goeringer
Distinguished Technologist
Director, Emerging Security Technologies
CableLabs®
To unsubscribe from the STDS-1904-WG list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-1904-WG&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
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