[Pce] Secdir last call review of draft-ietf-pce-stateful-pce-auto-bandwidth-10

Daniel Franke via Datatracker <noreply@ietf.org> Wed, 28 August 2019 19:43 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: pce@ietf.org
Delivered-To: pce@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 418711200E3; Wed, 28 Aug 2019 12:43:06 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Daniel Franke via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: pce@ietf.org, ietf@ietf.org, draft-ietf-pce-stateful-pce-auto-bandwidth.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.100.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Daniel Franke <dafranke@akamai.com>
Message-ID: <156702138622.1106.12957431760424204090@ietfa.amsl.com>
Date: Wed, 28 Aug 2019 12:43:06 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/vVBEiszLiR0uU1EYxP7Bfc3LyIc>
Subject: [Pce] Secdir last call review of draft-ietf-pce-stateful-pce-auto-bandwidth-10
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: Wed, 28 Aug 2019 19:43:06 -0000

Reviewer: Daniel Franke
Review result: Ready

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.

The protocol that this draft extends is one intended to be run over TLS and
conducted between two endpoints controlled by the same administrative
authority. The Security Considerations section duly makes this explicit and
references another RFC which thoroughly discusses what can occur when these
assumptions are violated. When the protocol is run as intended, there is no
communication across trust boundaries and therefore the potential security
concerns are minimal.