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

[[e-mail]]

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).

> 
> -- 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. 

> 
> -- Section 7.2 --
> What is the "A" used in the HMAC computation ?

[Med] This is: Additional Authenticated Data (A) (mentioned in 4.2).

> 
> 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. 

> 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)
> 
> -- 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.

> 
> 
> --------------------------------------------------------------------
> --
> 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.

> 
> -- 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.

> 
> -- 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 |

> 
> 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.

> 
> 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 :-)

> 
> -- 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. 

> 
> == 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.