Subject: [Pce] Alvaro Retana's No Objection on draft-ietf-pce-lsp-control-request-09: (with COMMENT)

From: Alvaro Retana via Datatracker <[email-masked]>
Date: Fri, 27 Sep 2019 03:08:36 -0700

Alvaro Retana has entered the following ballot position for
draft-ietf-pce-lsp-control-request-09: 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-pce-lsp-control-request/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I have a substantive comment and then some nits/editorial notes.

(1) It seems to me that any PCE can request control of an LSP.  Even if the
sessions are authenticated and encrypted, how does the PCC determine if it's ok
for the requesting PCE to ask for control?  §8.1 says that an "implementation
SHOULD allow the operator to configure the policy based on which it honors the
request to control the LSPs".  If the implementation doesn't allow the
configuration of policy, then it is possible for a rogue PCE to ask for control
of an LSP, and for the PCC to grant it.  Why is the ability to configure this
policy not REQUIRED?  I believe this case should be explicitly called out as a
vulnerability.

(2) Abstract: s/A Path Computation Client (PCC) has set up LSPs/A Path
Computation Client (PCC) that has set up LSPs

(3) §1: s/which PCE to delegate the orphaned LSP/which PCE to delegate the
orphaned LSP to

(4) §1: s/a simple extension, by using this a PCE can/a simple extension, by
using it a PCE can

(5) In §3 the new C Flag is called the "LSP-Control Request Flag", but §7.1
only uses "LSP-Control".  Please be consistent; the more descriptive name is
probably better.

---

From: Dhruv Dhody <[email-masked]>
Date: Mon, 30 Sep 2019 16:58:42 +0530

Hi Alvaro,

Let me take a stab at this. Authors can join in -

> https://datatracker.ietf.org/doc/draft-ietf-pce-lsp-control-request/

Thanks for pointing this out. Since RFC 8231 uses SHOULD wrt policy, I
would consider not changing that. We can highlight that the PCC is the
ultimate arbiter on if the delegation should be made and to which PCE.
Even after delegation, the PCC can take back control anytime. But at
the same time blindly accepting control request could be a problem!

I propose this text in Security section -

   A PCC is the ultimate arbiter of delegation.  As per [RFC8231], a
   local policy at PCC is used to influence the delegation.  A PCC can
   also revoke the delegation at any time.  A PCC MUST NOT blindly trust
   the control requests and SHOULD take local policy and other factors
   into consideration before honoring the request.

> only uses "LSP-Control".  Please be consistent; the more descriptive name is

These all looks like reasonable requests, authors - please update!

Thanks!
Dhruv