[secdir] SecDir review of draft-ietf-pce-pcep-service-aware-12

"Christian Huitema" <huitema@huitema.net> Thu, 08 September 2016 18:20 UTC

Return-Path: <huitema@huitema.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 B4EB412B258 for <secdir@ietfa.amsl.com>; Thu, 8 Sep 2016 11:20:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 KJXDP3x8Jd3S for <secdir@ietfa.amsl.com>; Thu, 8 Sep 2016 11:20:15 -0700 (PDT)
Received: from xsmtp11.mail2web.com (xsmtp31.mail2web.com [168.144.250.234]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5719612B22A for <secdir@ietf.org>; Thu, 8 Sep 2016 11:20:15 -0700 (PDT)
Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp11.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1bi3vp-0002UX-3q for secdir@ietf.org; Thu, 08 Sep 2016 14:20:14 -0400
Received: (qmail 11409 invoked from network); 8 Sep 2016 18:20:12 -0000
Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[24.16.156.113]) (envelope-sender <huitema@huitema.net>) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for <draft-ietf-pce-pcep-service-aware.all@ietf.org>; 8 Sep 2016 18:20:11 -0000
From: "Christian Huitema" <huitema@huitema.net>
To: <draft-ietf-pce-pcep-service-aware.all@ietf.org>, <iesg@ietf.org>, <secdir@ietf.org>
Date: Thu, 8 Sep 2016 11:20:09 -0700
Message-ID: <079401d209fd$a2e86200$e8b92600$@huitema.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdIJ+Pl2g+g4ww7xQtWNGqZcoaLQqQ==
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/AKsaDmrvhUKdB6bEychU67MYlts>
Subject: [secdir] SecDir review of draft-ietf-pce-pcep-service-aware-12
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
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: Thu, 08 Sep 2016 18:20:17 -0000

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.

This draft is ready.

The draft (draft-ietf-pce-pcep-service-aware-12), as the title indicates,
describes "Extensions to the Path Computation Element Communication
Protocol (PCEP) to compute service aware Label Switched Path (LSP)."
The extensions include to the path metric object and to the bandwidth 
Utilization The enable computation of latency, delay variation, packet loss 
and bandwidth utilization constraints for a path, and the selection of 
paths accordingly. The draft defines code points for various types of
computations, as well as new error types.

The security section states that these extensions do "not add any new 
security concerns beyond those discussed in [RFC5440] and [RFC5541] 
in itself." That's a true statement. This draft does not change the problem 
much, except for the addition of more and more potentially sensitive data 
in the routing messages. We could have a long and heated
discussion on the appropriateness of the mitigations described in the
security sections of these [RFC5440] and [RFC5541], such as TCP MD5, 
an optional use of IPSEC and IKE, and some forms of access control. In fact,

we could have that discussion for most routing related drafts. I am not
suggesting that we have this discussion right now.

-- Christian Huitema