Re: [sfc] Alvaro Retana's No Objection on draft-ietf-sfc-oam-packet-02: (with COMMENT)

[Alvaro Retana <[e-mail]>]

On March 15, 2023 at 4:16:59 AM, [e-mail] wrote:

Med:

Hi!

I'm ok with your replies, but I do want to ask about #5 again:


...
> > (5) From §5: "Any data included in an NSH OAM packet SHOULD be
> > integrity-protected [RFC9145]."
> >
> > Why is this action recommended and not required?
>
> [Med] I remember we discussed this point with you here:
> https://mailarchive.ietf.org/arch/msg/sfc/rPsqPUisDj3lILJk-CVF-ejBrVg/. Please
> see also
> https://mailarchive.ietf.org/arch/msg/sfc/yC-3dN6jvyxZNZY9EYz3XIUlJMs/. The
> wording in the spec is consistent with the positions expressed there. Thanks.

I remember that discussion, but I'm asking something different -- at
least trying to. ;-)


Let me rephrase:

The text from §9/rfc9145 (pasted below) requires integrity protection
when "NSH data is exposed to several threats".  But the text in this
draft only recommends it.  Are OAM packets not exposed to the same
threats?  If they are, why wouldn't the same requirement be applicable
here?

I don't see a difference between OAM packets and any other packets,
but I may be missing something.  Even if the use of rfc9145 is
optional (as we discussed before), I would still like to understand
the difference in criteria.

If those differences exist, it would help implementations when
considering when it may be ok to not use integrity protection.


Thanks!

Alvaro.


> > =====
> > NSH data is exposed to several threats:
> >
> > * An on-path attacker modifying the NSH data.
> >
> > * An attacker spoofing the NSH data.
> >
> > * An attacker capturing and replaying the NSH data.
> >
> > * Data carried in Context Headers revealing privacy-sensitive
> > information to attackers.
> >
> > * An attacker replacing the packet on which the NSH is imposed
> > with a modified or 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.
> > =====