Re: [sfc] Fwd: IETF WG state changed for draft-ietf-sfc-nsh-integrity

Hi Greg,

We made some changes to avoid the confusion raised in the message below. The changes can be tracked at:
https://tinyurl.com/nsh-integrity-latest

Hope this is better.

Cheers,
Med

De : mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]
Envoyé : mercredi 3 février 2021 11:12
À : Greg Mirsky <gregimirsky@gmail.com>
Cc : sfc@ietf.org; draft-ietf-sfc-nsh-integrity@ietf.org; Joel M. Halpern <jmh@joelhalpern.com>
Objet : RE: [sfc] Fwd: IETF WG state changed for draft-ietf-sfc-nsh-integrity

Hi Greg,

Thank you for the comment.

As explained in Section 7.2, if no encryption is used the IV Length field will be followed by the MAC:

   The NSH imposer computes the message integrity for the target NSH
   data (depending on the integrity protection scope discussed in
   Section 5<https://tools.ietf.org/html/draft-ietf-sfc-nsh-integrity-03#section-5>) using MAC_KEY and HMAC algorithm.  It inserts the MAC in
   the "MAC and Encrypted Metadata" Context Header.  The length of the
   MAC is decided by the HMAC algorithm adopted for the particular key
   identifier.

I guess you were confused by figures 6 and 7 where we put “Context Headers to encrypt (opt.)” right after Initialization Vector. Will fix that to avoid confusion.

Cheers,
Med

De : Greg Mirsky [mailto:gregimirsky@gmail.com]
Envoyé : vendredi 29 janvier 2021 19:20
À : Joel M. Halpern <jmh@joelhalpern.com<mailto:jmh@joelhalpern.com>>; draft-ietf-sfc-nsh-integrity@ietf.org<mailto:draft-ietf-sfc-nsh-integrity@ietf.org>
Cc : sfc@ietf.org<mailto:sfc@ietf.org>
Objet : Re: [sfc] Fwd: IETF WG state changed for draft-ietf-sfc-nsh-integrity

Dear Authors,
I appreciate your kind consideration of my comments on the draft. I've reviewed the updates. It all looks good. I might have a small question about the case of IV Length = 0. The updated text suggests:
       If encryption is not used, IV length is set to zero
       (that is, no "Initialization Vector" is included).
As I understand it, that means that the IV Length field is immediately followed by the padding as explained in the last paragraph in Section 5:
   The "MAC and Encrypted Metadata" Context Headers are padded out to a
    multiple of 4 bytes as per Section 2.2 of [RFC8300].
Is that correct?

And yes, I support progressing this document to publication.

Regards,
Greg

Regards,
Greg

On Thu, Jan 28, 2021 at 7:33 AM Joel M. Halpern <jmh@joelhalpern.com<mailto:jmh@joelhalpern.com>> wrote:
As you can see below, the SFC Chairs have started the WG last Call for
the nsh-integrity draft.  Please respond.
Thank you,
Joel

-------- Forwarded Message -------

The IETF WG state of draft-ietf-sfc-nsh-integrity has been changed to "In WG
Last Call" from "WG Document" by Joel Halpern:

https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-integrity/

Comment:
This starts the SFC Working Group last call for the NSH integrity protection
document.  This will run through the end of the day February 11, 2021.
(Don't worry about time zone.  If it is still Feb 11 2021 somewhere in the
world, you can send in comments.)  Please respond.  Silence is not consent,
and when (if, but we hope when) we send this to the AD, we need to be
able to
describe meaningful WG support for the publication.  And if possible, more
than just +1.

Thank you,
Joel (and Jim)

_______________________________________________
sfc mailing list
sfc@ietf.org<mailto:sfc@ietf.org>
https://www.ietf.org/mailman/listinfo/sfc

_________________________________________________________________________________________________________________________

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.

_________________________________________________________________________________________________________________________

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.