Last Call Review of draft-ietf-sfc-multi-layer-oam-23
review-ietf-sfc-multi-layer-oam-23-secdir-lc-mundy-2023-05-16-00

Document: draft-ietf-sfc-multi-layer-oam
Document Title: Active OAM for Service Function Chaining (SFC)
Reviewer: Russ Mundy
Review Results: Has issues

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written primarily for the benefit of the security area directors. Document
editors and WG chairs should treat these comments just like any other last call
comments.

The document defines additional capabilities for use in the Service Function
Chaining (SFC) Architecture described in RFC7665 as well as other related RFCs,
e.g. 7799, 8300, 8924. The document abstract is:

"A set of requirements for active Operation, Administration, and Maintenance
(OAM) of Service Function Chains (SFCs) in a network is presented in this
document. Based on these requirements, an encapsulation of active OAM messages
in SFC and a mechanism to detect and localize defects are described."

The primary issue that I have with the document is that it does not describe
how the defined capabilities implement the security requirements that are in
RFC7665, RFC8300 and RFC8924. Section 6 and 10 of the document does address
RFC9124 NSH header protection requirements but I did not see how the set of
security requirements in RFC7665, RFC8300 and RFC8924 are addressed (in Section
7 or elsewhere in the document).  Some illustrations follow:

- RFC7665 Security Considerations specifically states that "... realization
ought to provide means to protect against security and privacy attacks in the
areas hereby described." and describes four areas to be addressed. I could not
see where the document directly addressed any of these areas. The defined NSH
header protection most likely meets expectations of some of these areas but it
would be good to specifically identify this in this document's Security
Considerations (Section 7). - - Since RFC7665 defines the overall architecture
and provides specific security areas that implementations must address, it
seems appropriate that Section 7 would make specific statements about each of
the four areas from RFC7665, i.e., does the expectation apply to the
capabilities and, if so, how it is met (at least Boundaries: and
Classification: would seem to apply). - - The Boundaries: requirement in
RFC7665 appears to dictate that the Section 7 "RECOMMENDED" statements should
be "MUST" statements.

- RFC8300 contains an extensive Security Considerations section. The document
does define RFC9124 NSH header protection definition but it's not clear how
these relate to RFC8300 expectations contained in that document's Security
Considerations section. Since RFC8300 is foundational for this document, it
seems appropriate to have specific statements in Section 7 about what RFC8300
Security Considerations apply to this   document and how they are
met/implemented.

- An area that the document does not currently address is whether or not the
defined capabilities are expected to be used in a single administrative domain
or some other environment, e.g. an applicability statement. Most (maybe all)
related documents have statements about whether or not they are expected to be
used in 'open environment' or in a restricted environment, e.g. a single
administrative domain. Understanding the threat environment is important part
of implementing an appropriate secure solution. (personally I found RFC8300
Section 1.1 a very good example).

Minor issue: It seems to me that RFC7665 should be a Normative Reference rather
than Informative.