Sounds good to me, I am just offering the view from the deployment side of things.
Marek
From: Glen Kramer <glen.kramer@xxxxxxxxxxxx>
Sent: Friday, October 25, 2024 12:17 PM
To: Marek Hajduczenia <mxhajduczenia@xxxxxxxxx>; Glen Kramer <000006d1020766de-dmarc-request@xxxxxxxxxxxxxxxxx>
Cc: stds-1904-4-tf@xxxxxxxxxxxxxxxxx
Subject: RE: opinions needed for trunk protection
Marek,
I hear you. But it is also true for many other PON features – they are discussed and added to the standard, but are slow at being deployed.
I am not particularly in favor of just deleting the trunk protection scheme. I think it would be weird that this feature exists in 1G-EPON and 10G-EPON specifications, but is removed in 25G-EPON and 50G-EPON. Besides, removing it is actually more draft work than fixing it. To remove it, we need to also remove some management attributes, modify some other attributes that are shared between the tree and the trunk protection schemes, update PICS, and modify the text referencing the removed material.
I think it is easier to fix this feature. If it is indeed the case that the protected security data cannot or should not be shared among the different OLTs in different COs, the easiest fix is to say that the new OLT has to perform the startup sequence on its own, I.e., the ONUs get re-authenticated and encryption is re-established. We will need to get rid of 150 ms switching time target (not a mandatory requirement anyway).
Annex 9A is not needed anymore. It describes two methods of deducing RTTs by the backup OLT without doing the MPCP discovery. One method doesn’t work if encryption is enabled. The other method is trivial to describe in just a few sentences in the main clause.
I’ll work on modifying the trunk protection scheme, unless I hit another wall down the road.
Glen
From: Marek Hajduczenia <mxhajduczenia@xxxxxxxxx>
Sent: Thursday, October 24, 2024 4:37 AM
To: Glen Kramer <000006d1020766de-dmarc-request@xxxxxxxxxxxxxxxxx>
Cc: stds-1904-4-tf@xxxxxxxxxxxxxxxxx
Subject: Re: opinions needed for trunk protection
Personal 2 cents, nothing more - I have not seen a live deployment of this feature to date for 1G or 10G PON. It has been spoken about, debated, etc., but getting it deployed is a separate topic altogether.
Given the added complexity when OLT and ONU are mutually authenticated, I'd vote for a feature drop and extraction.
We *could* go the route of how SAE is implemented in WPA3 in the wireless world but it will just add complexity to an already complex and unused feature of the PON systems.
Marek
On Wed, Oct 23, 2024 at 6:43 PM Glen Kramer <000006d1020766de-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:
Hi All,
I was reviewing the Trunk Protection section and found that assumptions made in 1904.1 and carried over into 1904.4 may not hold anymore.
I’d like to get some feedback on my question below. To remind you, here is a drawing of trunk-protected PON:
The two OLTs can be in different central offices and the fiber length would be very different for the primary and backup trunks. The 1904.1 assumed that the backup OLT derives or is given the RTTs for all working ONUs and when the primary OLT or trunk fails, the backup OLT can just take over and start granting all registered ONUs.
The problem I see for 1904.4 is that now we have mandatory authentication and encryption. Is it reasonable to assume that the backup OLT can access ONU’s authentication and encryption data, including the encryption keys that exist within the primary OLT?
I don’t think this is feasible without creating major security problems.
If authentication data and keys are not available to the backup OLT, then the protection switching event should be followed by these steps:
1) ONU and OLT stop sending all user data
2) Synchronize MPCP clocks at the ONUs based on backup OLT MPCP clock
3) Synchronize CipherClocks at the ONUs (for IV derivation)
4) Re-authenticate all ONUs
5) Derive the initial keys for every ONU.
6) Start symmetric encryption (AES256)
7) Enable user data
I don’t think we can avoid most of the steps of a normal ONU startup sequence shown below. Maybe we can avoid steps 1 and 6, if the backup OLT gets ONUs IDs and RTTs externally and the ONU preserves the configuration during the HOLDOVER period.
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