[Pce] Roman Danyliw's Discuss on draft-ietf-pce-stateful-pce-p2mp-12: (with DISCUSS)

Roman Danyliw via Datatracker <noreply@ietf.org> Wed, 10 April 2019 14:30 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 56699120021; Wed, 10 Apr 2019 07:30:07 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Roman Danyliw via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-pce-stateful-pce-p2mp@ietf.org, Adrian Farrel <adrian@olddog.co.uk>, pce-chairs@ietf.org, adrian@olddog.co.uk, pce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.95.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw <rdd@cert.org>
Message-ID: <155490660734.22896.13528098840634992626.idtracker@ietfa.amsl.com>
Date: Wed, 10 Apr 2019 07:30:07 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/E_xFJi3d1DwUxDrEtE4ugjNEz9w>
Subject: [Pce] Roman Danyliw's Discuss on draft-ietf-pce-stateful-pce-p2mp-12: (with DISCUSS)
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, 10 Apr 2019 14:30:07 -0000

Roman Danyliw has entered the following ballot position for
draft-ietf-pce-stateful-pce-p2mp-12: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-p2mp/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

The Security Considerations section has numerous helpful and appropriate
references.  Thanks for tracking them down.  However, explicit, additional text
is required to help identify, de-duplicate and deconflict the “relevant
guidance” provided by them.

(1) Per “it is important that implementations conform to the relevant security
requirements of [RFC5440], [RFC8306] and [RFC8231], and [RFC8281]”:

** [RFC8231] says “RECOMMENDED that these PCEP extensions only be activated on
authenticated and encrypted sessions across PCEs and PCCs belonging to the same
administrative authority, using Transport Layer Security (TLS) [PCEPS], as per
the recommendations and best current practices in [RFC7525]”.  Good language. 
This draft again re-states “Securing the PCEP session using Transport Layer
Security (TLS) [RFC8253], as per the recommendations and best current practices
in [RFC7525], is RECOMMENDED.”  Why say that twice?  Is there something new
there?

** Per Section 10.4 of RFC5440 from 2009, IPSec is a MAY and Section 10.2 makes
TCP-MD5 a MUST.  The more recent (2017) RFC8306 and RFC8253 reference TLS and
TCP-AO, no IPSec.  RFC8306 explicitly says don’t use TCP-MD5.  What is the
RECOMMENDED approach today?

(2) Per “[s]ecuring the PCEP session using Transport Layer Security (TLS)
[RFC8253], as per the recommendations and best current practices in [RFC7525],
is RECOMMENDED”, how should the guidance on both of these drafts be
synthesized?  Specifically, this sentence is unclear on whether the the robust
TLS 1.2 requirements in Section 3.4 of RFC8253 are RECOMMENDED, and/or whether
the Security Considerations/Section 7 of RFC8253, which undermine these robust
requirements by saying administrators MAY allow the usage weak ciphersuites,
apply.  This sentence also cites RFC7525 which makes statements that weak
(NULL) cipher suites MUST NOT be negotiated in contradiction to the RFC8253
Section 7 guidance.

Given the discussion of TLs, some additional treatment of TLS v1.3 is needed,
recognizing that RFC7525 does recommend “v1.2+”

Again, there is helpful guidance across all of the references.  Please provide
more textually narrative about which specific sections apply on the references.