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

Alvaro Retana <aretana.ietf@gmail.com> Fri, 04 October 2019 11:19 UTC

From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <CAB75xn6kg9TkxV=S=o7BXDVQ5GpLkU1g+zG4XFwrGn9JkQ9RrQ@mail.gmail.com>
References: <156957891627.12410.17887218088455702680.idtracker@ietfa.amsl.com> <CAB75xn6kg9TkxV=S=o7BXDVQ5GpLkU1g+zG4XFwrGn9JkQ9RrQ@mail.gmail.com>
MIME-Version: 1.0
Date: Fri, 04 Oct 2019 04:19:01 -0700
Message-ID: <CAMMESszh_=70bAr3jxzETpBpR_5Vid4v+e+_cR1ZTE8icmF+YQ@mail.gmail.com>
To: Dhruv Dhody <dhruv.ietf@gmail.com>
Cc: Hariharan Ananthakrishnan <hari@netflix.com>, pce-chairs <pce-chairs@ietf.org>, draft-ietf-pce-lsp-control-request@ietf.org, The IESG <iesg@ietf.org>, pce@ietf.org
Content-Type: multipart/alternative; boundary="00000000000084663d059413dea2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/3F273z8Fq-ahS75sN_558jrOCXc>
Subject: Re: [Pce] Alvaro Retana's No Objection on draft-ietf-pce-lsp-control-request-09: (with COMMENT)
Precedence: list

On September 30, 2019 at 7:29:19 AM, Dhruv Dhody (dhruv.ietf@gmail.com)
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.

[Pce] Alvaro Retana's No Objection on draft-ietf-… Alvaro Retana via Datatracker
Re: [Pce] Alvaro Retana's No Objection on draft-i… Dhruv Dhody
Re: [Pce] Alvaro Retana's No Objection on draft-i… Alvaro Retana
Re: [Pce] Alvaro Retana's No Objection on draft-i… Dhruv Dhody