[Pce] Secdir last call review of draft-ietf-lsr-pce-discovery-security-support-05

Yaron Sheffer via Datatracker <noreply@ietf.org> Thu, 05 August 2021 19:24 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: expand-draft-ietf-lsr-pce-discovery-security-support.all@virtual.ietf.org
Delivered-To: pce@ietfa.amsl.com
Received: by ietfa.amsl.com (Postfix, from userid 65534) id 42FA83A1F65; Thu, 5 Aug 2021 12:24:37 -0700 (PDT)
X-Original-To: draft-ietf-lsr-pce-discovery-security-support.all@ietf.org
Delivered-To: xfilter-draft-ietf-lsr-pce-discovery-security-support.all@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 741873A1F5F; Thu, 5 Aug 2021 12:24:36 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Yaron Sheffer via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: draft-ietf-lsr-pce-discovery-security-support.all@ietf.org, last-call@ietf.org, lsr@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.35.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <162819147637.10274.7569490328477739918@ietfa.amsl.com>
Reply-To: Yaron Sheffer <yaronf.ietf@gmail.com>
Date: Thu, 05 Aug 2021 12:24:36 -0700
Resent-From: alias-bounces@ietf.org
Resent-To: yingzhen.ietf@gmail.com, jgs@juniper.net, dhruv.ietf@gmail.com, daniel@olddog.co.uk, acee@cisco.com, diego.r.lopez@telefonica.com, aretana.ietf@gmail.com, bill.wu@huawei.com, lsr@ietf.org, pce@ietf.org, chopps@chopps.org, martin.vigoureux@nokia.com, maqiufang1@huawei.com
Resent-Message-Id: <20210805192437.42FA83A1F65@ietfa.amsl.com>
Resent-Date: Thu, 05 Aug 2021 12:24:37 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/21YF7uaVJmRZ-8UrhwNX8nBueJQ>
Subject: [Pce] Secdir last call review of draft-ietf-lsr-pce-discovery-security-support-05
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 05 Aug 2021 19:24:38 -0000

Reviewer: Yaron Sheffer
Review result: Not Ready

This document defines a mechanism (a TLV) to advertise the PCE Protocol
security required (use of TCP-AO and its key ID, or alternatively use of TLS)
within the routing protocol being used.

* Sec. 3.1: I don't understand why "SHOULD advertise" and not MUST. Especially
given the strict client behavior defined later.

* Sec. 3.1: should we also say something about the case where both methods are
advertised, and whether we recommend for the client to use one of them over the
other?

* Sec. 4: typo (appears twice) - "to be carried in the PCED TLV of the for use".

* Sec. 7: this phrase appears to be essential to security of this mechanism:
"it MUST be insured that the IGP is protected for authentication and integrity
of the PCED TLV". I would expect more guidance: how can this property be
ensured in the relevant IGPs?

* Also, a possibly unintended consequence of this requirement is that if the
IGP cannot be protected in a particular deployment/product, this mechanism
would not be used. Please consider if this is likely to happen and whether we
want to forego PCEP transport security in such cases. My gut feel (not based on
experience in such networks) is that the threat models are different enough
that we should decouple the security of IGP from that of PCEP.