[secdir] Secdir review of draft-ietf-pce-gmpls-pcep-extensions-12
Vincent Roca <vincent.roca@inria.fr> Fri, 23 November 2018 09:06 UTC
Return-Path: <vincent.roca@inria.fr>
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 5EE7F130DE5; Fri, 23 Nov 2018 01:06:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 1cF88LueGXS9; Fri, 23 Nov 2018 01:05:58 -0800 (PST)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (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 1C242130DC3; Fri, 23 Nov 2018 01:05:53 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.56,269,1539640800"; d="scan'208,217";a="286549580"
Received: from ral043r.vpn.inria.fr ([128.93.178.43]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Nov 2018 10:05:51 +0100
From: Vincent Roca <vincent.roca@inria.fr>
Content-Type: multipart/alternative; boundary="Apple-Mail=_692A3B7B-DF6F-480D-9EF5-A4797B31D764"
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
Message-Id: <BB25281B-EB32-40A3-A0BE-7D9375832608@inria.fr>
Date: Fri, 23 Nov 2018 10:05:49 +0100
To: The IESG <iesg@ietf.org>, secdir@ietf.org, draft-ietf-pce-gmpls-pcep-extensions.all@ietf.org
X-Mailer: Apple Mail (2.3445.101.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/fbNn4zEie0A8Q9cdD_F1YBswwaE>
Subject: [secdir] Secdir review of draft-ietf-pce-gmpls-pcep-extensions-12
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 23 Nov 2018 09:06:00 -0000
Hello, 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. Summary: Ready with issues The Security Considerations section provides a good introduction to the risks. However my main concern is the lack of discussion around security policies. After reading this section, we have the feeling that TLS alone is sufficient to secure the GMPLS PCE WRT the three attacks described. With scenario 1, a fundamental part of the solution consists in setting up security policies: what is acceptable or not in terms of path? It may be discussed in the two references mentioned in the last paragraph, but even in that case, the way the current section is written is misleading. I have two additional comments: ** Ambiguous text: it is said o Message deciphering: As in the previous case, knowledge of an infrastructure can be obtained by sniffing PCEP messages. Message deciphering suggests the message is encrypted but the attacker has enough knowledge to decrypt it. I'm not sure it's what the authors mean. I think there's a confusion in the use of "deciphering" which in security explicitely refers to encryption (https://en.wikipedia.org/wiki/Cipher). ** Ambiguous text: it is said "Authentication can provide origin verification, message integrity and replay protection,..." Àuthentication of the two peers on the one hand, and integrity/replay protection on the other hand, are different services. There's probably a package where these three services are bundled together, but that's a design choice. I suggest changing a little bit the sentence to avoid this confusion. Typo: ** Section 6: "A legitimate PCC could requests" : s/requests/request/ Cheers, Vincent
- [secdir] Secdir review of draft-ietf-pce-gmpls-pc… Vincent Roca
- Re: [secdir] Secdir review of draft-ietf-pce-gmpl… Julien Meuric
- Re: [secdir] Secdir review of draft-ietf-pce-gmpl… Cyril Margaria