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

From: Zaheduzzaman Sarker via Datatracker <[email-masked]>
Date: Tue, 13 Jul 2021 03:36:53 -0700

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.

* 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.

* 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? 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.

---

From: <[email-masked]>
Date: Tue, 13 Jul 2021 11:06:21 +0000

Hi Zahed, 

Thanks for the review. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Zaheduzzaman Sarker via Datatracker [mailto:[email-masked]]
> Envoyé : mardi 13 juillet 2021 12:37
> À : The IESG <[email-masked]>
> Cc : [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Objet : Zaheduzzaman Sarker's No Objection on draft-ietf-sfc-nsh-
> integrity-06: (with COMMENT)
> 
> 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.)
> 
> 
> I have following non-blocking comments those I believe would improve
> the document if addressed --
> 

[Med] Already replied to those. 

> 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. 

>   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.
==

 My
>    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. 

_________________________________________________________________________________________________________________________

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.

---

From: Zaheduzzaman Sarker <[email-masked]>
Date: Tue, 13 Jul 2021 14:09:06 +0000

Hi,

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

BR
Zahed

On 2021-07-13, 13:06, "[email-masked]" <[email-masked]> wrote:

    Hi Zahed, 

    Thanks for the review. 

    Please see inline. 

    Cheers,
    Med

Thanks, watching the thread.

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.

    ==

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

     My

Ok.

---

From: <[email-masked]>
Date: Tue, 13 Jul 2021 18:37:02 +0000

Re-,

Sure. Added a sentence to the introduction: https://tinyurl.com/nsh-integrity-latest.

Cheers,
Med

> De : Zaheduzzaman Sarker [mailto:[email-masked]]
> Envoyé : mardi 13 juillet 2021 16:09
> À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>; The
> IESG <[email-masked]>
> [email-masked]; [email-masked]
> Objet : Re: Zaheduzzaman Sarker's No Objection on draft-ietf-sfc-
> nsh-integrity-06: (with COMMENT)
> 
...
>     [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.
>

---

From: Zaheduzzaman Sarker <[email-masked]>
Date: Tue, 13 Jul 2021 20:38:34 +0000

Thanks for addressing my comments. Looks good to me.

BR
Zahed
________________________________
From: [email-masked] <[email-masked]>
Sent: Tuesday, July 13, 2021 8:37:02 PM
To: Zaheduzzaman Sarker <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: RE: Zaheduzzaman Sarker's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT)

Re-,

Sure. Added a sentence to the introduction: https://protect2.fireeye.com/v1/url?k=8f5926fb-d0c21fd6-8f596660-8692dc8284cb-13fc495eae83f895&q=1&e=a8edbcbc-a167-4689-86fa-60282dba2815&u=https%3A%2F%2Ftinyurl.com%2Fnsh-integrity-latest.

Cheers,
Med

...