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

[<[e-mail]>]

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: [e-mail] <[e-mail]> 
Sent: Dienstag, 5. November 2019 15:53
To: von Hugo, Dirk <[e-mail]>; [e-mail]
Cc: [e-mail]
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

> -----Message d'origine-----
> De : [e-mail] [mailto:[e-mail]] Envoyé 
> : mardi 5 novembre 2019 15:07 À : [e-mail]; 
> BOUCADAIR Mohamed TGI/OLN Cc : [e-mail] 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 <[e-mail]>; [e-mail]
> Cc: BOUCADAIR Mohamed OLNC/OLN ([e-mail]) 
> <[e-mail]>; Konda, Tirumaleswar Reddy
> ([e-mail]) 
> <[e-mail]>
> 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 <[e-mail]> On Behalf Of Joel M. Halpern
> Sent: Montag, 4. November 2019 17:04
> To: [e-mail]
> 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, [e-mail] wrote:
> > 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 : [e-mail] [mailto:[e-mail]] 
> >> 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
> >
> > _______________________________________________
> > sfc mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/sfc
> >
> 
> _______________________________________________
> sfc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sfc