[secdir] Secdir review of draft-ietf-pce-rfc6006bis

Charlie Kaufman <charliekaufman@outlook.com> Thu, 31 August 2017 23:09 UTC

Return-Path: <kivinen@iki.fi>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 4F50A132A89; Thu, 31 Aug 2017 16:09:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.119
X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Lsc0TMFz8zxz; Thu, 31 Aug 2017 16:09:50 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7166132FB9; Thu, 31 Aug 2017 16:09:47 -0700 (PDT)
Received: from fireball.acr.fi (localhost []) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v7VN9jHq017392 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 1 Sep 2017 02:09:45 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v7VN9jl9009650; Fri, 1 Sep 2017 02:09:45 +0300 (EEST)
Resent-From: kivinen@iki.fi
Resent-Message-ID: <22952.38713.497174.495741@fireball.acr.fi>
Resent-Date: Fri, 1 Sep 2017 02:09:45 +0300
Resent-To: secdir@ietf.org, iesg@ietf.org, draft-ietf-pce-rfc6006bis.all@ietf.org
Thread-Topic: Secdir review of draft-ietf-pce-rfc6006bis
Thread-Index: AQHTE+LwKl1xiooPeEezcBh2V63s7Q==
Message-ID: <CY4PR1701MB1926723B19518B2895C016D9DF8F0@CY4PR1701MB1926.namprd17.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Exchange-Organization-RecordReviewCfmType: 0
x-ms-publictraffictype: Email
From: Charlie Kaufman <charliekaufman@outlook.com>
To: "secdir\@ietf.org" <secdir@ietf.org>, "iesg\@ietf.org" <iesg@ietf.org>, "draft-ietf-pce-rfc6006bis.all\@tools.ietf.org" <draft-ietf-pce-rfc6006bis.all@tools.ietf.org>
Content-Type: multipart/alternative; boundary="_000_CY4PR1701MB1926723B19518B2895C016D9DF8F0CY4PR1701MB1926_"
MIME-Version: 1.0
X-Edit-Time: 1 min
X-Total-Time: 0 min
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/rSiIZstKBV-jkW36RP1vuA2O-fE>
Subject: [secdir] Secdir review of draft-ietf-pce-rfc6006bis
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
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>
Date: Thu, 31 Aug 2017 23:09:51 -0000
X-Original-Date: Sun, 13 Aug 2017 03:24:19 +0000
X-List-Received-Date: Thu, 31 Aug 2017 23:09:51 -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. Document editors and WG chairs should treat these comments just like any other last call comments.

Summary: No significant security issues

This document is a "refreshing" of rfc6006 (Extensions to PCEP for Point-to-Multipoint Traffic Engineering Label Switched Paths) to incorporate errata that have accumulated over the last seven years. There may be some small additional changes.

One minor change was made to Security considerations, and it was a good change, but I fear makes the security considerations somewhat internally inconsistent. That change was to change a recommendation to use TCP-AO to a recommendation to use TLS. TLS is a more logical protocol to use in this context, but the security considerations also references RFC5440, what mandates TCP-MD5 and recommends TCP-AO (which was not available when RFC5440 was written).

I'm not sure the best way to resolve this... probably to leave it as is. Someday, RFC5440 should be updated.

Security considerations in this document discusses that dangers of someone impersonating a client for the purpose of denying service or learning about the network configuration, and RFC5440 talks about that dangers of eavesdropping in learning what the client is doing. It does not discuss whether there are important threats posed by someone impersonating a PCEP server and returning bad routing information. I suspect that might be a more serious threat then either of the other attacks, but don't know enough about how the protocol is used to know for sure.

In any case, all the considerations mentioned above probably belong in RFC5440 (PCEP) rather than this document concerning extensions.

 --Charlie Kaufman