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

["Joel M. Halpern" <[e-mail]>]

Depending upon what you mean, either

1) The discussion never happened, because the action was not suggested.

or, with a longer view

2) The discussion happened when 8300 was being approved.  We agreed with 
the IESG that we would not define a mandatory-to-implement NSH security 
mechanism, but that we would add an optional NSH security mechanism. 
Which this draft does.

Yours,
Joel

On 7/12/2021 3:29 PM, Alvaro Retana wrote:
> Joel:
> 
> Hi!
> 
> I guess I missed where that discussion happened — probably buried in one 
> of the threads.  Can you please point me to it?
> 
> Thanks!
> 
> Alvaro.
> 
> On July 12, 2021 at 3:23:28 PM, Joel M. Halpern ([e-mail] 
> <mailto:[e-mail]>) wrote:
> 
>> I find your description of this as a "required update to 8300" rather
>> odd. The working group did not agree to make implementation of this
>> mandatory for 8300. That would, indeed, be an update to 8300. This is
>> just another feature that can be used with NSH. A useful feature.
>>
>> The security considerations do give lots of reasons to do this. But that
>> is not the same as making it "required" for all implementations of 8300.
>>
>> Yours,
>> Joel
>>
>> On 7/12/2021 2:36 PM, Alvaro Retana via Datatracker wrote:
>> > Alvaro Retana 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 
>> <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/ 
>> <https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-integrity/>
>> >  
>> >  
>> >  
>> > ----------------------------------------------------------------------
>> > COMMENT:
>> > ----------------------------------------------------------------------
>> >  
>> >  
>> > (1) Given the required behavior specified in the Security Considerations
>> > section...
>> >  
>> >     NSH data are exposed to several threats:
>> >  
>> >     o  A man-in-the-middle attacker modifying the NSH data.
>> >  
>> >     o  Attacker spoofing the NSH data.
>> >  
>> >     o  Attacker capturing and replaying the NSH data.
>> >  
>> >     o  Data carried in Context Headers revealing privacy-sensitive
>> >        information to attackers.
>> >  
>> >     o  Attacker replacing the packet on which the NSH is imposed with a
>> >        bogus packet.
>> >  
>> >     In an SFC-enabled domain where the above attacks are possible, (1)
>> >     NSH data MUST be integrity-protected and replay-protected, and (2)
>> >     privacy-sensitive NSH metadata MUST be encrypted for confidentiality
>> >     preservation purposes.  The Base and Service Path headers are not
>> >     encrypted.
>> >  
>> > Why doesn't this document formally update rfc8300?  Concerns that eventually
>> > led to this solution have been expressed for several other documents, including
>> > rfc8459 and rfc8979.
>> >  
>> > It looks like the WG didn't consider the question of Updating the base NSH
>> > specification.  I believe that this document specifies a required update to
>> > NSH, and would like the WG to consider formally Updating rfc8300.  [My search
>> > of the archive didn't find any related discussion -- did I miss it?]
>> >  
>> > [Even though I consider this omission a serious oversight, I don't think this
>> > issue raises to the level of a DISCUSS.]
>> >  
>> > (2) §3: I find the use of normative language to describe requirements (that are
>> > met in this same document) not the best use of rfc2119 language because any
>> > interoperability concerns would result from the specification itself and not
>> > the requirements.
>> >  
>> > The use of rfc2119 keywords to describe requirements may result in confusion.
>> > For example, "The solution MAY provide integrity protection for the Base
>> > Header." -- as described later, protecting the Base Header is optional, but the
>> > solution *does* provide integrity protection for it.  IOW, the specification is
>> > what is reflected in the requirement, but referring to the solution, not the
>> > protection: providing integrity protection is not optional, using it is.  A
>> > better working would be: "The solution must provide optional integrity
>> > protection for the Base Header."
>> >  
>> >  
>> >  
>> > _______________________________________________
>> > sfc mailing list
>> > [e-mail] <mailto:[e-mail]>
>> > https://www.ietf.org/mailman/listinfo/sfc 
>> <https://www.ietf.org/mailman/listinfo/sfc>
>> >  
> 
> _______________________________________________
> sfc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sfc
>