Re: [Last-Call] [ippm] Last Call: <draft-ietf-ippm-ioam-data-11.txt> (Data Fields for In-situ OAM) to Proposed Standard

Greg Mirsky <> Tue, 24 November 2020 21:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1E0A73A0C11; Tue, 24 Nov 2020 13:30:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, 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 nTzpWt9z2GXd; Tue, 24 Nov 2020 13:30:45 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 387853A0C0E; Tue, 24 Nov 2020 13:30:45 -0800 (PST)
Received: by with SMTP id j205so141028lfj.6; Tue, 24 Nov 2020 13:30:45 -0800 (PST)
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=fjUNX8qphKiCuEWrPCMFp/845p/wOQ28jgTco3Em8l0=; b=IFo14a24GhhXPiPZLP4W4gU2V4ZXc5DV7YVxJQbcS9aEvSC4LSLULtctJKkcf+VK0p 7bnTbDPpfQclq7mT9nRYWZdMdvuKT6qSCR3wCRSpONOsl/K0YZNzYUEuAQJq30rm/ivv VEkE1odwWuymHfLbVhI4ctZ9BrsSfR4lkoQGokyEtCZF0VlX/bQvBKdrecl1Q9ZXCo4b 0lnFSwl+n7jPZq27AV/6LQ/Ug6jT02/rMa5QFLCjOnvWSYR22fIvIKasL6YCurvC9tN+ hK4/LirIFs6t9UK3eDA2O2afjWv2qKNzPpX6vHZeIXswErXkQKqvFokg3TYy9R4cwq4R iWpg==
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=fjUNX8qphKiCuEWrPCMFp/845p/wOQ28jgTco3Em8l0=; b=I20un9aAbojnR+Hje79zyJqE7TrKnUASvwjJPVH/lTFMWh+i75hBEN3/HxwUO+B5hE FX/vleCnuIH+SOvo5GUzTK/41Ux77eyo34FHqMnxB7QY4OtnnDFl0vDTMsOo2V5g/81M mvAIsMOou5kywiRp8m4wG6a56wcLHOsMrELVbKrxqAoRqZnJCbxJsrE/qNleFE1QYmdQ mScEkiPzQJLU40ZowX+WXrRy0AiO6b4XYyYde3UoP9IeVbfaBqAx+pmw1K5bN6uCWucK VtjKkFVXRS7iNqHKL5oXWuLEzsQT+IgRAVV+b/dldIjZbgXatj2QyggYBkkHzGAlDrX4 Tp1g==
X-Gm-Message-State: AOAM532fXT5/RJ6N4nxDm2zmn0QCpz6jNpF0x8qapthtWO3CXL/Co+ZZ /Ael0byQsMjsiFxSv5Ggkv6TtnF9WJEeU70SUAHeO+Sf
X-Google-Smtp-Source: ABdhPJyz872gurwA+V6Ukz6TQk40rWjjLMYIRVla48wr4CnF41LWhagsU9Yct2GbBnRdnewnP+SLfpjoNLHXb5R34II=
X-Received: by 2002:a05:6512:1102:: with SMTP id l2mr40723lfg.500.1606253443033; Tue, 24 Nov 2020 13:30:43 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Greg Mirsky <>
Date: Tue, 24 Nov 2020 13:30:31 -0800
Message-ID: <>
Cc: "MORTON, ALFRED C (AL)" <>, IPPM Chairs <>,, IETF IPPM WG <>
Content-Type: multipart/alternative; boundary="000000000000e42ea305b4e105bd"
Archived-At: <>
Subject: Re: [Last-Call] [ippm] Last Call: <draft-ietf-ippm-ioam-data-11.txt> (Data Fields for In-situ OAM) to Proposed Standard
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Last Calls <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 24 Nov 2020 21:30:52 -0000

Dear All,
I have several comments related to the security aspects of this

   - although this draft does not define network-specific encapsulation of
   IAOM data, it would the right place to introduce a generic method of IAOM
   data integrity protection. As noted in the Security Considerations section,
   IOAM trace options and collected information may become the target of a
   malicious attack. Protecting the integrity of data with HMAC seems like the
   right option. It seems reasonable that the text used to calculate HMAC
   includes in addition to the IOAM trace option header and an IOAM node data
   field that uniquely identify the source of the packet that includes IOAM
   trace. For example, in an IP network, the IP source address can be
   concatenated with the IAOM trace option header. The integrity of each IAOM
   node data record can also be protected by HMAC. The data record can be
   concatenated with, for example, the IOAM option header to form the text
   used in the calculation of the HMAC. While the detailed construction of the
   text used in HMAC calculation could be provided in network-specific
   documents, it seems appropriate to require the optional use of HMAC for the
   integrity protection of the IOAM option header and IOAM data record in this
   - I have some concern over using the Checksum Complement in the IPv6
   network. RFC 6936 provided us with the most detailed analysis for using
   zero UDP checksum in the IPv6 network. As I understand the purpose of the
   Checksum Complement, its security impact is similar to the one of using
   zero UDP checksum. I think that the use of Checksum Complement in the IPv6
   network should be explicitly discussed in the document. I'd recommend
   adding the reference to RFC 6936 and provide arguments supporting the use
   of the Checksum Complement in the IPv6 network.


On Tue, Nov 24, 2020 at 10:25 AM The IESG <> wrote:

> The IESG has received a request from the IP Performance Measurement WG
> (ippm)
> to consider the following document: - 'Data Fields for In-situ OAM'
>   <draft-ietf-ippm-ioam-data-11.txt> as Proposed Standard
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> mailing lists by 2020-12-08. Exceptionally, comments
> may
> be sent to instead. In either case, please retain the
> beginning
> of the Subject line to allow automated sorting.
> Abstract
>    In-situ Operations, Administration, and Maintenance (IOAM) records
>    operational and telemetry information in the packet while the packet
>    traverses a path between two points in the network.  This document
>    discusses the data fields and associated data types for in-situ OAM.
>    In-situ OAM data fields can be encapsulated into a variety of
>    protocols such as NSH, Segment Routing, Geneve, IPv6 (via extension
>    header), or IPv4.  In-situ OAM can be used to complement OAM
>    mechanisms based on e.g.  ICMP or other types of probe packets.
> The file can be obtained via
> The following IPR Declarations may be related to this I-D:
> _______________________________________________
> ippm mailing list