Re: [secdir] Secdir review of draft-ietf-pce-gmpls-pcep-extensions-12

Julien Meuric <julien.meuric@orange.com> Fri, 23 November 2018 09:37 UTC

Return-Path: <julien.meuric@orange.com>
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 E1888130DFC; Fri, 23 Nov 2018 01:37:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_FAIL=0.001] autolearn=no 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 3sGn1CLlIsjE; Fri, 23 Nov 2018 01:37:32 -0800 (PST)
Received: from p-mail-ext.rd.orange.com (p-mail-ext.rd.orange.com [161.106.1.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6AED812896A; Fri, 23 Nov 2018 01:37:32 -0800 (PST)
Received: from p-mail-ext.rd.orange.com (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 073F156157A; Fri, 23 Nov 2018 10:37:12 +0100 (CET)
Received: from p-mail-int.rd.francetelecom.fr (p-mail-int.rd.francetelecom.fr [10.192.117.12]) by p-mail-ext.rd.orange.com (Postfix) with ESMTP id 01E1E561575; Fri, 23 Nov 2018 10:37:12 +0100 (CET)
Received: from p-mail-int.rd.francetelecom.fr (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C576D181516; Fri, 23 Nov 2018 10:37:14 +0100 (CET)
Received: from [10.193.71.219] (l-at13891.rd.francetelecom.fr [10.193.71.219]) by p-mail-int.rd.francetelecom.fr (Postfix) with ESMTP id 974A01814E5; Fri, 23 Nov 2018 10:37:14 +0100 (CET)
From: Julien Meuric <julien.meuric@orange.com>
To: Vincent Roca <vincent.roca@inria.fr>
Cc: The IESG <iesg@ietf.org>, secdir@ietf.org, draft-ietf-pce-gmpls-pcep-extensions.all@ietf.org
References: <BB25281B-EB32-40A3-A0BE-7D9375832608@inria.fr>
Organization: Orange
Message-ID: <ff49029f-7e1f-672f-1dc3-22bc1f0a3e87@orange.com>
Date: Fri, 23 Nov 2018 10:37:14 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <BB25281B-EB32-40A3-A0BE-7D9375832608@inria.fr>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-PMX-Version: 6.4.6.2792898, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2018.11.23.93016, AntiVirus-Engine: 5.56.0, AntiVirus-Data: 2018.11.23.5560000
X-PMX-Spam: Gauge=IIIIIIII, Probability=8%, Report=' MULTIPLE_RCPTS 0.1, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_2000_2999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, IN_REP_TO 0, LEGITIMATE_SIGNS 0, MSG_THREAD 0, MULTIPLE_REAL_RCPTS 0, REFERENCES 0, SINGLE_URI_IN_BODY 0, URI_WITH_PATH_ONLY 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CC_NAME 0, __CC_NAME_DIFF_FROM_ACC 0, __CC_REAL_NAMES 0, __CP_NOT_1 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __DQ_NEG_HEUR 0, __DQ_NEG_IP 0, __FORWARDED_MSG 0, __HAS_CC_HDR 0, __HAS_FROM 0, __HAS_MSGID 0, __HIGHBITS 0, __HTTPS_URI 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_TEXT_P 0, __MIME_TEXT_P1 0, __MIME_VERSION 0, __MOZILLA_USER_AGENT 0, __MULTIPLE_RCPTS_CC_X2 0, __NO_HTML_TAG_RAW 0, __REFERENCES 0, __SANE_MSGID 0, __SINGLE_URI_TEXT 0, __SUBJ_ALPHA_NEGATE 0, __SUBJ_REPLY 0, __TO_MALFORMED_2 0, __TO_NAME 0, __TO_NAME_DIFF_FROM_ACC 0, __TO_REAL_NAMES 0, __URI_IN_BODY 0, __URI_NOT_IMG 0, __URI_NO_MAILTO 0, __URI_NO_WWW 0, __URI_NS , __URI_WITH_PATH 0, __USER_AGENT 0'
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/DwCEhlq9QWOutm-J0l8Bp41uR90>
Subject: Re: [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:37:35 -0000

Merci Vincent !

Your review is appreciated. No doubt the authors will be able to address
your comments.

Cheers,

Julien


On 23/11/2018 10:05, Vincent Roca wrote:
> 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
>
>
>
>