Hi Russ,
thank you for a great discussion and your help improving the document.
Regards,
Greg
On Thu, Jun 8, 2023 at 5:42 PM Russ Mundy <mundy@xxxxxxxxxxx> wrote:
Hi Greg,Thanks for these additional changes - I think they take care of my concerns.Regards,RussOn Jun 7, 2023, at 7:41 PM, Greg Mirsky <gregimirsky@xxxxxxxxx> wrote:Hi Russ,thank you for your response and detailed explanations of outstanding concerns. Please find my notes inlined below under GIM2>> tag.Regards,GregOn Wed, Jun 7, 2023 at 10:17 PM Russ Mundy <mundy@xxxxxxxxxxx> wrote:Hi Greg,Thanks for the updates and the followup.I do apologize but a combination of operational and personal commitments have delayed my reply.The additional text at the beginning of Section 7 is an excellent addition to the Security Considerations that should point folks to these documents - thanks for the addition and the change to the ref's.I've relooked at the RFCs and the ID and I don't see that the added text deals with all of the things from my initial review. My basic concern is that the referenced RFCs identify a number of requirements that need additional specifics to be provided for particular use cases - I think this ID is such a case. I hope the following items can be addressed in some way:- RFC7665 Section 6 Boundaries section contains MUST requirements for protection and isolation of SFC capabilities while Section 7 of the ID has RECOMMENDED rather than MUST for this use case. This seems to put the ID out of compliance with RFC7665. Do the 'RECOMMEDEDs' need to change to 'MUSTs' to comply with 7665 or have I misunderstood something?GIM2>> As I understand your question, it is the last paragraph of Section 7 of the ID that is not consistent with the normative level of the analysis of protecting the boundaries of an SFC domain in Section 6 of RFC 7665. I my understanding is correct, would the following update address your concern"OLD TEXT:Also, since the Service Function Information sub-TLV disclosesinformation about the SFP, the spoofed CVReq packet may be used toobtain network information. Thus it is RECOMMENDED thatimplementations provide a means of checking the source addresses ofCVReq messages, specified in SFC Source TLV Section 6.3.1, against anaccess list before accepting the message.NEW TEXT:Also, since the Service Function Information sub-TLV disclosesinformation about the SFP, the spoofed CVReq packet may be used toobtain network information. Thus, implementations MUST provide ameans of checking the source addresses of CVReq messages, specifiedin SFC Source TLV Section 6.3.1, against an access list beforeaccepting the message.- As I read RFC7665 & 8300, they seem to be pretty clear that the intended use environment is within a single administrative domain but I did not find anything about intended use environment in the ID. Given that this ID defines such an environment, would it be acceptable to include the text from the second paragraph of Section 1.1 of RFC8300 (replacing NSH with SFC) in this document? (could be added to either Section 1 or 7)GIM2>> This I-D must not define an environment different from the environments defined in RFC 7665 and 8300. Would appending the following text to Section 1, as you suggested, makes that clearer:NEW TEXT:The intended scope of active SFC OAM is for use within a singleprovider operational domain. Active SFC OAM deployment scope isdeliberately constrained, as explained in [RFC7665] and [RFC8300],and limited to a single network administrative domain.Thanks for your patience,RussOn Jun 5, 2023, at 10:17 AM, Greg Mirsky <gregimirsky@xxxxxxxxx> wrote:<draft-ietf-sfc-multi-layer-oam-24.txt><draft-ietf-sfc-multi-layer-oam-24.diff.html>Hi Russ,the new version of the draft was uploaded. It includes updates addressing your comments. Please let me know if you find them satisfactorily resolved.Best regards,Greg---------- Forwarded message ---------
From: Greg Mirsky <gregimirsky@xxxxxxxxx>
Date: Tue, May 30, 2023 at 2:45 AM
Subject: Fwd: Secdir last call review of draft-ietf-sfc-multi-layer-oam-23
To: Russ Mundy <mundy@xxxxxxxxxxx>Hi Russ,thanks again for your comments. Have you had a chance to check the proposed updates? What are your thoughts?Regards,Greg---------- Forwarded message ---------
From: Greg Mirsky <gregimirsky@xxxxxxxxx>
Date: Tue, May 23, 2023 at 5:20 PM
Subject: Re: Secdir last call review of draft-ietf-sfc-multi-layer-oam-23
To: Russ Mundy <mundy@xxxxxxxxxxx>
Cc: <secdir@xxxxxxxx>, <draft-ietf-sfc-multi-layer-oam.all@xxxxxxxx>, <last-call@xxxxxxxx>, <sfc@xxxxxxxx>, <mundy@xxxxxxxxxxx>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,GregOn Tue, May 16, 2023 at 12:51 PM Russ Mundy via Datatracker <noreply@xxxxxxxx> 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 EchoRequest/Reply mechanism described in this document inherits SecurityConsiderations 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 themonitored SFC data in the forward direction from ingress towardegress endpoint(s) of the OAM test.The fate sharing, in the SFC environment, is achieved when a testpacket traverses the same path and receives the same treatment in theunderlay 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
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
