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

Dhruv Dhody <dhruv.ietf@gmail.com> Mon, 07 October 2019 10:03 UTC

Return-Path: <dhruv.ietf@gmail.com>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75A141200F9; Mon, 7 Oct 2019 03:03:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TAcupoRtR7G2; Mon, 7 Oct 2019 03:03:25 -0700 (PDT)
Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B62151200FA; Mon, 7 Oct 2019 03:03:25 -0700 (PDT)
Received: by mail-io1-xd2b.google.com with SMTP id b136so27189536iof.3; Mon, 07 Oct 2019 03:03:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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: <156957891627.12410.17887218088455702680.idtracker@ietfa.amsl.com> <CAB75xn6kg9TkxV=S=o7BXDVQ5GpLkU1g+zG4XFwrGn9JkQ9RrQ@mail.gmail.com> <CAMMESszh_=70bAr3jxzETpBpR_5Vid4v+e+_cR1ZTE8icmF+YQ@mail.gmail.com>
In-Reply-To: <CAMMESszh_=70bAr3jxzETpBpR_5Vid4v+e+_cR1ZTE8icmF+YQ@mail.gmail.com>
From: Dhruv Dhody <dhruv.ietf@gmail.com>
Date: Mon, 7 Oct 2019 15:32:47 +0530
Message-ID: <CAB75xn5DPt6NkY1vJkupbPP7waPT+tFK01j5vd0ns249nZz4+w@mail.gmail.com>
To: Alvaro Retana <aretana.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: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/zPSAPMUObJPhI-DkBuI3_i-HMk4>
Subject: Re: [Pce] Alvaro Retana's No Objection on draft-ietf-pce-lsp-control-request-09: (with COMMENT)
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=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 <aretana.ietf@gmail.com> wrote:
>
> 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…
>

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.