Re: [spring] Last-call comments on OAM in SRv6 draft

Greg Mirsky <> Tue, 13 April 2021 17:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4B44A3A2039; Tue, 13 Apr 2021 10:34:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5sYqUpQ1teTx; Tue, 13 Apr 2021 10:34:32 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D605E3A2035; Tue, 13 Apr 2021 10:34:31 -0700 (PDT)
Received: by with SMTP id z13so11595311lfd.9; Tue, 13 Apr 2021 10:34:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=376P7hXjeOfGdGWf9ufutE3+Fd6FaIT4Kuo8wdZR38k=; b=fxUT/QfuA5m2c+8lTz6Ya/AMd+U/7gJZTmaDbD49mz3wx5g/kKhpXZCV/msI3afM7P KZE/NIHqETQK7sbkUWwn3Gb9KHYjtSv6qgfGMSMFrcB1zIFSNC+JDXzK+R4UWP9Uvcji PCuaA5K/9EBg2+OKs4Sdca3LkAJBuqnxCYN+l+j8vhZ+pPUojxf56+TZwUTIjzb29wpE VR5lHznMnZ34nyj5/Fi68MuTDYYE7RtwKg+BwhafV8kqfvSSGxhmomu8WxAGHB6+nxNQ CqxJcesG23b+DPLg3GvXek+NtolLnX4ug7fEmipLodXrThBaQOBBMFSI8KRA/aePUcY7 GNgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=376P7hXjeOfGdGWf9ufutE3+Fd6FaIT4Kuo8wdZR38k=; b=Dlp8fq1NuEQxm+huCAMoPd1e3DGCBctkj1i4wGRMfyoC25yBVNJ/A2mK9RDqVrzdeo vmw4p3//n2I/GsRNwVoPGC77aaquk4aLPCBLTqoiuADEcpLdBPtcrU2bgEQTmRCX27hJ rcUQy4CFKcbMmzHcgmAD9vct6Y6bojuEUgDLaIjFL7xHMdUKoxMLlZx5sHd/esiNinnK yq1olH0F8GVHJyi3y82d28KOgckqsY9mQkuCT4K9Xlzjoxwr3rZyM2TJQGh4LaTXpnod yg4AlFKDZm2nsW/LGQzjuISLZtNN1u2m97k8BK43bGoDfx/KMF8cQ6K59PAnb8cRNTzY 1/IQ==
X-Gm-Message-State: AOAM533+xQ9N8xuQM18Vq2IBgdMIjogPoHiFyAU/4hpKBLFfCCrbfxXk KtCOul376F7tjQ/negzU7h5TAQYU/wRVrdgbqXreAwMo/e8=
X-Google-Smtp-Source: ABdhPJyI7UsFYYKJmnWNLUC555GFl+014cAXAQ3PdOtCnTgl5FZrfe5qaD93mWlh7rVCFR53cHCktCq5d9XXlgGRhV4=
X-Received: by 2002:a05:6512:3196:: with SMTP id i22mr19121294lfe.192.1618335268234; Tue, 13 Apr 2021 10:34:28 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Greg Mirsky <>
Date: Tue, 13 Apr 2021 10:34:17 -0700
Message-ID: <>
To: "Zafar Ali (zali)" <>
Cc: "" <>, "" <>, 6man WG <>, 6man Chairs <>, spring <>
Content-Type: multipart/alternative; boundary="000000000000ca6d5705bfde0aef"
Archived-At: <>
Subject: Re: [spring] Last-call comments on OAM in SRv6 draft
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 13 Apr 2021 17:34:39 -0000

Hi Zafar,
thank you for listening to my comments and thoughtfully addressing them
with updates.
The new version looks good to me.


On Thu, Apr 8, 2021 at 11:24 PM Zafar Ali (zali) <> 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.
> The comments are addressed as in-lined with [ZA] in the following.
> Thanks
> Regards … Zafar
> *From: *Greg Mirsky <>
> *Date: *Saturday, March 20, 2021 at 5:04 PM
> *To: *"" <>, "
>" <
>>, 6man WG <>, 6man
> Chairs <>, spring <>
> *Subject: *Last-call comments on OAM in SRv6 draft
> *Resent-From: *<>
> *Resent-To: *<>, <>, <
>>, <>, <
> *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 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:
> 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