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

[Dhruv Dhody <[e-mail]>]

Hi Alvaro,

On Fri, Oct 4, 2019 at 4:49 PM Alvaro Retana <[e-mail]> wrote:
>
> On September 30, 2019 at 7:29:19 AM, Dhruv Dhody ([e-mail]) 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…
>

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

> Thanks!
>
> Alvaro.