[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
- [spring] Last-call comments on OAM in SRv6 draft Greg Mirsky
- Re: [spring] Last-call comments on OAM in SRv6 dr… Zafar Ali (zali)
- Re: [spring] Last-call comments on OAM in SRv6 dr… Greg Mirsky