Re: [secdir] Secdir last call review of draft-ietf-pce-hierarchy-extensions-10

<daniel@olddog.co.uk> Mon, 13 May 2019 19:22 UTC

Return-Path: <dk@danielking.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90AD712023C for <secdir@ietfa.amsl.com>; Mon, 13 May 2019 12:22:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=danielking-net.20150623.gappssmtp.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 SwSBaP339QqS for <secdir@ietfa.amsl.com>; Mon, 13 May 2019 12:22:40 -0700 (PDT)
Received: from mail-wr1-x442.google.com (mail-wr1-x442.google.com [IPv6:2a00:1450:4864:20::442]) (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 EE5CA1200C5 for <secdir@ietf.org>; Mon, 13 May 2019 12:22:39 -0700 (PDT)
Received: by mail-wr1-x442.google.com with SMTP id c5so16513939wrs.11 for <secdir@ietf.org>; Mon, 13 May 2019 12:22:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielking-net.20150623.gappssmtp.com; s=20150623; h=sender:from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=AN56KssOHU9dO2JLrRY/lBaRCmDeUrk+NIplJQv/4YA=; b=mG3vu42YnQgudlf/ZVrajWSIxxkqUXbG/Uyu8bohgWcXaWsa6TfsC+bqotmGrL5OU7 fO/WsWjx+KNRxGVdrTqwKuyFMbP6qNwEJdnkGcCV2TsB2qfqzeUP2rIfcHhmhnX+A+d4 oDvagyhcEj3YSbZV17Vu4Pa0JwOT7LV3/rJeiVAvsQxNcEXeTDPxxDCg2zONyI2F56Jj qUZpvNr4Gv7VKZKWEDQ2RBsp5mPvfmg4stRqwA65KTB6JhdnBDdQQE69HPfKASntHQzq WAMlJU+9wu01WHGmjl9oLFaL/b76GNrvNNkOwmGX5Ntgr1lx4EIX8huQk0UvFqZ5XhtR YJKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:references:in-reply-to:subject :date:message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=AN56KssOHU9dO2JLrRY/lBaRCmDeUrk+NIplJQv/4YA=; b=dbli1jwQ2ZG2tFPgtuBOmLEVRp5qyhQKbL08ZEeiiCYbi2xj5XfuV/NOeH0PMgdMpB O38BnsPb0N1f0rqBGQsPnj+uCbLogLx3YE2mdj4BakATAqfEsga/fTof3Uju/tWTYrix ZFLXnrRGjMIBTJu4A+FaYyBVz52vINilkd4jqZgUSzcpqY/DObeb8blJrBaMd0gcvL/N dHV8/asjtnLNDtE5Y7PSKVDFT7C6WZm72F22q1L1rvGxUtyV7Oes2XFF1KoB+3Xrbrdd TEXgLuym8viukZeU4tCxqKhnnn9cicZlATz16l6HpbzzvMXmVULE5jXYLDxyQCZzbGq5 aedw==
X-Gm-Message-State: APjAAAXG8e0nRBasyipoij+ct14UJ3UNP/+Ug4AWnnj0A/S8dDmjml5k fnA9PFLpJLOyVN0qSUdbHfAWBQ==
X-Google-Smtp-Source: APXvYqxq20FeoZnoKnZKR02O3ZiE6PnLF508tszVtQs+z6OPVVQrI3g8rsXPF4cS+l/B/1wn8A95Vw==
X-Received: by 2002:adf:8bc5:: with SMTP id w5mr4593047wra.226.1557775358235; Mon, 13 May 2019 12:22:38 -0700 (PDT)
Received: from CIPHER ([88.202.231.139]) by smtp.gmail.com with ESMTPSA id b18sm8321723wrx.75.2019.05.13.12.22.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 May 2019 12:22:37 -0700 (PDT)
Sender: Daniel King <dk@danielking.net>
X-Google-Original-Sender: "Daniel King" <dk@danielking.net>
From: daniel@olddog.co.uk
To: 'Kyle Rose' <krose@krose.org>, secdir@ietf.org
Cc: draft-ietf-pce-hierarchy-extensions.all@ietf.org, pce@ietf.org, oscar.gonzalezdedios@telefonica.com
References: <155535945259.10773.14556389726269462856@ietfa.amsl.com>
In-Reply-To: <155535945259.10773.14556389726269462856@ietfa.amsl.com>
Date: Mon, 13 May 2019 20:22:36 +0100
Message-ID: <007701d509c1$39535b80$abfa1280$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQIbdTdcm2N8ImEWYCoeoc+jBrkXfKXclcrA
Content-Language: en-gb
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/KEZOzclNjFb0gW5lzxjek2Q368k>
Subject: Re: [secdir] Secdir last call review of draft-ietf-pce-hierarchy-extensions-10
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 May 2019 19:22:42 -0000

Hi Kyle, 

Thank you for the review, it is most appreciated!

We have addressed all your comments in the latest version of our I-D (v11) but were advised to hold off posting until after the IESG telechat. Comments inline (DK>>) on how we addressed said comments: 


-----Original Message-----
From: Kyle Rose via Datatracker <noreply@ietf.org> 
Sent: 15 April 2019 21:18
To: secdir@ietf.org
Cc: draft-ietf-pce-hierarchy-extensions.all@ietf.org; pce@ietf.org; ietf@ietf.org
Subject: Secdir last call review of draft-ietf-pce-hierarchy-extensions-10

Reviewer: Kyle Rose
Review result: Has Nits

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.

For background, Wikipedia has the following to say about PCE:

q( Routing can be subject to a set of constraints, such as Quality of Service
(QoS), policy, or price. Constraint-based path computation is a strategic
component of traffic engineering in MPLS, GMPLS and Segment Routing networks.
It is used to determine the path through the network that traffic should
follow, and provides the route for each Label Switched Path (LSP) that is set
up.

Path computation has previously been performed either in a management system or
at the head end of each LSP. But path computation in large, multi-domain
networks may be very complex and may require more computational power and
network information than is typically available at a network element, yet may
still need to be more dynamic than can be provided by a management system.

Thus, a PCE is an entity capable of computing paths for a single or set of
services. A PCE might be a network node, network management station, or
dedicated computational platform that is resource-aware and has the ability to
consider multiple constraints for sophisticated path computation. PCE
applications compute label switched paths for MPLS and GMPLS traffic
engineering. )

The document is nearly ready. In addition to numerous grammatical errors
throughout, I see one minor but substantive issue. In section 6.1.2, the last
sentence reads:

q( This means
   that a parent PCE must be configured with the identities and security
   credentials of all of its child PCEs, or there must be some form of
   shared secret that allows an unknown child PCE to be authorized by
   the parent PCE. )

A secret shared by more than two parties cannot be used to establish identity.
If there are two, then assuming exfiltration and reflection attacks are not
part of your threat model, each party knows it is talking to the single other
legitimate possessor of the shared secret. If there are more than two, this is
no longer the case. That said, in this case it's not clear you need to identify
individual child PCEs, and so (notwithstanding potential impersonation attacks
in a shared secret scheme) you may wish to shorten this sentence to:

q( This means that a parent PCE MUST* be able to cryptographically authenticate
requests from child PCEs. )

The choice of authentication scheme can then be left to implementors, or
recommendations to a different document. You might add a sentence to the
security considerations section suggesting that multi-party shared key
authentication schemes are not recommended for inter-domain relationships
because of the potential for impersonation and repudiation and for the
operational difficulties should revocation be required.

DK>> Thanks for the comments and especially the text update! We have used your suggestion directly, and also expanded the security discussion. The I-D now includes the following text in Section .1.2.  Parent PCE

>>
   The parent PCE must only accept path computation requests from
   authorized child PCEs.  If a parent PCE receives requests from an
   unauthorized child PCE, the request should be dropped.  This means 
   that a parent PCE MUST be able to cryptographically authenticate 
   requests from child PCEs.
   
   Multi-party shared key authentication schemes are not recommended for
   inter-domain relationships because of the potential for impersonation
   and repudiation and for the operational difficulties should 
   revocation be required.
   
   The choice of authentication schemes to employ may be left to 
   implementers of H-PCE and are not discussed further in this document.
<<

*Whether this "MUST" should be BCP 14 language or not is unclear to me.

DK>> We felt we should mandate "MUST" in this document and then pickup discussion on methods and schemes in a future document as required.  

BR, Dan and the other authors.