[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.
- [Pce] Roman Danyliw's Discuss on draft-ietf-pce-s… Roman Danyliw via Datatracker
- Re: [Pce] Roman Danyliw's Discuss on draft-ietf-p… Dhruv Dhody
- Re: [Pce] Roman Danyliw's Discuss on draft-ietf-p… Roman Danyliw