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

Hi!

I meant the discussion about this draft formally Updating rfc8300 — which I
would have hopped happened when processing/discussing this document (not
before).

I’m assuming that discussion never happened.

BTW, I’m not asking for the new mechanism to be MTI — the current text (at
least to me) reads as if it is not.  I’m ok with that.  [IOW, an Update to
rfc8300 would “inherit” that characteristic.]

Alvaro.

On July 12, 2021 at 3:37:51 PM, Joel M. Halpern (jmh@joelhalpern.com) wrote:

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 (jmh@joelhalpern.com
> <mailto:jmh@joelhalpern.com>) 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
>> > sfc@ietf.org <mailto:sfc@ietf.org>
>> > https://www.ietf.org/mailman/listinfo/sfc
>> <https://www.ietf.org/mailman/listinfo/sfc>
>> >
>
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc
>