Subject: [secdir] Review of draft-ietf-pce-lsp-control-request-07

From: Shawn Emery <[email-masked]>
Date: Sun, 18 Aug 2019 18:47:40 -0600

Reviewer: Shawn M. Emery
Review result: Ready

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.

This draft specifies an extension to the Path Computation Element
communication
Protocol (PCE) that allows a PCE to request control of Label Switched Paths
(LSPs).

The security considerations section does exist and discusses a new DoS
vector
that this draft creates.  The attack involves sending control requests for
delegate
control of all of its LSPs to the Path Computation Client (PCC).  The
proposed
solution is to set a threshold rate of the delegation requests for the PCC
per PCE.
I agree with the proposed solution, though I don't know if guidance can be
provided
on what these thresholds would be per environment.

The section goes on to refer to RFC 8231 to justify that the PCP extension
should
be deployed with authenticated and encrypted sessions in TLS using RFC 8253.
I agree with this prescription as well else an attacker would now be able
to take
control over all local LSPs with this extension.  I think that this should
at least be
stated if an attacker is able to compromise a PCE.

General comments:

None.

Editorial comments:

s/sends PCRpt/sends a PCRpt/
s/also specify/also specifies/
s/all its/all of its/
s/If threshold/If the threshold/
s/explicitly set aside/explicitly excluded/

Shawn.
--

---

From: Dhruv Dhody <[email-masked]>
Date: Tue, 20 Aug 2019 11:14:02 +0530

Hi Shawn,

<adding WG>

Thanks for your security review and comments.

On Mon, Aug 19, 2019 at 6:17 AM Shawn Emery <[email-masked]> wrote:
> This draft specifies an extension to the Path Computation Element communication
> Protocol (PCE) that allows a PCE to request control of Label Switched Paths (LSPs).
>
> The security considerations section does exist and discusses a new DoS vector
> that this draft creates.  The attack involves sending control requests for delegate
> control of all of its LSPs to the Path Computation Client (PCC).  The proposed
> solution is to set a threshold rate of the delegation requests for the PCC per PCE.
> I agree with the proposed solution, though I don't know if guidance can be provided

As you noted the document does not provide default for the threshold
as it dependent on the deployment/environment. The same is true for
RFC 8231.

> The section goes on to refer to RFC 8231 to justify that the PCP extension should
> I agree with this prescription as well else an attacker would now be able to take
> control over all local LSPs with this extension.  I think that this should at least be

The security consideration includes "...either by spoofing messages or
by compromising the PCE itself".

> s/explicitly set aside/explicitly excluded/

Thanks for these, request authors to handle them.

Thanks!
Dhruv

---

From: Mahend Negi <[email-masked]>
Date: Sun, 25 Aug 2019 22:42:53 +0530

Hi Shawn/Dhruv,

Thanks for the review and clarifications, we have fixed all the editorial
comments in new version.

New Version:
https://tools.ietf.org/html/draft-ietf-pce-lsp-control-request-08

Version Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-lsp-control-request-08

Regards,
Mahendra

---

From: Shawn Emery <[email-masked]>
Date: Sun, 25 Aug 2019 13:17:39 -0600

The changes look good.  Thank you for the follow-up.

Shawn.
--