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

[Zaheduzzaman Sarker <[e-mail]>]

Hi,

Thanks for the responses. See below my reflections inline below.

BR
Zahed

On 2021-07-13, 13:06, "[e-mail]" <[e-mail]> wrote:

    Hi Zahed, 

    Thanks for the review. 

    Please see inline. 

    Cheers,
    Med

    > -----Message d'origine-----
    > De : Zaheduzzaman Sarker via Datatracker [mailto:[e-mail]]
    > Envoyé : mardi 13 juillet 2021 12:37
    > À : The IESG <[e-mail]>
    > Cc : [e-mail]; [e-mail];
    > [e-mail]; [e-mail]; [e-mail]
    > Objet : Zaheduzzaman Sarker's No Objection on draft-ietf-sfc-nsh-
    > integrity-06: (with COMMENT)
    > 
    > Zaheduzzaman Sarker has entered the following ballot position for
    > draft-ietf-sfc-nsh-integrity-06: No Objection
    > 
    > 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/
    > 
    > 
    > 
    > --------------------------------------------------------------------
    > --
    > COMMENT:
    > --------------------------------------------------------------------
    > --
    > 
    > Thanks for the efforts on this specification.
    > 
    > I have following non-blocking comments those I believe would improve
    > the document if addressed --
    > 
    > * I agree with Alvaro and Lars's comment about updating 8300. Would
    > like to get
    > response(s) to their comments.

    [Med] Already replied to those. 

Thanks, watching the thread.

    > 
    > * I think it will be helpful to explicitly mention if integrity and
    > confidentiality by the transport encapsulation is needed or not when
    > this specification is in use. This specification definitely says
    > that one does not need to relay on the service provided by the
    > transport encapsulation but it does not says that those services are
    > not longer required.

    [Med] We don't say so because this is deployment-specific. One may deploy hSFC (RFC8459) with transport security to interconnect lower-level domains, but use this spec within a lower-level domain. 

Ok, then can we write something along the lines you have written here? This might actual help the why not updating 8300 discussion as well.

    > 
    > * Section 1 : says -
    >     "This specification fills that gap.  Concretely, this document
    > adds
    >    integrity protection and optional encryption of sensitive
    > metadata
    >    directly to the NSH (Section 4);"
    > 
    >   Does this specification extends the use of NSH in multiple SFC
    > domain?

    [Med] No, we don't as we adhere to RFC7665 and RFC8300. 

    Future documents may define an updated 7665 to describe the inter-domain case. This spec may solve some of the inherent issues, but it is out of scope to discuss those in this I-D.

    Till this happens, the scope is still what is recorded in RFC7665: 

    ==
       The architecture described herein is assumed to be applicable to a
       single network administrative domain.  While it is possible for the
       architectural principles and components to be applied to inter-domain
       SFCs, these are left for future study.
    ==

OK. I have seen the update where you mention about the gaps that will resolve my question as well.

     My
    >   little understanding of NSH says it is SFC domain specific and
    > within one SFC
    >   domain the devices a vetted to be trusted. I think it will be very
    > helpful to
    >   add zest from the section 3.2.1. of I-D.arkko-farrell-arch-model-t
    > here.
    > 
    > * Section 6 :
    > 
    >    The epoch is 1970-01-01T00:00Z in UTC time.  Note this epoch
    > value
    >       is different from the one used in Section 6 of [RFC5905].
    > 
    >    It would be great if we can add the implications of the
    > difference. Now I
    >    don't know what it means.
    > 
    > 

    [Med] The implication is basically what is mentioned under wraparound bullet: "The next wraparound will occur in the year 2106". If we maintained the epoch in RFC5905, the wraparound would be in 2036. Tweaked the text to mention this. Thanks. 

Ok.



    _________________________________________________________________________________________________________________________

    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.