Subject: [sfc] TR: New Version Notification for draft-rebo-sfc-nsh-integrity-01.txt

From: <[email-masked]>
Date: Mon, 4 Nov 2019 15:56:36 +0000

Hi all, 

This new version integrates the comments we received offline. The main changes are: 

* Clarify why we don't encrypt the base and service path headers
* Clarify that all metadata is integrity protected
* Clarify that the Base header may (or not) be covered by integrity protection. Both schemes are discussed with trade-offs called out.
* Updated the solution overview to provide a big picture view. 

A detailed diff can be found at: https://www.ietf.org/rfcdiff?url2=draft-rebo-sfc-nsh-integrity-01 

Please review and share your comments. 

Cheers,
Tiru & Med 

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]]
> Envoyé : lundi 4 novembre 2019 16:46
> À : Reddy K; Tirumaleswar Reddy; BOUCADAIR Mohamed TGI/OLN
> Objet : New Version Notification for draft-rebo-sfc-nsh-integrity-01.txt
> 
> 
> A new version of I-D, draft-rebo-sfc-nsh-integrity-01.txt
> has been successfully submitted by Mohamed Boucadair and posted to the
> IETF repository.
> 
> Name:		draft-rebo-sfc-nsh-integrity
> Revision:	01
> Title:		Integrity Protection for Network Service Header (NSH) and
> Encryption of Sensitive Metadata
> Document date:	2019-11-04
> Group:		Individual Submission
> Pages:		21
> URL:            https://www.ietf.org/internet-drafts/draft-rebo-sfc-nsh-
> integrity-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-rebo-sfc-nsh-
> integrity/
> Htmlized:       https://tools.ietf.org/html/draft-rebo-sfc-nsh-integrity-01
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-rebo-sfc-nsh-
> integrity
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-rebo-sfc-nsh-
> integrity-01
> 
> Abstract:
>    This specification adds integrity protection and optional encryption
>    directly to Network Service Headers (NSH) used for Service Function
>    Chaining (SFC).
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 4 Nov 2019 11:03:57 -0500

Thank you for your work on this Med and Tiru.
Working Group, this is a topic we have in the charter, and explicitly 
told the IESG we would work on.  Please review and comment on the 
approach described here.

Thank you,
Joel (as co-chair)

On 11/4/2019 10:56 AM, [email-masked] wrote:
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

---

From: <[email-masked]>
Date: Tue, 5 Nov 2019 15:19:59 +0000

Dear all,
regarding the draft by Med and Tiru I thankfully acknowledge that they have considered my (already announced) comments within a preliminary update of their draft - see below.
I am fine with all the changes.
Thanks!
Kind regards
Dirk

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Dienstag, 5. November 2019 15:53
To: von Hugo, Dirk <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: [sfc] TR: New Version Notification for draft-rebo-sfc-nsh-integrity-01.txt

Hi Dirk, 

All good points. Thank you.

I implemented the changes to address these comments: 

https://github.com/boucadair/sfc-nsh-integrity/blob/master/draft-rebo-sfc-nsh-integrity-01.txt
diff: https://github.com/boucadair/sfc-nsh-integrity/commit/e2a088ca53976128a02c54696eb28ed35faa99db#diff-3457ce7d425fdeb9578acbd5b2e46793 

Can you forward this message to the sfc list?

Cheers,
Med

> De : [email-masked] [mailto:[email-masked]] Envoyé 
> : mardi 5 novembre 2019 15:07 À : [email-masked]; 
> BOUCADAIR Mohamed TGI/OLN Cc : [email-masked] Objet : RE: 
> [sfc] TR: New Version Notification for draft-rebo-sfc-nsh- 
> integrity-01.txt
> 
> Hi Tiru and Med
> Thanks again for your draft!
> As already promised I suggest in the next version to consider 
> following comments (mainly nits only ;-)):
> 
> p.2 (and following short headers):
> Intgerity Protection for NSH => Integrity Protection for NSH
> 
> p.4:
> SFP not defined - I suggest to change:
> within a service path. => within a service path or Service Function 
> Path (SFP).
> 
> p.7:
> not requrie to => not require to
> 
> p.9/10:
> Figures in sect. 6.1 and 6.2 have no caption
> 
> p.11:
> scope of this TLV is depicted in Figure 5. => scope of this TLV is 
> depicted in Figure 4.
> Figure 4: Scope of MAC# => Figure 4: Scope of MAC#1
> 
> p.13:
> SFC proxy that receive => SFC proxy that receives
> 
> p.15:
> that the Sequence Number that does not duplicate => that the Sequence 
> Number does not duplicate is to be used . => is to be used.
> 
> p.16:
> explain on AES or ChaCha20 that these are popular Authentication 
> Encryption Security modes as proposed for TLS ?
> NSH data are exposed to from to four primary attacks => NSH data are 
> exposed to threats by one or more out of up to four primary attack 
> situations
> 
> p.17:
> AS such this is attack is not => As such this attack is not
> 
> p.19:
> KMS => KMS (Key Management Server/Service??) SFC-aware SFs do not 
> share any credentials => In case an SFC domain stretches across 
> multiple independent operators' administrative domains SFC-aware SFs 
> do not share any credentials
> 
> I would question this sentence w/o extension in its generality - in 
> case an SFC domain is completely within an operator domain this would 
> be not true - at least I cannot imagine why a 3rd party should be included?
> 
> Thanks and
> Kind regards
> Dirk
> 
> 
> -----Original Message-----
> From: von Hugo, Dirk
> Sent: Dienstag, 5. November 2019 14:15
> To: Joel M. Halpern <[email-masked]>; [email-masked]
> Cc: BOUCADAIR Mohamed OLNC/OLN ([email-masked]) 
> <[email-masked]>; Konda, Tirumaleswar Reddy
> ([email-masked]) 
> <[email-masked]>
> Subject: RE: [sfc] TR: New Version Notification for 
> draft-rebo-sfc-nsh- integrity-01.txt
> 
> Hi all,
> I think is very valuable work also from point of view of future 
> flexible network deployments - and also will help to put other WG 
> drafts further where security, privacy, and integrity should definitely be provided.
> Thanks to Med and Tiru!
> So far I detect no missing issues, only some nits which I will point 
> out to the authors ...
> Please progress in Singapure!
> Kind regards
> Dirk
> 
> -----Original Message-----
> From: sfc <[email-masked]> On Behalf Of Joel M. Halpern
> Sent: Montag, 4. November 2019 17:04
> To: [email-masked]
> Subject: Re: [sfc] TR: New Version Notification for 
> draft-rebo-sfc-nsh- integrity-01.txt
> 
> > This new version integrates the comments we received offline. The 
> > main
> changes are:
> >
> > * Clarify that the Base header may (or not) be covered by integrity
> protection. Both schemes are discussed with trade-offs called out.
> > A detailed diff can be found at:
> > https://www.ietf.org/rfcdiff?url2=draft-rebo-sfc-nsh-integrity-01
> >
> >> Envoyé : lundi 4 novembre 2019 16:46 À : Reddy K; Tirumaleswar 
> >> Reddy; BOUCADAIR Mohamed TGI/OLN Objet : New Version Notification 
> >> for draft-rebo-sfc-nsh-integrity-01.txt
> >>
> >>
> >> has been successfully submitted by Mohamed Boucadair and posted to 
> >> the IETF repository.
> >>
> >> submission until the htmlized version and diff are available at 
> >> tools.ietf.org.
> >>
> >> The IETF Secretariat
> >

---

From: <[email-masked]>
Date: Tue, 5 Nov 2019 13:15:04 +0000

Hi all,
I think is very valuable work also from point of view of future flexible network deployments - and also will help to put other WG drafts further where security, privacy, and integrity should definitely be provided. Thanks to Med and Tiru!
So far I detect no missing issues, only some nits which I will point out to the authors ...
Please progress in Singapure!
Kind regards
Dirk

-----Original Message-----
From: sfc <[email-masked]> On Behalf Of Joel M. Halpern
Sent: Montag, 4. November 2019 17:04
To: [email-masked]
Subject: Re: [sfc] TR: New Version Notification for draft-rebo-sfc-nsh-integrity-01.txt

Thank you for your work on this Med and Tiru.
Working Group, this is a topic we have in the charter, and explicitly told the IESG we would work on.  Please review and comment on the approach described here.

Thank you,
Joel (as co-chair)

On 11/4/2019 10:56 AM, [email-masked] wrote:
>> Envoyé : lundi 4 novembre 2019 16:46 À : Reddy K; Tirumaleswar Reddy; 
>> BOUCADAIR Mohamed TGI/OLN Objet : New Version Notification for 
>> draft-rebo-sfc-nsh-integrity-01.txt
>>
>>

---

From: Shunsuke Homma <[email-masked]>
Date: Fri, 08 Nov 2019 21:33:06 +0900

Hi, 

I agree that integrity protection is important, and I'd like to support this work. 

In addition to encryption of metadata, I assume that a mechanism to prevent accidentally errors on metadata would be also needed.  For example, it may be realized by integrating some error correction mechanism into NSH scheme, or defining a rule for a case that an SF/SF proxy detects metadata error is detected (e.g., delete the errored metadata, discard whole of packet).

Best regards,

Shunsuke

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Tuesday, November 05, 2019 1:04 AM
To: [email-masked]
Subject: Re: [sfc] TR: New Version Notification for draft-rebo-sfc-nsh-integrity-01.txt

Thank you,
Joel (as co-chair)

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 8 Nov 2019 09:02:04 -0500

Shunsuke.   Thank you for your interest in this topic.
As co-chair, I am trying to understand what kinds of additions you would 
be looking for to address metadata errors.  All SF are already allowed 
to modify metadata.  Any process for detecting and correcting erroneous 
metadata would seem on the one end to be permitted by current rules, and 
on the other hand to be highly specific to the precise metadata being 
dealt with.
Did you have something more general, and needing documentation, to be added?

Yours,
Joel Halpern

---

From: Shunsuke Homma <[email-masked]>
Date: Mon, 11 Nov 2019 18:08:48 +0900

Hi Joel,

I assume that bit errors and software errors may cause some problems. The current NSH allows to contain every type of metadata, and some types of metadata such as subscriber ID or upper-level SFP info (ref. RFC8459) may affect the following SFP or SFs' processes if it has some errors. Such metadata would be inserted by CF, in other words SFC component, and I thought that detection/prevention schemes of such accidental errors can be supported in SFC framework.

However, as you pointed, the current specifications allow SFs and SFC components to modify metadata, and it may be implementation matter.

Best regards,

Shunsuke

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Friday, November 08, 2019 11:02 PM
To: Shunsuke Homma; [email-masked]
Subject: Re: [sfc] TR: New Version Notification for draft-rebo-sfc-nsh-integrity-01.txt

Yours,
Joel Halpern