Subject: Re: [Pce] Secdir last call review of draft-ietf-pce-hierarchy-extensions-10

From: <[email-masked]>
Date: Mon, 13 May 2019 20:22:36 +0100

Hi Kyle, 

Thank you for the review, it is most appreciated!

We have addressed all your comments in the latest version of our I-D (v11) but were advised to hold off posting until after the IESG telechat. Comments inline (DK>>) on how we addressed said comments: 

-----Original Message-----
From: Kyle Rose via Datatracker <[email-masked]> 
Sent: 15 April 2019 21:18
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Secdir last call review of draft-ietf-pce-hierarchy-extensions-10

Reviewer: Kyle Rose
Review result: Has Nits

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written primarily for the benefit of the security area directors. Document
editors and WG chairs should treat these comments just like any other last call
comments.

For background, Wikipedia has the following to say about PCE:

q( Routing can be subject to a set of constraints, such as Quality of Service
(QoS), policy, or price. Constraint-based path computation is a strategic
component of traffic engineering in MPLS, GMPLS and Segment Routing networks.
It is used to determine the path through the network that traffic should
follow, and provides the route for each Label Switched Path (LSP) that is set
up.

Path computation has previously been performed either in a management system or
at the head end of each LSP. But path computation in large, multi-domain
networks may be very complex and may require more computational power and
network information than is typically available at a network element, yet may
still need to be more dynamic than can be provided by a management system.

Thus, a PCE is an entity capable of computing paths for a single or set of
services. A PCE might be a network node, network management station, or
dedicated computational platform that is resource-aware and has the ability to
consider multiple constraints for sophisticated path computation. PCE
applications compute label switched paths for MPLS and GMPLS traffic
engineering. )

The document is nearly ready. In addition to numerous grammatical errors
throughout, I see one minor but substantive issue. In section 6.1.2, the last
sentence reads:

q( This means
   that a parent PCE must be configured with the identities and security
   credentials of all of its child PCEs, or there must be some form of
   shared secret that allows an unknown child PCE to be authorized by
   the parent PCE. )

A secret shared by more than two parties cannot be used to establish identity.
If there are two, then assuming exfiltration and reflection attacks are not
part of your threat model, each party knows it is talking to the single other
legitimate possessor of the shared secret. If there are more than two, this is
no longer the case. That said, in this case it's not clear you need to identify
individual child PCEs, and so (notwithstanding potential impersonation attacks
in a shared secret scheme) you may wish to shorten this sentence to:

q( This means that a parent PCE MUST* be able to cryptographically authenticate
requests from child PCEs. )

The choice of authentication scheme can then be left to implementors, or
recommendations to a different document. You might add a sentence to the
security considerations section suggesting that multi-party shared key
authentication schemes are not recommended for inter-domain relationships
because of the potential for impersonation and repudiation and for the
operational difficulties should revocation be required.

DK>> Thanks for the comments and especially the text update! We have used your suggestion directly, and also expanded the security discussion. The I-D now includes the following text in Section .1.2.  Parent PCE

   The parent PCE must only accept path computation requests from
   authorized child PCEs.  If a parent PCE receives requests from an
   unauthorized child PCE, the request should be dropped.  This means 
   that a parent PCE MUST be able to cryptographically authenticate 
   requests from child PCEs.
   
   Multi-party shared key authentication schemes are not recommended for
   inter-domain relationships because of the potential for impersonation
   and repudiation and for the operational difficulties should 
   revocation be required.
   
   The choice of authentication schemes to employ may be left to 
   implementers of H-PCE and are not discussed further in this document.
<<

*Whether this "MUST" should be BCP 14 language or not is unclear to me.

DK>> We felt we should mandate "MUST" in this document and then pickup discussion on methods and schemes in a future document as required.  

BR, Dan and the other authors.

---

From: Kyle Rose <[email-masked]>
Date: Mon, 13 May 2019 16:08:19 -0400

Sounds great! I look forward to reviewing the new version.

Thanks,
Kyle

On Mon, May 13, 2019 at 3:22 PM <[email-masked]> wrote:

> We have addressed all your comments in the latest version of our I-D (v11)
> but were advised to hold off posting until after the IESG telechat.
> Comments inline (DK>>) on how we addressed said comments:
>