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

From: Alvaro Retana <[email-masked]>
Date: Fri, 4 Oct 2019 04:19:01 -0700

On September 30, 2019 at 7:29:19 AM, Dhruv Dhody ([email-masked])
wrote:

Dhruv:

Hi!

> ----------------------------------------------------------------------
> 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.

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.

Two points:

(1) How is “MUST NOT blindly trust” normatively enforceable?  Even if it
was, the mechanism to take off the blindfolds is the policy…

(2) Even if policy is configured, a rogue PCE can still take control of the
LSP; for example, the policy was misconfigured, or simply because the PCE
has been compromised.

In all these cases the problem is not so much that a PCE took control, but
the actions that it can take with the LSP: change its characteristics,
reroute it, shut it down, etc…

Thanks!

Alvaro.

---

From: Dhruv Dhody <[email-masked]>
Date: Mon, 7 Oct 2019 15:32:47 +0530

Hi Alvaro,

On Fri, Oct 4, 2019 at 4:49 PM Alvaro Retana <[email-masked]> wrote:
>
> On September 30, 2019 at 7:29:19 AM, Dhruv Dhody ([email-masked]) wrote:
>
> Dhruv:
>
> Hi!
>
> > 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
> > 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.
> >
>
> (1) How is “MUST NOT blindly trust” normatively enforceable?  Even if it was, the mechanism to take off the blindfolds is the policy…
>

You are right, better to avoid normative language here.

> (2) Even if policy is configured, a rogue PCE can still take control of the LSP; for example, the policy was misconfigured, or simply because the PCE has been compromised.
>
> In all these cases the problem is not so much that a PCE took control, but the actions that it can take with the LSP: change its characteristics, reroute it, shut it down, etc…
>

I made the same point to Ben in my reply. The actions that the PCE can
take on a delegated LSP is covered by RFC 8231: a PCC could reject the
parameters set by the PCC and it could also revoke delegation. Policy
related text in RFC 8231 uses SHOULD.

Does the ability of a PCE to 'request' control over an LSP in itself
raise the bar? IMHO it falls well within the existing protocol policy
parameters of RFC 8231 (and also RFC 8281: PCE-initiated LSP). For the
sake of consistency I feel SHOULD is the way to go.

Thanks!
Dhruv