Re: [sfc] John Scudder's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT)

mohamed.boucadair@orange.com Fri, 16 July 2021 12:01 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1CB23A33E0; Fri, 16 Jul 2021 05:01:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com
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 exJY2wLAG9wf; Fri, 16 Jul 2021 05:01:09 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97BD03A33E2; Fri, 16 Jul 2021 05:01:08 -0700 (PDT)
Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfednr27.francetelecom.fr (ESMTP service) with ESMTPS id 4GR8w24Lz6z4xJ8; Fri, 16 Jul 2021 14:01:06 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1626436866; bh=UjQ8RZt9nB00MrTlN3t1nzDkayx9uXf6iSf3jiryXok=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=l9hFUAL/k0J4gSNu6DKt9sj/U0FImHqZ7qp+pHxNJbffp3U56HVqagy00kk0dOhSW RDSCn1c/k2rD6Vg2R8d3RkuACEjYK2nNBLjVWQT8RAcS6v0ypgfybbJODIACPreQyw B/j8SBTPJCytkBsBuJNriE5JIbj6Z3zhwxox736D4WOE1Y5l0Y/+XlpE/GlGcU8QZ/ CphrezDhp1W+GgZoa7D4Vy1Bc7kRpncZRcYv4bBci5yu6GMH8siYHUR9pKQI0QIRBl MzMfNJll+puDMxDFLqkfMxgiNYkfC3GJJAL18m29QFFwAYJzDenwYLYaEnlk1UOj6i zlUgBOjnbvFsA==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfednr03.francetelecom.fr (ESMTP service) with ESMTPS id 4GR8w23VpSzDq83; Fri, 16 Jul 2021 14:01:06 +0200 (CEST)
From: mohamed.boucadair@orange.com
To: John Scudder <jgs@juniper.net>
CC: The IESG <iesg@ietf.org>, "gregimirsky@gmail.com" <gregimirsky@gmail.com>, "draft-ietf-sfc-nsh-integrity@ietf.org" <draft-ietf-sfc-nsh-integrity@ietf.org>, "sfc-chairs@ietf.org" <sfc-chairs@ietf.org>, "sfc@ietf.org" <sfc@ietf.org>
Thread-Topic: [sfc] John Scudder's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT)
Thread-Index: AQHXeQY6zKUu9wrRqk2rKi8P49lscKtDfi0AgAC2ogCAAUgnwA==
Date: Fri, 16 Jul 2021 12:01:04 +0000
Message-ID: <7006_1626436866_60F17502_7006_40_1_787AE7BB302AE849A7480A190F8B9330353C0103@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <162630455957.5451.359442420121368370@ietfa.amsl.com> <32352_1626325998_60EFC3EE_32352_250_1_787AE7BB302AE849A7480A190F8B9330353BF458@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <4646DA07-E18B-49C9-891C-116F05EF71E8@juniper.net>
In-Reply-To: <4646DA07-E18B-49C9-891C-116F05EF71E8@juniper.net>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.245]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/sfc/J-tgKLV_OyYRJ18Z-eMPbJArER8>
Subject: Re: [sfc] John Scudder's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT)
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Jul 2021 12:01:14 -0000

Hi John,

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : John Scudder [mailto:jgs@juniper.net]
> Envoyé : jeudi 15 juillet 2021 18:07
> À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>
> Cc : The IESG <iesg@ietf.org>; gregimirsky@gmail.com; draft-ietf-
> sfc-nsh-integrity@ietf.org; sfc-chairs@ietf.org; sfc@ietf.org
> Objet : Re: [sfc] John Scudder's No Objection on draft-ietf-sfc-nsh-
> integrity-06: (with COMMENT)
> 
> Hi Med,
> 
> A couple more comments inline below.
> 
[...]
> >> -----------------------------------------------------------------
> ---
> >> --
> >> COMMENT:
> >> -----------------------------------------------------------------
> ---
> >> --
> >>
> >> 1. Section 4.2
> >>
> >>   The authenticated encryption process takes as input four-octet
> >>   strings: a secret key (K), a plaintext (P), Additional
> >> Authenticated
> >>   Data (A) (which contains the data to be authenticated, but not
> >>   encrypted), and an Initialization Vector (IV).  The ciphertext
> >> value
> >>   (E) and the Authentication Tag value (T) are provided as
> outputs.
> >>
> >> As written, this means that each of these quantities is a 32 bit
> >> string, even P and A. I think you don’t mean that. If you mean
> each
> >> quantity is a string of octets, then move the hyphen: “takes as
> input
> >> four octet-strings“. (In the unlikely event you really do mean
> each
> >> quantity is a string of four octets, then “… takes as input four
> >> strings, each of four octets.”)
> >>
> >
> > [Med] Good catch. Changed to "as input four octet strings:"
> 
> I suggest using the hyphen as in the earlier comment: “as input four
> octet-strings”. This makes it unambiguous that “four” modifies
> “octet strings” and not just “octet”, which is still slightly
> ambiguous in the non-hyphenated version. Possibly the RFC Editor
> will have comments too, of course. If you distinctly prefer the non-
> hyphenated version, it’s not a big deal though.
> 
> …

[Med] Noted your preference, but I'm afraid that we will touch that text to address one of Ben's DISCUSS point. 

> 
> >> 3. Section 9.1
> >>
> >> You use “should“ in several places. As written, it isn’t clear if
> >> you’re indicating expectation, or requirement. After reading the
> >> whole section, I think you’re indicating requirement. This seems
> like
> >> a good place for use of the RFC 2119 style SHOULD keyword.
> >>
> >>
> >
> > [Med] The normative language is not used because these are somehow
> covered by other normative text in the main document. See for
> example the statements about providing key materials to authorized
> entities and so on.
> 
> OK. In that case I think it would be beneficial to choose some other
> rewrite, to make it unambiguous that you mean something closer to
> “shall” and less like “will”. The problem is that “should” could
> mean either. For example,
> 
> OLD:
>    No device other than the NSH-aware SFs in the SFC-enabled domain
>    should be able to update the integrity protected NSH data.
>    Similarly, no device other than the NSH-aware SFs and SFC proxies
> in
>    the SFC-enabled domain should be able to decrypt and update the
>    Context Headers carrying privacy-sensitive metadata.  In other
> words,
>    if the NSH-aware SFs and SFC proxies in the SFC-enabled domain
> are
>    considered fully trusted to act on the NSH data, only these
> elements
>    can have access to privacy-sensitive NSH metadata and the keying
>    material used to integrity protect NSH data and encrypt Context
>    Headers.
> 
> NEW:
>    It is expected that devices in the SFC-enabled domain will be
> configured
>    such that no device other than the NSH-aware SFs in the domain
>    will be able to update the integrity protected NSH data, and also
>    such that no device other than the NSH-aware SFs and SFC proxies
> in
>    the SFC-enabled domain will be able to decrypt and update the
>    Context Headers carrying privacy-sensitive metadata.  
> 

[Med] Thanks. Went with the following: 

   It is expected that specific devices in the SFC-enabled domain will
   be configured such that no device other than the classifiers (when
   reclassification is enabled), NSH-aware SFs, and SFC proxies will be
   able to update the integrity protected NSH data (Section 7.1), and
   also such that no device other than the NSH-aware SFs and SFC proxies
   will be able to decrypt and update the Context Headers carrying
   sensitive metadata (Section 7.1).

A full diff can be tracked at: https://tinyurl.com/nsh-integrity-latest 


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.