Re: [Teas] Eric Rescorla's No Objection on draft-ietf-teas-lsp-diversity-08: (with COMMENT)

["Adrian Farrel" <[e-mail]>]

Agree with Dieter here.
 
The risk in this case is that a 3rd party could see the path key in flight (control plane or PCEP) and then issue a query to the PCE to expand the key.
The protection is that the PCE knows who is allowed to ask for expansion, PCEP is session-based, PCEP security now exists.
 
A
 
From: Teas [mailto:[e-mail]] On Behalf Of Dieter Beller
Sent: 31 October 2017 17:58
To: Eric Rescorla; The IESG
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [Teas] Eric Rescorla's No Objection on draft-ietf-teas-lsp-diversity-08: (with COMMENT)
 
Hi Eric,

my apologies for the late response - it was difficult for me finding time in the last weeks to address the IESG review comments.

Please find the answers to your comments in-line below.

Could you please let us know if your comments are adequately addressed.


Thanks,
Dieter and co-authors


On 30.08.2017 22:20, Eric Rescorla wrote:
Eric Rescorla has entered the following ballot position for
draft-ietf-teas-lsp-diversity-08: No Objection
 
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
 
 
Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
 
 
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-teas-lsp-diversity/
 
 
 
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
 
I'm not sure that the security considerations here are accurate. Specifically,
the PAS seems like it might potentially leak information about paths, because
if I am able to learn someone else's PAS values, I can tell if they are routed
along the same paths as I am. Is that correct? If so, it seems like it might be
useful to recommend self-encrypting PAS values so that two identical paths
given to separate people have different PAS values.

We do not believe that encryption at the UNI is required because the Path key (PCE approach) or the PAS information is not shared between the core network
and all edge nodes connected to the core network (see Figure 1). It is assumed that only a particular edge node receives a Path key or PAS information for an
LSP that this edge node initiated before requesting another LSP that shall meet certain diversity constraints insid the core network. Path keys and PAS is only
meaningful in the context of a pair or several LSPs oriiginating from the same edge node. These LSPs shall meet diversity constraints inside the core network in
order to avoid that they will all fail together due to a failure in the core network - a typical failure is a link cut.

Moreover, Path key or a PAS are already abstract information and do not allow the edge node to infer any topological information of the core network.



 
 
Also, it seems like it S 2.3 would be clearer if you factored out the algorithm
for processing the XRO values from the differential treatment depending on the
L bit. Perhaps you could just have one list and use [SHOULD (L=1), MUST(L=0)]
or something?
 
A combined list would be an alternative way to describe the processing rules for the L-flag in section2.3.
On the other hand, we believe that nothing is technically wrong with the current description, where two lists are used.
So, we would like to keep the description as is.