Hi Marek,
This is a strange turn of events. When we first discussed the MACSec vs. Zero-Overhead in January, I believe you made a comment that 5% of extra overhead is significant enough to prefer the Zero-Overhead method (Sorry if I misunderstood what you said). I believe Mark made a similar comment too. At the same time, no specific technical issues were identified with zero-overhead method and there weren’t any strong objections to it besides the concerns of its future post-quantum cipher-agility.
So, I assumed that we had an informal agreement to proceed with the Zero-overhead method and I reiterated that understanding before I presented my slides at the last consensus call. To be clear, the latest proposal relies on the EAPOL/RADIUS Authentication (per IEEE 802.1X) and EAPOL/MKA (again, per IEEE802.1X) for the first key exchange (SAK). Once SAK is exchanged, the OLT and the ONU establish a secure management channel using the Zero-Overhead method. All subsequent key exchanges are carried via OAMPDUs under the already encrypted management channel. Using OAMPDUs allows the same messages to be used for multicast and unicast key exchanges, and even allows the same OAMPDU to carry multiple keys (one unicast key per ONU and multiple multicast keys - one for each multicast LLID configured in a given ONU).
Now, we seem to be back at the same discussion again. It is unfortunate if for 1.5 months the group members had different assumptions, but good that it surfaced now rather than later. I feel before proceeding further with any technical development, we need to make a formal decision on what encryption method to use.
All,
Before we attempt to take a vote, let’s make sure we consider all relevant technical arguments. Please reply to this email with your pros and cons for both of these two methods. I will aggregate it all in one document and then we will discuss and take a take a vote, probably at the next WG call.
Thank you,
Glen
Glen,
I am not aware of any security incidents for 10G-EPON, but I have limited visibility into NA deployments only.
I believe that the concern with zero encryption that led us towards MACSec was the fact that we do not have any spec to fall back on this in case, and would have to write everything ourselves. I am not a fan of MACSec, especially in the upstream direction, where packet sizes are smaller and overhead will be higher. I do like the fact that MACSec solution has a larger security expert forum vetting the system and keeping it up to date.
Regards
Marek
On 3/24/23 15:32, Glen Kramer wrote:
All,
Here is the second thread to discuss the question in the subject. Here is what was discussed before:
= = = =
- 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.
[SG] This makes sense; however, it does provide a downgrade attack path through the configuration or management of the ONU. This is mitigated by using secure channels to configure and manage the ONU. Note that the attack against ViaSat’s KA-SAT network last spring was enabled in part by a management network vulnerability after the adversaries had compromised the management network via a compromised VPN.
- 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] Are we still considering zero encryption as a viable option? Did I miss anything?
[SG] An explicit enable/disable message again provides for a downgrade attack. The message should occur after authentication and the message should be integrity protected (HMAC/CMAC). AND, its by definition got to occur before encryption starts, or an unencrypted message, so if an adversary has found a way to do packet injection, preventing the downgrade relies entirely on authentication and integrity.
= = = =
I think before we discuss whether the encryption is enabled by default or by an explicit message, we need to address Marek’s question whether we are still considering zero-overhead encryption. I though in one of the earlier calls, most have agreed that 5% of average overhead in MACSec (32 bytes per frame) is too much for PON. For flows consisting exclusively of short frames, the overhead can be close to 50%. I was under the assumption that we all were in agreement to continue with the zero-overhead method for 25G-EPON and I don’t remember any statements that it wasn’t a viable option. There were concerns about zero-overhead encryption not being as vetted as MACSec, but no specific loopholes identified as far as I could tell. Of course, it is possible that I missed that discussion earlier.
Zero-overhead encryption was also used specified DPoE and referenced by 1904.1 for 10G-EPON. Does anyone know of any security incidents related to the zero-overhead encryption strength in 10G-EPON deployments?
Let’s use this thread to summarize all the specific technical concerns related to zero-overhead method and discuss their severity or possible solutions.
If anyone has a proposal to use an alternative encryption method (like MACsec), let’s also discuss it now.
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