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

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:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern
Sent: Friday, November 08, 2019 11:02 PM
To: Shunsuke Homma; sfc@ietf.org
Subject: Re: [sfc] TR: New Version Notification for draft-rebo-sfc-nsh-integrity-01.txt

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

On 11/8/2019 7:33 AM, Shunsuke Homma wrote:
> 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:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern
> Sent: Tuesday, November 05, 2019 1:04 AM
> To: sfc@ietf.org
> 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, mohamed.boucadair@orange.com 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 : internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
>>> 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
>> sfc@ietf.org
>> https://www.ietf.org/mailman/listinfo/sfc
>>
> 
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc
> 
> 

_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc