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

Greg Mirsky <> Thu, 26 November 2020 20:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8700D3A09AC; Thu, 26 Nov 2020 12:14:59 -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 ZpjNt_Wss_IP; Thu, 26 Nov 2020 12:14:57 -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 D06803A09B7; Thu, 26 Nov 2020 12:14:56 -0800 (PST)
Received: by with SMTP id s30so4108692lfc.4; Thu, 26 Nov 2020 12:14:56 -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=ZqfUjaNXSLu8vVP8MueSMiKsIecfshWolDSACWvKstE=; b=Z3Kx+gGPUkAMoyWPHAG6Tz6WFBBB8TGqyUhD5WgCEMV2/AkVdPxbEIeC6U8AQONcbM I8sZwCFgyJQHo1CbAeq/la1VvANi+mF7ikuF1UtURjwFLJQMucyChRLmkI18Cb2zsKk9 LHQB0Bm0LLnTNN5P7AwDjbBUrAFE3RaPqoqRvfz0tN26/uK5DQyAgVtlIqGJJpbcs8dE HINPzXOZLA46XuN+82qtuFCLQDPsb2Sr4hEe+71Vj4ulwocPx5yOqjZKDnx96eGyBN5w 64L5Q+kaAOmOb1SNxE104aLsosq9f1T4ApT4Y7ctwr4msjIJO6GG4YmVPLjSHewLsIgf qPMw==
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=ZqfUjaNXSLu8vVP8MueSMiKsIecfshWolDSACWvKstE=; b=ERNtrN0HpPUO3lkxP65LZ/ZCAGR0B3x+14LuUkAO6Vk2Q3ezcze4HyX47iyy069rY8 sRhifT/DKqRDC6SvfUVQfciw+hO6c//IgaTLkE5HaVlxLZhBC+60tKGVTk57Rh0ZiA4b NzZlHe5vlzJxdkCN5feRn0gEKuqQSoiV8W8nDv6/BRaAx2Jcmom2R2Wh9ofxxM8sq+O9 bnCwAPlo9oUdsMUxZwwS1MPfnwemPUTlarBLaDZfYk5z/zERIhzy/y+gO+snA43Fxcn9 a79lsa1jv/uz0dlfzK6Z7RLD3hhC2TNIhB3dPm2vRetimyMy5rZ41JgSSgK1ofO9xrvk 7l2g==
X-Gm-Message-State: AOAM533uA76vEeMeqm1NYVwUhJ4TVE5YOCjGxqbbubVbMnSD33JAx57I A3jn/3BUKHY3/JJ36Lb/9ZuVEY+Hs5IHPNiwBTA=
X-Google-Smtp-Source: ABdhPJw82+tP4f58IojC0UsdkqJ01HnD98GjWQJJhllvV693m5mlMz5EA4NIWfIHJhJ2eLnK/koXc+pwU3pIhfSrMsA=
X-Received: by 2002:ac2:5503:: with SMTP id j3mr2034035lfk.94.1606421694787; Thu, 26 Nov 2020 12:14:54 -0800 (PST)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Greg Mirsky <>
Date: Thu, 26 Nov 2020 12:14:42 -0800
Message-ID: <>
To: Tal Mizrahi <>
Cc:, "MORTON, ALFRED C (AL)" <>, IPPM Chairs <>,, IETF IPPM WG <>
Content-Type: multipart/alternative; boundary="0000000000007a338c05b5083223"
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: Thu, 26 Nov 2020 20:15:00 -0000

Hi Tal,
thank you for your careful consideration of my comments and detailed
responses. Please find my follow-up notes in-line below under the GIM>> tag.


On Wed, Nov 25, 2020 at 1:56 AM Tal Mizrahi <>

> Hi Greg,
> Thanks for the comments.
> Please see my comments below, marked [TM].
> Thanks,
> Tal.
> 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.
GIM>> I appreciate the proposed text but am not convinced that the
limitations of the current HW platforms are a factor that should limit our
definition of the comprehensive and secure protocol. I agree, there's
always a difference between the specification of a protocol and its
implementation. How a vendor decides to implement and how an operator
chooses to deploy the protocol is outside of our control as a group the
defines the protocol specification. But I believe that the proper protocol
specification must include security mechanisms that protect data integrity.
Whether the protocol also protects the privacy of the data or relies on the
security mechanisms outside of the protocol, in my opinion, is an open
question but it should be explained in the protocol specification.

> 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
> publication.
GIM>> I think that proceeding without addressing the essential security
issue of the protocol might be premature and may produce implementations
that are vulnerable to attacks.

> > 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.
GIM>> As I recall, one of the reasons RFC 7820 was published as
Experimental was concern about the security impact of the proposed
mechanism. If my recollection of the discussion of the security impact RFC
7820 may have in a network is accurte, I'll maintain my concern regarding
the Checksum Complement option in IOAM.

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