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.