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

Zero-overhead encryption or else?

All,

 

Here is the second thread to discuss the question in the subject. Here is what was discussed before:

 

= = = =

  1. 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.

  1. 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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature