Hi Zafar, thank you for listening to my comments and thoughtfully addressing them with updates. The new version looks good to me.
Regards, Greg On Thu, Apr 8, 2021 at 11:24 PM Zafar Ali (zali) <[email protected]> wrote: > Hi Greg, > > > > Many thanks for your comments and offline discussion to help close them; > much appreciated. > > > > We have uploaded rev 10 to address your comments. > > https://datatracker.ietf.org/doc/html/draft-ietf-6man-spring-srv6-oam-10 > > > > The comments are addressed as in-lined with [ZA] in the following. > > > > Thanks > > > > Regards … Zafar > > > > *From: *Greg Mirsky <[email protected]> > *Date: *Saturday, March 20, 2021 at 5:04 PM > *To: *"[email protected]" <[email protected]>, " > [email protected]" < > [email protected]>, 6man WG <[email protected]>, 6man > Chairs <[email protected]>, spring <[email protected]> > *Subject: *Last-call comments on OAM in SRv6 draft > *Resent-From: *<[email protected]> > *Resent-To: *<[email protected]>, <[email protected]>, < > [email protected]>, <[email protected]>, < > [email protected]> > *Resent-Date: *Saturday, March 20, 2021 at 5:03 PM > > > > Dear Authors, 6man and SPRING community, > > I have read this draft and have several comments I want to share with you. > > The draft is well-written and I appreciate the work authors put into it. > OAM is the essential element of any networking technology and I believe it > is important that this document will be published soon after the > publication of RFC 8754. Below, please find my comments and questions, some > are just an editorial while some may have more technical impact on the > document. I appreciate your kind consideration. > > - As I understand the document, it consists of two parts - > informational and standardization. The informational part explains how > existing mechanisms like ICMPv6 can be applied in the SRv6 environment. > Also, the applicability of RFC 8403 is explained. In the standardization > part, the O-flag is defined and its processing described. I am concerned > that that part of the draft is significantly underdeveloped as the threats > that are created by the introduction of the O-flag are not identified and > protection mechanisms are not sufficiently discussed, specified. As it > appears, the O-flag use in SRv6 is very much similar to what already and > for a long time has been achieved by using ACLs - sampling data flows. > Though managing ACL may be operationally intensive, that is a well-secured > process. Using O-flag that can be exploited by an attacker without > sufficient protection, as currently defined in the draft, is risky and > raises the question of benefit vs. risk. It might be that the benefit of > the O-flag is marginal comparing to the risk and complexity its > introductions brings in SRv6. > > [ZA] RFC8754 defines the notion of an SR domain and use of SRH within the > SR domain. The use of O-flag defined in this document is restricted to an > SR domain. Similar to the SID manipulation, O-flag manipulation is not > considered as a threat within the SR domain. Procedures for securing an SR > domain are defined the section 5.1 and section 7 of RFC8754. Also, SRH > Flags are protected by the HMAC TLV, as described in Section 2.1.2.1 of > [RFC8754]. We have added this description in the security section of the > draft. We have added this text to the security section (please see the rev > 10). > > - in the Introduction section, you've noted that the document > > "... includes illustrations of pinging an SRv6 SID for the SID > connectivity checks and to validate the availability of a SID ..." > > We know of two modes of path verification - continuity check (CC) and > connectivity verification (CV). The former demonstrates whether there is a > path between two network systems. The latter - is to verify that only > packets transmitted on that particular connection reach the system. If > these commonly accepted definitions of CC and CV also applicable in this > document, what is verified by "SID connectivity check"? Also, can you > point to the definition of availability metric that, according to the > statement, is being validated by pinging a SID? > > > > [ZA] Thanks for offline discussion and suggested text. The text is updated > using the suggested text in rev. 10. > > > > > - if "classic IPv6 loopback address", as the document suggests is > "2001:DB8:A:k::/128", perhaps you can point out a document that established > that tradition. > > [ZA] The use of this addressing is merely for illustration. There is no > prior tradition that is referenced or future tradition that is suggested. > Perhaps s/ classic IPv6 loopback address/ IPv6 loopback address will > address your comment > > > > - The O-flag has been introduced as > > The O-flag in SRH is used as a marking-bit in the user packets to > trigger the telemetry data collection and export at the segment > endpoints. > I think that the definition leaves an open question of whether the O-flag > can be set in a test packet originated in the SRv6 domain. For example, can > the O-flag be set on BFD control packets periodically transmitted by the > SRv6 node? > > > > [ZA] In Section 2.1.1, the draft has specific text for handing test > packets: “The OAM process MUST NOT process the copy of the packet or > respond to any upper-layer header (like ICMP, UDP, etc.) payload to prevent > multiple evaluations of the datagram.” > > > - Pseudocode S01.1 suggests that an implementation that supports the > O-flag makes a copy of the marked packet and punts that copy to the control > plane. Such processing seems to create a new DoS attack vector even though > the Security Considerations section does not acknowledge that. It appears > that that part of processing should be discussed in the Security > Considerations section and mechanisms to mitigate the threat explained. > > [ZA] Section 2.1.1. says: “The processing node SHOULD rate-limit the > number of packets punted to the OAM process to avoid hitting any > performance impact.”. This is the mitigation for DoS attacks. However, > you correctly note that text is needed in the security section. We’ve > added the following: > > [ZA] Added Text: As noted in section 7.1 of <xref target="RFC8754"/>, > compromised nodes within the SR domain may mount attacks. The O-flag may be > set by an attacking node attempting a denial-of-service attack on the OAM > process at the segment endpoint node. An implementation correctly > implementing the rate limiting in section 2.1.1 would not be susceptible to > that denial-of-service attack. > > - In the explanation of traceroute through the reference model some > entity is referenced as hop2. What is it? > > [ZA] It is actually 2nd hop in the traceroute output, which corresponds > to link3 in the Figure 1. Your comment is addressed by: s/hop2/ link3 in > the sample traceroute output > > - Perhaps s/SRv6 capable/SRv6-capable/ > > [ZA] change made in rev 10. > > - Section 3.2.2 describes SID tracing using UDP transport for a test > packet. I couldn't find information on the selection of the destination UDP > port number for tracing SID. What is it? > > [ZA] There is no new UDP port assignment for tracing SID. The UDP ports > assigned for “traceroute use” in the following IANA registry are used: > https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml. > Added text in 3.2.2. > > > > - Should note that the method to sample a data flow, described in > Section 3.3, is similar to what can be achieved using IOAM's Direct > Export trace type > <https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-direct-export/>. > Also, the Hybrid Two-Step method of collecting the telemetry > information > <https://datatracker.ietf.org/doc/draft-mirsky-ippm-hybrid-two-step/> > may result in fewer additional packets and simplify the correlation of the > collected data. > > [ZA] As discussed offline, I do not think comparison of approaches is > appropriate. > > Regards, > > Greg >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
