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

Greg Mirsky <gregimirsky@gmail.com> Sat, 20 March 2021 21:03 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86EA23A2A82; Sat, 20 Mar 2021 14:03:41 -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 OCigbxPCdTIg; Sat, 20 Mar 2021 14:03:39 -0700 (PDT)
Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 E48033A2A80; Sat, 20 Mar 2021 14:03:38 -0700 (PDT)
Received: by mail-lf1-x12c.google.com with SMTP id x28so15303119lfu.6; Sat, 20 Mar 2021 14:03:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=OvubLs+UEbq6anMobIQMniV3USNBSOniziGA68bx2rE=; b=XAKO2NW7nam0pecSp1IMRP7b5jY5/L0PrcaGHUbSFcK8RlCH0maR+ARQYmEEjuFspm iP1EzD7gbrMzG5cqkWaRLuZ9z5XFHj7t9CYGHCMUKgZnHuzlpv5aJj7G1+yZ0G+zPiXL U1yFH84M7CKRKwj6UqVdqe7q/t+UZ8bltLBrLAxJ5ebe0fPehzn/QNSm0xb4ZxzrgJkO EHiFKKlMz9yCOW4PepFIdBX0W1W6ZDDLll9WKv+s/Nv6HDbjrel00GkQjFYH50gKbfKn tMNM9YX5G0lt9AxSCpOxiMrdhQVRjrfGq6O70pjLsYniJDhYKsUavmPYL4a16xGBcKr6 mXBA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=OvubLs+UEbq6anMobIQMniV3USNBSOniziGA68bx2rE=; b=pHvlyfgNqxRnzSNXmqipuALJ0YpZcB87n/g2oP6114sQFIhIGvKsc3sCwSNFDbUWzG vK5FhcTyAQ1JbTYQxHiQErDRKW3a9+zfmxYD+tHVHgxcqOQrNmc8iJDF9Zb2IJBxeCVu bk+L0/shtlAqKutlO1Sn7FVF2XXh9ToMMTjaS3V/xkCFa7E1SdFeuh4bSDB8gKLUXYe4 zDUQe91VtQe3eGdzgju5UD12n6VC3F4zy8krk0L/vRQBT/kICe/wwlI55458FP7KbKOx tIFVqyk+NduOv7ZBixYtoQp9xcJp3P3CF54vEob/4fUZ1VPKQxK9T4JXXHSvMedSxf1M vL9A==
X-Gm-Message-State: AOAM530ZFSZ819mHYJ0iIbH9166+CWsaZS5tRugYSyDxWRkgLTTuynL/ 13UEBO0HFVZcsxwxvQVJo164VQj4QbCzd9a+S/jN4+xM0ZdZEg==
X-Google-Smtp-Source: ABdhPJxldu63PHVvvSVlAHpYPMn/D4xkYGtCKeiir9qVyCZdLlT0levHDRw2O5L30kd3C/lcj70AI4qGMkWZ43oijKk=
X-Received: by 2002:ac2:430b:: with SMTP id l11mr1778730lfh.350.1616274215458; Sat, 20 Mar 2021 14:03:35 -0700 (PDT)
MIME-Version: 1.0
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Sat, 20 Mar 2021 14:03:25 -0700
Message-ID: <CA+RyBmWQHOKoMryWwhWUjd12bs+V=YrctKchFyOZKU4uwQEiOQ@mail.gmail.com>
To: last-call@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="00000000000078db6f05bdfe2a48"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/DG1QDt7AhjRUs7lWDnmbv5OUabg>
Subject: [spring] Last-call comments on OAM in SRv6 draft
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 20 Mar 2021 21:03:42 -0000

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