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

Hi Med,
thank you for the quick updates. These are very helpful and the text is
perfectly clear.

Regards,
Greg

On Wed, Feb 3, 2021 at 11:18 PM <mohamed.boucadair@orange.com> wrote:

> 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 <gregimirsky@gmail.com>]
> *Envoyé :* vendredi 29 janvier 2021 19:20
> *À :* Joel M. Halpern <jmh@joelhalpern.com>;
> draft-ietf-sfc-nsh-integrity@ietf.org
> *Cc :* 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>
> 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
> 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.
>
>