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 <gregimirsky@xxxxxxxxx>
Date: Saturday, March 20, 2021 at 5:04 PM
To: "last-call@xxxxxxxx" <last-call@xxxxxxxx>, "draft-ietf-6man-spring-srv6-oam@xxxxxxxx" <draft-ietf-6man-spring-srv6-oam@xxxxxxxx>, 6man WG <ipv6@xxxxxxxx>, 6man Chairs <6man-chairs@xxxxxxxx>, spring <spring@xxxxxxxx>
Subject: Last-call comments on OAM in SRv6 draft
Resent-From: <alias-bounces@xxxxxxxx>
Resent-To: <zali@xxxxxxxxx>, <cfilsfil@xxxxxxxxx>, <satoru.matsushima@xxxxxxxxxxxxxxxx>, <daniel.voyer@xxxxxxx>, <mach.chen@xxxxxxxxxx>
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. Also, the Hybrid Two-Step method of collecting the telemetry information 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
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
