Re: Last-call comments on OAM in SRv6 draft

Greg Mirsky <gregimirsky@gmail.com> Tue, 13 April 2021 17:34 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B44A3A2039; Tue, 13 Apr 2021 10:34:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5sYqUpQ1teTx; Tue, 13 Apr 2021 10:34:32 -0700 (PDT)
Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D605E3A2035; Tue, 13 Apr 2021 10:34:31 -0700 (PDT)
Received: by mail-lf1-x12b.google.com with SMTP id z13so11595311lfd.9; Tue, 13 Apr 2021 10:34:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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: <CA+RyBmWQHOKoMryWwhWUjd12bs+V=YrctKchFyOZKU4uwQEiOQ@mail.gmail.com> <04FBBB8B-2666-4CC8-8039-232C14C738DD@cisco.com>
In-Reply-To: <04FBBB8B-2666-4CC8-8039-232C14C738DD@cisco.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Tue, 13 Apr 2021 10:34:17 -0700
Message-ID: <CA+RyBmX_wfo1mnkJPoeRHxi2a0U4rvByJjhL7D1xKByyca-2gw@mail.gmail.com>
Subject: Re: Last-call comments on OAM in SRv6 draft
To: "Zafar Ali (zali)" <zali@cisco.com>
Cc: "last-call@ietf.org" <last-call@ietf.org>, "draft-ietf-6man-spring-srv6-oam@ietf.org" <draft-ietf-6man-spring-srv6-oam@ietf.org>, 6man WG <ipv6@ietf.org>, 6man Chairs <6man-chairs@ietf.org>, spring <spring@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ca6d5705bfde0aef"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/h437Odu2fJGD4X7NauakVU2H_FE>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Apr 2021 17:34:38 -0000

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) <zali@cisco.com> 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 <gregimirsky@gmail.com>
> *Date: *Saturday, March 20, 2021 at 5:04 PM
> *To: *"last-call@ietf.org" <last-call@ietf.org>, "
> draft-ietf-6man-spring-srv6-oam@ietf.org" <
> draft-ietf-6man-spring-srv6-oam@ietf.org>, 6man WG <ipv6@ietf.org>, 6man
> Chairs <6man-chairs@ietf.org>, spring <spring@ietf.org>
> *Subject: *Last-call comments on OAM in SRv6 draft
> *Resent-From: *<alias-bounces@ietf.org>
> *Resent-To: *<zali@cisco.com>, <cfilsfil@cisco.com>, <
> satoru.matsushima@g.softbank.co.jp>, <daniel.voyer@bell.ca>, <
> mach.chen@huawei.com>
> *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
>