Sorry – late to this discussion.
For backup OLTs, I would agree that the best solution is to reauthenticate and establish new traffic encryption keys. Even if you could keep all the encryption keys synced between
the OLTs, it seems like there are all sorts of transition edge cases to account for. I can’t see how that kind of redundancy couldn’t still be implemented by a vendor to support a kind of “virtualized OLT” – but spec-ing that doesn’t seem necessary.
Fail-over would be pretty straight forward authentication-wise. Presumably the backup OLT would spread out the re-authentication activity in such a way as to not get overloaded
during switch-over – which it should be able to easily do since it initiates the auth process. If a central AAA server isn’t used for authenticating ONUs, then you’d want it to maintain a copy of the ONU trust store (any intermediate CA(s) used for issuance
of NACs to ONUs) on the backup OLT(s). Allow/deny lists (for NAC- or DAC-based ONU authentication) would similarly either need to be centralized or mirrored.
I don’t know if you were strictly asking about private encryption keys. But OLT private authentication keys (asymmetric keys presented during EAP-TLS) are slightly more interesting.
Currently, ONUs do not authenticate OLTs (we haven’t specified mutual authentication). But this is pretty easily accommodated as well.
- Backup OLTs can authenticate with ONUs using certs signed by a common root or CA cert (operator or third-party root) -
with that root being deployed into the ONUs trust stores. This would enable the ONU to authenticate against any number or all of an operator’s OLTs.
- Each OLT could have its own discreet self-signed cert and the ONUs provisioned with the individual certs of all OLTs that
the operator deems “authentic”.
Option 1 is better IMHO as it would allow backup OLTs and/or PON splits to be deployed without refreshing ONU trust stores. But the operator can pick their poison based on the
level of PKI they require/desire.
cp
p.s. I would like to consider drafting dual authentication elements, even if it doesn’t get in the spec.
From:
stds-1904-4-tf@xxxxxxxxxxxxxxxxx <stds-1904-4-tf@xxxxxxxxxxxxxxxxx> on behalf of Curtis Knittle <0000243ed8852903-dmarc-request@xxxxxxxxxxxxxxxxx>
Date: Tuesday, October 29, 2024 at 2:56 PM
To: mxhajduczenia@xxxxxxxxx <mxhajduczenia@xxxxxxxxx>, 'Glen Kramer' <glen.kramer@xxxxxxxxxxxx>, 'Glen Kramer' <000006d1020766de-dmarc-request@xxxxxxxxxxxxxxxxx>
Cc: stds-1904-4-tf@xxxxxxxxxxxxxxxxx <stds-1904-4-tf@xxxxxxxxxxxxxxxxx>
Subject: RE: opinions needed for trunk protection
|
Glen,
I trust your assessment of the work required here, and support making changes to fix to feature. I also agree that much of the initial ONU registration steps will need to be
repeated with the backup OLT.
Curtis
From: stds-1904-4-tf@xxxxxxxxxxxxxxxxx <stds-1904-4-tf@xxxxxxxxxxxxxxxxx>
On Behalf Of mxhajduczenia@xxxxxxxxx
Sent: Friday, October 25, 2024 12:19 PM
To: 'Glen Kramer' <glen.kramer@xxxxxxxxxxxx>; 'Glen Kramer' <000006d1020766de-dmarc-request@xxxxxxxxxxxxxxxxx>
Cc: stds-1904-4-tf@xxxxxxxxxxxxxxxxx
Subject: RE: opinions needed for trunk protection
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
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