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

[[e-mail]]

Hi Alvaro, 

Sure. I made the changes that you can track at: https://tinyurl.com/nsh-integrity-latest 

* Added a pointer to 8.2 where the transport security is discussed
* added an explicit mention of the third option that refers to this I-D

We may tweak this a little more. 

Cheers,
Med

> -----Message d'origine-----
> De : Alvaro Retana [mailto:[e-mail]]
> Envoyé : lundi 12 juillet 2021 22:13
> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>; The
> IESG <[e-mail]>
> Cc : [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Objet : RE: Alvaro Retana's No Objection on draft-ietf-sfc-nsh-
> integrity-06: (with COMMENT)
> 
> On July 12, 2021 at 3:41:13 PM, [e-mail]
> ([e-mail] (mailto:[e-mail]))
> wrote:
> 
> 
> ...
> > > The outcome is that the requirements in rfc8300 would result in
> not
> > > using this specification.
> > >
> >
> > [Med] Not sure about this given that RFC8300 says the following:
> >
> > NSH itself does not mandate protocol-specific integrity
> protection.
> > However, if an operator deems protection is required, several
> options
> > are viable:
> >
> > 1. SFF/SF NSH verification
> > ...
> > 2. Transport Security
> > ...
> > 3. NSH Variable Header-Based Integrity
> >
> > Lastly, NSH MD Type 2 provides, via variable-length headers, the
> > ability to append cryptographic integrity protection to the NSH
> > packet. The implementation of such a scheme is outside the scope
> of
> > this document.
> >
> > The I-D is basically the third option.
> 
> Ok.  Please make it extra obvious that this is the case -- using the
> same words would be ideal.
> 
> 
> §8.2.2 (Confidentiality) is a lot less clear.
> 
> 
> Even though I still think that a formal Update to rfc8300 is the
> right thing to do, I would be very happy if there was (at least)
> some additional text included to clarify the expected relationship
> between the 2 documents.
> 
> Thanks!
> 
> Alvaro.
> 
> 
> 
> > > > I know that we can interpret the update as "amends", but
> unless
> > > > I'm mistaken there is no formal IETF consensus on this.
> > >
> > > True.
> > >
> > > Without at least some text explaining the relationship between
> the
> > > requirements in this document and how they may be considered
> instead
> > > of the ones in rfc8300, I don't think this document is complete.
> For
> > > better or worse, the only tool we have right now to make that
> link
> > > clear is the Updates tag.
> > >
> > >
> > > Thanks!
> > >
> > > Alvaro.

_________________________________________________________________________________________________________________________

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.