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

Tal Mizrahi <> Wed, 25 November 2020 09:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DC9643A07C0; Wed, 25 Nov 2020 01:56:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, 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 dke1epQi8sjp; Wed, 25 Nov 2020 01:56:27 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1EF503A07BD; Wed, 25 Nov 2020 01:56:27 -0800 (PST)
Received: by with SMTP id 23so1246427wrc.8; Wed, 25 Nov 2020 01:56:27 -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:content-transfer-encoding; bh=qCut7MWvYETKgedf4vTlUsf3411eMFmyQEkjfP7qpd8=; b=eDZ202tJKnznZwjEt/E/yAQGafEJzzRoVFR10mjw+opd315ecO842c1hLhn0zb6vy3 8i1FyYgIrx94RdhZUqu4Km0nzk73frlEb9s24WjZPEfTdcBxi5MrJgbLte2REGOAPEtq 7owdmAKQDVG7lRYERGxLFVMyqtWklRBqdxMIlZAX9F3+rGsIlr4UaXWeJF5OFMNLWZWx wahdltdsg5ldxh0NjDPTQktKAqaEqOiPcrPx41aNbkkOaW/937t9MYpeyELQ+9r8IRBQ pivOXQ+FuMP2BwHSGn7oitx91koKYKg2lX2aUxTwBdVXc9vTcN/cuyHHSTjjgjeSPvjQ Gc6A==
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:content-transfer-encoding; bh=qCut7MWvYETKgedf4vTlUsf3411eMFmyQEkjfP7qpd8=; b=edCXdTg27m6L2ch/aRIbVffzATaFFcijY2VtQLnfXudb5iZsPAbaf5p5gqs4P0SoVl dyr0c7pB8QnMLj3Ues76f0H2WeEwtOLz7dCkdVC34R1LyOcrY9v3IyRXkonZWJj6qVIt YHIRJlJnUhw/vnn6bnaavrjulEuCaUDxQqXk5A4YnMenot1PqLs9o3shec8A2NR0JNm9 cL+it0jQWuKVraPtZ9DXACjMGoLo/Uq1/K4Tt2FKmzSRjGkFaFzkKeD1/QMG3Wb6toHQ wRSms1cYhGzA3fmIpqXQHJBqhAIBINbizYgy38Uo10SftnG5zTcdN/Ssfh+g/RLSvvOf clYQ==
X-Gm-Message-State: AOAM533pKl51F+bx2/+JPYhVHjZQ4In3YLf/kR5/wNoxAMEPafobupp1 +PTHHWuzzlgGvD2VBYcZlu1UoPM4dz8hu71l020=
X-Google-Smtp-Source: ABdhPJyWrp9hPz3JIKW2vqQWfkVVlFWXGE9LDX9fs8x6UT6K6ogz2SatW4dWAiVpL95OEvX7RYJt1nLjedVcEVUbZno=
X-Received: by 2002:adf:fd06:: with SMTP id e6mr3107295wrr.206.1606298185192; Wed, 25 Nov 2020 01:56:25 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Tal Mizrahi <>
Date: Wed, 25 Nov 2020 11:56:13 +0200
Message-ID: <>
To: Greg Mirsky <>
Cc:, "MORTON, ALFRED C (AL)" <>, IPPM Chairs <>,, IETF IPPM WG <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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: Wed, 25 Nov 2020 09:56:29 -0000

Hi Greg,

Thanks for the comments.
Please see my comments below, marked [TM].


On Tue, Nov 24, 2020 at 11:30 PM Greg Mirsky <> wrote:
> Dear All,
> I have several comments related to the security aspects of this specification:
> 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 document.

[TM] Integrity protection is an important security consideration.
Thanks to your previous comments about this issue we have added the
following text to the security considerations section:

   In particular, these threats are applicable by compromising
   the integrity of IOAM data, either by maliciously modifying IOAM
   options in transit, or by injecting packets with maliciously
   generated IOAM options

Specifically, implementing HMAC by hardware devices such as switches
and routers in wire speed may be challenging.
My feeling is that even if we decided to define an HMAC, it would end
up being something that is not implemented by most vendors.

I would suggest to consider a new IOAM option that incorporates an
HMAC, which can be used alongside the conventional trace options. This
would allow an optional integrity protection capability for those
specific implementations that require it. This new option could be
defined in a new draft, allowing the data draft to proceed to

> 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.

[TM] The Checksum Complement is a field that simplifies the checksum
update for hardware switches/routers. Unlike zero checksum, the
destination *does* verify the checksum when a checksum complement is
used. Therefore, in my opinion the zero checksum considerations are
not relevant in this context.
>From a security perspective, I do not think a Checksum Complement has
any security implications. I believe it was phrased well in RFC 7820
(OWAMP/TWAMP Checksum Complement):

   It is important to emphasize that the scheme described in this
   document does not increase the protocol's vulnerability to MITM
   attacks; a MITM attacker who maliciously modifies a packet and its
   Checksum Complement is logically equivalent to a MITM attacker who
   modifies a packet and its UDP Checksum field.

> Regards,
> Greg
> 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