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

Dhruv Dhody <> Tue, 20 August 2019 05:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8776E1200EC; Mon, 19 Aug 2019 22:44:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bgSQpJqhxWNl; Mon, 19 Aug 2019 22:44:40 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E0EAD1200CC; Mon, 19 Aug 2019 22:44:39 -0700 (PDT)
Received: by with SMTP id s21so9677589ioa.1; Mon, 19 Aug 2019 22:44:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PPC9NQFizlMsPI56G4CwH84q6M4X0Jbxi7CsfdBaeew=; b=ltkcHA0rqRAslhF62tnEpjW2L5+ZLR7O3bWzHETdzVkQISVsy6i2pK+Mye74SgljTK tMv5Ow+XtjGnhueQ9EMGUB4XVeOkq9AeNK6nHxLm9FZQnN1Ced+a/r79Mb64k4ZmI0FU AMZa7sxAygoLtVqCRRrAk0wO5ElUsGAKIHj0a7wo1A5PbXdkE0fJOADBITGaisTx0u3u h5J5x6JLyNIg1S0XpmEoIMIhB1KOX+xbasWj6wB+7gG1s6V/8H0pVQl4oWCkeMwL2305 aTUFDNjDSDE3+eCRzWITLvW3c9nUW+1E/eQ4pLhPCpFtdM/3FGMi+CT3PSuuiYibxrDP ofxA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PPC9NQFizlMsPI56G4CwH84q6M4X0Jbxi7CsfdBaeew=; b=Ilowp4gb63v30LEo1rMtbk0uSpSiO6SWOyiB4eD7MJhFNIKvENMK0a41pj6S8AkW1l ptaTPDaGTyqOYPtDz5Uz/fUUNkD7eFvenbdOy+f30iPOtdPvq03i18ClwPnKwIoYWia6 cTyPSciwds6KVAsk9U7GAw7VwhFYRJz1L8P2lcOiQ5bgNYogsKjKnShWcx/YpJralOYr k80OPEKmlop44EGxFOXDWNHo/5Wghtfw7Aqm6mvRmyh/MSvwfI6ztXRQzGNhmAWi0zda fvJkuDr08lHM6pgMjbg9qvN4ys8UDtIkYESA2GxCJOVvbLA0IgqX7tuuD6wJo2v9HUfC uc3g==
X-Gm-Message-State: APjAAAW8xtpvgBUd0cgLfRanddFM6abrnb93i+djYVqizEiBXPiBFvYp 4YciqStPcfzWARoxpw5xTHCz9YmIfG901gY6tLE=
X-Google-Smtp-Source: APXvYqzLEOoOIMieHRlyb+U5J0bPO86vyTb2y9KgsOQzjd7zEob0pi29vKEnjdhtczr8PI/E+GTXF+6vYiZK4jz7+qY=
X-Received: by 2002:a5d:890d:: with SMTP id b13mr27967654ion.124.1566279879089; Mon, 19 Aug 2019 22:44:39 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Dhruv Dhody <>
Date: Tue, 20 Aug 2019 11:14:02 +0530
Message-ID: <>
To: Shawn Emery <>
Cc: secdir <>,, Shawn Emery <>,
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [secdir] Review of draft-ietf-pce-lsp-control-request-07
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 20 Aug 2019 05:44:42 -0000

Hi Shawn,

<adding WG>

Thanks for your security review and comments.

On Mon, Aug 19, 2019 at 6:17 AM Shawn Emery <> wrote:
> 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.

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

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

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

Thanks for these, request authors to handle them.


> Shawn.
> --