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

Return-Path: <aretana.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 4550A12092F; Fri, 4 Oct 2019 04:19:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.737
X-Spam-Level:
X-Spam-Status: No, score=-0.737 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 X3D1SNNcHyKz; Fri, 4 Oct 2019 04:19:03 -0700 (PDT)
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (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 7AA22120931; Fri, 4 Oct 2019 04:19:03 -0700 (PDT)
Received: by mail-ed1-x532.google.com with SMTP id p10so5508334edq.1; Fri, 04 Oct 2019 04:19:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=llW+3kDSH4B9U7GDR4Q2rQLYJyOiYz0pbgTCjtGjNo0=; b=VTZnC8DU+1CkaTbLfAPhlBBNTKAtkuLHvHfXLaRoDjXoc6I+wnQkcjbXXlQo53KoDf qStx5KjIDYEZCY1azoFcM6kNF6drb8CT3TAqHdxO1HtMObLDqfVA+JKpqqHbGP91aBiA wlyC1SKI9sP+tUHFkE4MsaA+3RCX79B6YG+2iM6DnHKj78xlNuo6tShF9lS3oytSogNA hoBUdmN1KP6aDTTY42NwKTI+FNo4WZI0oItry9p+eheHGlLZrBLH+F9QdLWOdxtTPZtq AbeOtMIgrcZGdgY17dj2yZxUPQAuM7sUTprGgY3o06gQPja1XkQjtpxLMZgeLfGa2G7X D8ZA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=llW+3kDSH4B9U7GDR4Q2rQLYJyOiYz0pbgTCjtGjNo0=; b=ODpiS5uxikc7Px3ccAb3hvDSsfWzhj7N6hJRD3wOhPLVRIeDJ3+6lRIKDxrufcAgWI KCzXjDFfIXbJPpXJMzFq2FlnIx18uPy8H7atwzZYKzyZOe/C2yBMkNHuDcSiCiWTZycF yYbIHXSaZH+R0qwnL6LWGIsFPFLFmQtY3Tc6PMsiHyQg3wxHm28Q+PpT7Kl8VDRpLQmn 8kHQIy5qssFQve1esVc9dXbrHAbYGPxDLVNlvbnDvPBvDAPsRvEq7ISLMHPJ07qgHT/h bwLEe01i+kos1vGAYWTOkelCs5nxenJUQehFuGHUWbyzoqyvme3fwBMPZVWtTt+g3Qo6 ouKA==
X-Gm-Message-State: APjAAAVqWk7waDfuSjxbu6oRYhzuU6yo4X3ngTLv9L88s/ZTy2CMI+uc K6R5kTCrUELEqk3q0DF7pe+4sW7frpjgYPeslgL0P63u
X-Google-Smtp-Source: APXvYqwszc7veXBFWHoccOaltfgCaOP/ORqxZHgF9+ZrWpW1c30uZe5PPhoHrKUP+3Mz+HshFH9dF2pwYPIE44o9WFU=
X-Received: by 2002:a50:ea8c:: with SMTP id d12mr14604935edo.87.1570187942060; Fri, 04 Oct 2019 04:19:02 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 4 Oct 2019 04:19:01 -0700
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, 4 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)
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: Fri, 04 Oct 2019 11:19:05 -0000

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.