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

[Alvaro Retana <[e-mail]>]

On July 12, 2021 at 2:52:22 PM, [e-mail] wrote:


Med:

Hi!

...
> > (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?]
>
> [Med] We don't use the update header as we don't formally update any text
> in 8300.

Updating text is not the only reason to formally Update another specification.

This document requires the use of both integrity and encryption if
specific attacks are possible (text above).  It is reasonable to
interpret that as cases where the "operator deems protection is
required", which is the text that rfc8300 uses when it talks about the
need for integrity protection (similar text can also be found about
encryption).  IOW, the formal Update that I'm suggesting here is to
provide more insight into when integrity protection and encryption are
required, and the mechanism to use.


As I look into this further, I believe there is a normative
inconsistency between this document and rfc8300:

- rfc8300 requires the use of an encapsulating transport protocol that
can provide integrity protection and/or encryption, as needed.

- This document requires protection as specified in the text above.  A
stated goal of this specification is so that "the NSH does not have to
rely upon an underlying transport encapsulation for security and
confidentiality".

The outcome is that the requirements in rfc8300 would result in not
using this specification.


> I know that we can interpret the update as "amends", but unless I'm mistaken
> there is no formal IETF consensus on this.

True.

Without at least some text explaining the relationship between the
requirements in this document and how they may be considered instead
of the ones in rfc8300, I don't think this document is complete.  For
better or worse, the only tool we have right now to make that link
clear is the Updates tag.


Thanks!

Alvaro.