Re: [sfc] Éric Vyncke's Discuss on draft-ietf-sfc-nsh-integrity-06: (with DISCUSS and COMMENT)

[tirumal reddy <[e-mail]>]

Thanks Eric for reviewing the revised draft and clearing the DISCUSS.
Thanks a lot to Martin for following up with you.

Cheers,
-Tiru

On Mon, 13 Sept 2021 at 19:20, Eric Vyncke (evyncke) <[e-mail]>
wrote:

> Hello Tiru,
>
>
>
> Your proposed text indeed addresses my remaining issue.
>
>
>
> I am clearing my DISCUSS in the coming minutes as Med also addressed
> earlier my other DISCUSS points.
>
>
>
> Regards and sorry for belated reply,
>
>
>
> -éric
>
>
>
> PS: your reply was lost in the ‘fury’ ot the IETF week, sorry about that
> and please thank your AD, Martin Vigoureux, for sending me today a gentle
> nudge...
>
> PS2: if IESG members do not respond, then ALWAYS feel free to send a
> reminder as we are mere overloaded human beings :-)
>
>
>
> *From: *tirumal reddy <[e-mail]>
> *Date: *Wednesday, 14 July 2021 at 13:58
> *To: *Eric Vyncke <[e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>om>, The
> IESG <[e-mail]>rg>, "[e-mail]" <
> [e-mail]>gt;, "[e-mail]" <
> [e-mail]>gt;, "[e-mail]" <[e-mail]>rg>, "
> [e-mail]" <[e-mail]>
> *Subject: *Re: Éric Vyncke's Discuss on draft-ietf-sfc-nsh-integrity-06:
> (with DISCUSS and COMMENT)
>
>
>
> Hi Eric,
>
>
>
> We will update text in Section 7.2 as follows to address the comment :
>
>
>
> The NSH imposer sets the MAC field to zero and then computes the message
> integrity for the target NSH data (depending on the integrity protection
> scope discussed in Section 5) using MAC_KEY and HMAC algorithm. It then
> inserts the computed digest in the MAC field in the "MAC and Encrypted
> Metadata" Context Header.
>
>
>
> Cheers,
>
> -Tiru
>
>
>
> On Wed, 14 Jul 2021 at 16:42, Eric Vyncke (evyncke) <[e-mail]>
> wrote:
>
> Hello Med,
>
> Thank you for your prompt reply.
>
> See below for EV>, still holding my DISCUSS mainly around the "how to
> compute the MAC as it includes the MAC field itself"
>
> Regards
>
> -éric
>
> -----Original Message-----
> From: "[e-mail]" <[e-mail]>
> Date: Tuesday, 13 July 2021 at 18:54
> To: Eric Vyncke <[e-mail]>om>, The IESG <[e-mail]>
> Cc: "[e-mail]" <
> [e-mail]>gt;, "[e-mail]" <
> [e-mail]>gt;, "[e-mail]" <[e-mail]>rg>, "
> [e-mail]" <[e-mail]>
> Subject: RE: Éric Vyncke's Discuss on draft-ietf-sfc-nsh-integrity-06:
> (with DISCUSS and COMMENT)
>
>     Hi Eric,
>
>     Thank you for the review.
>
>     Please see inline.
>
>     Cheers,
>     Med
>
>     > -----Message d'origine-----
>     > De : Éric Vyncke via Datatracker [mailto:[e-mail]]
>     > Envoyé : mardi 13 juillet 2021 14:18
>     > À : The IESG <[e-mail]>
>     > Cc : [e-mail]; [e-mail];
>     > [e-mail]; [e-mail]; [e-mail]
>     > Objet : Éric Vyncke's Discuss on draft-ietf-sfc-nsh-integrity-06:
>     > (with DISCUSS and COMMENT)
>     >
>     > Éric Vyncke has entered the following ballot position for
>     > draft-ietf-sfc-nsh-integrity-06: Discuss
>     >
>     > When responding, please keep the subject line intact and reply to
>     > all email addresses included in the To and CC lines. (Feel free to
>     > cut this introductory paragraph, however.)
>     >
>     >
>     > Please refer to https://www.ietf.org/iesg/statement/discuss-
>     > criteria.html
>     > for more information about DISCUSS and COMMENT positions.
>     >
>     >
>     > The document, along with other ballot positions, can be found here:
>     > https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-integrity/
>     >
>     >
>     >
>     > --------------------------------------------------------------------
>     > --
>     > DISCUSS:
>     > --------------------------------------------------------------------
>     > --
>     >
>     > Thank you for the work put into this document.
>     >
>     > Special thanks to Greg Mirsky for his shepherding especially about
>     > his summary of the WG consensus.
>     >
>     > Please find below some blocking DISCUSS point (which should be easy
>     > to fix), some non-blocking COMMENT points (but replies would be
>     > appreciated), and one nit.
>     >
>     > I hope that this helps to improve the document,
>     >
>     > Regards,
>     >
>     > -éric
>     >
>     > == DISCUSS ==
>     >
>     > I failed to spot the order of the operations for the integrity and
>     > confidentiality operations, e.g., I did not find on what the HMAC is
>     > computed:
>     > in the unencrypted or encrypted field ?
>
>     [Med] Isn't this covered by this text:
>
>        Using the secret key (K) and authenticated encryption algorithm, the
>        NSH imposer encrypts the Context Headers (as set, for example, in
>        Section 3), computes the message integrity for the target NSH data,
>        and inserts the resulting payload in the "MAC and Encrypted
> Metadata"
>        Context Header (Section 5).  The entire Context Header carrying a
>        privacy-sensitive metadata is encrypted (that is, including the MD
>        Class, Type, Length, and associated metadata of each Context
> Header).
>
> EV> the text could be made clearer by using "then" rather than simple ","
> EV> but I STRONGLY suggest to move this explanation earlier at the very
> beginning of section 7 (or 7.1) and not like now in section 7.3
> EV> BTW, this is indeed the expected order to avoid DoS
>
>     >
>     > -- Section 5.1 --
>     > What is the unit of "key length", I assume a length expressed in
>     > octets but it is not specified.
>
>     [Med] Yes. Fixed. Thank you for catching this.
>
> EV> __
>
>     >
>     > -- Section 7.2 --
>     > What is the "A" used in the HMAC computation ?
>
>     [Med] This is: Additional Authenticated Data (A) (mentioned in 4.2).
>
> EV> fair enough, suggest to write that the terminology of section 4.2 is
> used there.
>     >
>     > The formula specifies HMAC-SHA-256-128() but what if another HMAC is
>     > used ?
>
>     [Med] Please note that the text says: "can be illustrated as
> follows:".
>
>     That is for illustration purposes.
>
> EV> could also be made more obvious with " The Message Authentication Code
> (T) computation process for additional authentication text (A) with
> HMAC-SHA-256-128() can be illustrated as follows:"
>
>     > Section 7.3 use MAC() which is more flexible.
>     >
>     > As the MAC field is included in the integrity protected header,
>     > please specify the value of this field when computing the HMAC (I
>     > assume 0 but let's be clear)
>
> EV> still waiting for an answer on this issue (so keeping my DISCUSS
> ballot)
>
>     >
>     > -- Section 7.5 --
>     > What is the expected behavior when a NSH does not contain a "MAC and
>     > Encrypted Metadata" Context Header ? §1 hints to packet drop ?
>     > Should there be a local policy for this case ?
>
>     [Med] This is covered here:
>
>        It MUST log an error at least once per the
>        SPI for which the "MAC and Encrypted Metadata" Context Header is
>        missing.
>
> EV> honestly, not clear from the text. Please consider adding "In this
> case, it MUST..."
>
>     >
>     >
>     > --------------------------------------------------------------------
>     > --
>     > COMMENT:
>     > --------------------------------------------------------------------
>     > --
>     >
>     >
>     > I second Alvaro's and Lars' point about formally updating RFC 8300.
>     >
>     > Quite often in the text "privacy-sensitive metadata" is used but
>     > encryption is not only required for privacy but also to protect
>     > operational data from attackers (i.e., not linked to privacy), is
>     > there a real need to qualify "metadata" with "privacy-sensitive",
>     > i.e., "confidential metadata" may be more appropriate ?
>
>     [Med] We use this term because we can easily argue why we included
> statement such as:
>
>      " In an SFC-enabled domain where the above attacks are possible, (1)
>        NSH data MUST be integrity-protected and replay-protected, and (2)
>        privacy-sensitive NSH metadata MUST be encrypted for confidentiality
>        preservation purposes."
>
>     Other types can be encrypted as per:
>
>        Classifier(s), NSH-aware SFs, and SFC proxies are instructed with
> the
>        set of Context Headers (privacy-sensitive metadata, typically) that
>        must be encrypted.
>
> EV> let's say that we disagree __ but this is non-blocking anyway
>
>     >
>     > -- Section 4.1.1 --
>     > The use of 'metadata' (notably in table 1) for 'context headers' is
>     > confusing for a first-time reader. Any chance to be consistent and
>     > only use 'context headers' ?
>
>     [Med] Will see how to make this better, but please that we do have the
> following before table 1:
>
>     "Context Header(s): Carries metadata..."
>
>     >
>     > -- Section 4.2 --
>     > At first reading, I am confused by the use of the word 'secret key'
>     > for what appears to be a 'shared key'. Or is this 'secret key' never
>     > shared and simply used to generate the secondary keys, which are
>     > then shared ? Even if discussed later, some early explanations would
>     > be welcome.
>
>     [Med] We are using similar wording as in RFC7518.
>
> EV> I fail to see this wording in RFC 7518
>
>     >
>     > -- Section 5.1 --
>     > Is there a good reason why the field name "key length" is not "key
>     > ID length" ?
>
>     [Med] Only for esthetic matters of the figures. Can fix that if you
> prefer.
>
>     |Key ID Length| vs | Key Length |
>
> EV> this would be clearer IMHO but editorial hence non-blocking
>
>     >
>     > I also find very strange to define "Length: variable" as the header
>     > field itself as a fixed length, simply state "unsigned integer".
>
>     [Med] We are echoing Section 2.5.1 of RFC8300.
>
> EV> like above, I fail to see this similarity in the section 2.5.1 of RFC
> 8300 "Indicates the length of the variable-length metadata, in bytes."
>     >
>     > As timestamp can include fractions of second, which is a good thing,
>     > then please reword "expressed in seconds relative" to indicate that
>     > fraction of second is included.
>
>     [Med] OK.
>
>     >
>     > The 32-bit epoch will wrap around in 2036, should this I-D already
>     > consider what to do at that moment ?
>
>     [Med] Hmm. We say that it wraps in 2106 :-)
>
> EV> I should have spot the different epoch ;-)
>
>     >
>     > -- Section 8 --
>     > Indeed MTU is always an interesting 'problem' but how is this
>     > extension different than plain NSH ? The NSH neither increases nor
>     > decreases on the fly with this document.
>
>     [Med] It varies as we can add/strip context headers as the packet
> progress in the service chain.
>
> EV> Amazing that this was accepted by the IESG in RFC 8300 years ago...
> when net-pgm RFC had to remove the header insertion.
>
>     >
>     > == NITS ==
>     >
>     > -- Section 3 --
>     > Should 'figure 1' be 'table 1' per consistency with section 4.1.1 ?
>
>     [Med] It should. Will be fixed. Thanks.
>
>     >
>     >
>
>
>
> _________________________________________________________________________________________________________________________
>
>     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.
>
>