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

Dhruv Dhody <> Mon, 07 October 2019 10:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 75A141200F9; Mon, 7 Oct 2019 03:03:27 -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 TAcupoRtR7G2; Mon, 7 Oct 2019 03:03:25 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B62151200FA; Mon, 7 Oct 2019 03:03:25 -0700 (PDT)
Received: by with SMTP id b136so27189536iof.3; Mon, 07 Oct 2019 03:03:25 -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:content-transfer-encoding; bh=YG3Ft/Pgk5rIWL6utdTfx3zueqf5Yxc0mGwtFM6DJlA=; b=h3ymehVr/E3XnC/5p7DUBDvSyLWsk9RW8Y9s/XnvBKMljhn/ftX6Di7NXUL9SzmA0y 99RAmgGreWILZPzR0IpUCgyBuU3iOYNe9C6BgeUNPX8aRTFP9rhtXmEa2dgf441yc18R letQP9izdKthI70ia9JtQ7L9VwkYmD6cQ1KmsZtl8hwFKJr45tTXgFPS9wtOkjJCkDEH LsCppTsi7nLML9JNX3QJ1ZzyTNcNoN6IKRcrTQ/q3XBs2B7DxU1To6ChmMuyT71tGObw 80XfHwndhYctyhOS2VLP8qenyh0nHPyTfEUOIfWgr0IqJwBJBe0V8KIoAZ2jUpEtwt2O W6dw==
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:content-transfer-encoding; bh=YG3Ft/Pgk5rIWL6utdTfx3zueqf5Yxc0mGwtFM6DJlA=; b=M4/djdOwuQr59DSSWWZtSj4RYs3MCrGCwgpjGVS5OAs9tS96mVHc5yeysn9cxUdHMn 1j4qUMyz/3+mYeiz+hLe4dti5E/4MzCmi3TrI6Y8sVkS9mVtruM6n9bEptyYpLDk4Hyw FGYm67o0zahwuRAayw8ZzLuj+hhpnYW+qzIA1BPVR9+tCaPhc6gzietRqvI12hKbFU0U mS19SClvA3O0Zw35CIUkm/M0ws/etFavMBao8rqlqGMu5rSm7N24+8tae8TO8S/EuSA8 sWEzjY5EpY6Dc7H4S9P1HGyOHu+Ha/WaXopRbzaNZgHQmilOvU6YBDceGb5vkpa/JOi6 QmSw==
X-Gm-Message-State: APjAAAUHcWjBpe3FSkOxeAvBNS6vuncxJuYmIQ3xb6vKr++1MfDG4cla bQllTwFRj6b65sd9Rf4F4za4TALTCeRzkeZRU44=
X-Google-Smtp-Source: APXvYqwnTFLn3XFmoe7VcMDNVMIAeW5BXwx1EB4BIOBfRqj4rEW/TZ3q/JGwpImV39ZkYY+AT+L66NZxFsUyEqeoLEA=
X-Received: by 2002:a05:6638:692:: with SMTP id i18mr25377034jab.108.1570442604747; Mon, 07 Oct 2019 03:03:24 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Dhruv Dhody <>
Date: Mon, 7 Oct 2019 15:32:47 +0530
Message-ID: <>
To: Alvaro Retana <>
Cc: Hariharan Ananthakrishnan <>, pce-chairs <>,, The IESG <>,
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Pce] Alvaro Retana's No Objection on draft-ietf-pce-lsp-control-request-09: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Path Computation Element <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 07 Oct 2019 10:03:28 -0000

Hi Alvaro,

On Fri, Oct 4, 2019 at 4:49 PM Alvaro Retana <> wrote:
> On September 30, 2019 at 7:29:19 AM, Dhruv Dhody ( wrote:
> Dhruv:
> Hi!
> > ----------------------------------------------------------------------
> > ----------------------------------------------------------------------
> >
> > 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!
> Alvaro.