Re: [Last-Call] Secdir last call review of draft-ietf-sfc-multi-layer-oam-23

[Greg Mirsky <[e-mail]>]

Hi Russ,
thank you for your review and detailed comments. Please find my notes below
tagged GIM>>. Attached, are the working version of the draft (it now
includes updates resulting from the discussions with reviewers from RtgDir,
TsvArt, and GenArt.) and the diff that highlights those updates.

Regards,
Greg

On Tue, May 16, 2023 at 12:51 PM Russ Mundy via Datatracker <
[e-mail]> wrote:

> Reviewer: Russ Mundy
> Review result: Has Issues
>
> 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).
>
GIM>> We added the following text in Section 7:
NEW TEXT:
    As an element of SFC OAM and, specifically, NSH-based, the Echo
   Request/Reply mechanism described in this document inherits Security
   Considerations discussed in [RFC7665] and [RFC8300].
Would this text address your concerns? What would you suggest to expand?
In the course of addressing RtgDir comments, we extended the explanation of
"fate sharing" in REQ#1:
      REQ#1: Packets of active SFC OAM SHOULD be fate sharing with the
      monitored SFC data in the forward direction from ingress toward
      egress endpoint(s) of the OAM test.

   The fate sharing, in the SFC environment, is achieved when a test
   packet traverses the same path and receives the same treatment in the
   underlay network layer as an SFC-encapsulated packet (e.g., NSH).
"Fate sharing" is not only essential for accurate understanding of the
network conditions as experienced by the monitored data, but also to stress
that all security recommendations listed in RFC 8300 are applicable to SFC
active OAM and SFC Echo Request/Reply that is defined in the draft.


> Minor issue: It seems to me that RFC7665 should be a Normative Reference
> rather
> than Informative.
>
GIM>> Agreed and moved to the Normative list. Will inform the Shepherd
about the Downref:
 ** Downref: Normative reference to an Informational RFC: RFC 7665