Subject: [Last-Call] Last-call comments on OAM in SRv6 draft

From: Greg Mirsky <[email-masked]>
Date: Sat, 20 Mar 2021 14:03:25 -0700

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.
   - 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?

   - 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.
   - 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?

   - 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.
   - In the explanation of traceroute through the reference model some
   entity is referenced as hop2. What is it?
   - Perhaps s/SRv6 capable/SRv6-capable/
   - 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?
   - 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.

Regards,
Greg