Re: [sfc] Opsdir last call review of draft-ietf-sfc-nsh-integrity-05

[Juergen Schoenwaelder <[e-mail]>]

Med,

looks good, thanks for taking my comments into account.

/js

On Fri, Jul 02, 2021 at 05:10:10AM +0000, [e-mail] wrote:
> Hi Jürgen, 
> 
> FYI, the changes are now implemented in the public version: 
> https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-integrity-06 
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : [e-mail]
> > [mailto:[e-mail]]
> > Envoyé : vendredi 25 juin 2021 11:56
> > À : Jürgen Schönwälder <[e-mail]>de>; ops-
> > [e-mail]
> > Cc : [e-mail]; [e-mail];
> > [e-mail]
> > Objet : RE: Opsdir last call review of draft-ietf-sfc-nsh-integrity-
> > 05
> > 
> > Hi Jürgen,
> > 
> > Thank you for the review. You can track the changes at:
> > https://tinyurl.com/nsh-integrity-latest
> > 
> > Please see inline.
> > 
> > Cheers,
> > Med
> > 
> > > -----Message d'origine-----
> > > De : Jürgen Schönwälder via Datatracker [mailto:[e-mail]]
> > > Envoyé : vendredi 25 juin 2021 10:18 À : [e-mail] Cc :
> > > [e-mail]; [e-mail];
> > > [e-mail] Objet : Opsdir last call review of
> > > draft-ietf-sfc-nsh-integrity-05
> > >
> > > Reviewer: Jürgen Schönwälder
> > > Review result: Has Issues
> > >
> > > The document is very well written and organized, thanks for that.
> > I
> > > have some comments and a few nits. The issues I have a minor, I
> > think
> > > the document overall is in a good shape.
> > >
> > > - From an operational perspective, I very much appreciate that
> > there
> > >   is some text discussing error and failure reporting and that
> > there
> > >   are some MTU configuration guidelines.
> > >
> > > - The document claims:
> > >
> > >     As depicted in Table 1, SFFs are not involved in data
> > encryption.
> > >     This document enforces this design approach by encrypting
> > Context
> > >     Headers with keys that are not supplied to SFFs, thus
> > enforcing
> > > this
> > >     limitation by protocol (rather than requirements language).
> > >
> > >   I am a bit puzzled about this statement since a protocol
> > definition
> > >   at the end is just some form of requirements language.
> > 
> > [Med] FWIW, that sentence was drawn compared to an alternative
> > design we considered in the past (use of AEAD which relies upon a
> > single key for both encryption and integrity) and for which we
> > indicated the following at that time:
> > 
> >       In order to avoid the overhead of multiple authentication tags
> > and
> >       multiple keys, and to prevent SFFs from acquiring the secret
> > key
> >       to decrypt the metadata, the recommendation is not to
> > integrity
> >       protect the base header.  Such approach does not require to
> >       recompute the MAC each time TTL is decremented by an SFF.  As
> > a
> >       reminder, an SFF is not supposed to act on the metadata or
> > look
> >       into the content of the metadata.
> > 
> > We were concerned with relying on the requirement language (mainly
> > the last sentence) for the correct protocol behavior. We changed the
> > design so that the limitation is imposed by the protocol: use
> > distinct keys for encryption (ENC_KEY) and integrity (MAC_KEY).
> > 
> > We do have the following:
> > 
> >    The other advantage is
> >    that SFFs do not have access to the ENC_KEY and cannot act on the
> >    encrypted Context Headers and, only in case of the second level
> > of
> >    assurance, SFFs do have access to the MAC_KEY.  Similarly, an
> > NSH-
> >    aware SF or SFC Proxy not allowed to decrypt the Context Headers
> > will
> >    not have access to the ENC_KEY.
> > 
> > but ...
> > 
> >  Well,
> > > putting
> > >   that remark aside, I do not really see anything in the
> > specification
> > >   that ensures that SFFs won't get the keys. We also read:
> > >
> > >     [...] Encryption keying material is only provided to
> > >     these SFC data plane elements.
> > >
> > >   Well, the specification is actually silent about how keys are
> > >   distributed. Section 4.4. says:
> > >
> > >     The procedure for the allocation/provisioning of secret keys
> > (K)
> > > and
> > >     authenticated encryption algorithm or MAC_KEY and HMAC
> > algorithm
> > > is
> > >     outside the scope of this specification.  As such, this
> > > specification
> > >     does not mandate the support of any specific mechanism.
> > >
> > >   To me, it seems the claims made in section 4.4. do not really
> > hold.
> > 
> > [Med] ... I agree that we still depend on the provisioning. Removed
> > that sentence.
> > 
> > >
> > > - In section 6, you picked as the epoch 1970-01-01T00:00Z while
> > NTP
> > >   uses the epoch 1900-01-01T00:00Z. This leads to rollovers in the
> > >   year 2106 for your timestamps while the NTP rollover would be in
> > >   2036. Given that you use an NTP compatible format and a
> > different
> > >   epoch, I think this deserves to be spelled out explicitly so
> > that
> > >   people understand that they have to do conversions.
> > >
> > >   (Alternatively, you could adopt the epoch NTP is using and the
> > need
> > >   for conversions goes away at the price of an earlier rollover.)
> > >
> > >   Anyway, what I am saying is that if you pick a different epoch,
> > I
> > >   suggest to spell this out explicitly and to not rely on
> > >   implementers to discover this.
> > >
> > 
> > [Med] Fair point. Added a note.
> > 
> > > Minor nits:
> > >
> > > - In section 5.2, it should say:
> > >
> > >   OLD
> > >
> > >   In reference to Figure 5
> > >
> > >   NEW
> > >
> > >   In reference to Figure 7
> > >
> > 
> > [Med] For both 5.1 and 5.2 we provide a reference to the figure with
> > the format of the context header (i.e., Figure 5). Figures 6/7 cover
> > the NSH header and so on.
> > 
> > > - In section 7.3, I suggest this change to make it clear again to
> > the
> > >   reader what K is:
> > >
> > >   OLD
> > >
> > >   Using K and
> > >
> > >   NEW
> > >
> > >   Using the secret key K and
> > 
> > [Med] 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.
> 
> 
> _________________________________________________________________________________________________________________________
> 
> 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.
> 

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>