Re: [ippm] Adoption call for draft-mizrahi-ippm-ioam-flags Re: Regarding draft-mizrahi-ippm-ioam-flags

Tom Herbert <> Wed, 31 July 2019 22:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 39046120086 for <>; Wed, 31 Jul 2019 15:40:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 wZE3adgMx3v0 for <>; Wed, 31 Jul 2019 15:40:43 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::442]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EAA73120073 for <>; Wed, 31 Jul 2019 15:40:42 -0700 (PDT)
Received: by with SMTP id c2so68185279wrm.8 for <>; Wed, 31 Jul 2019 15:40:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=BiwEaMjqBdA9mBl8V+PcdTExK8ptjDxyYGPlH8yiSZw=; b=pDh9oQQpYI0yNSYaXT9EhsjM6dU5L1pgjihzxIjhZUB5r0W+UHuQo1BYLorT96ckt5 bi0lSs60PbgOlZmrRa+OEDQDXn4X6Jz2ufNWThFYseDKuZaYp0VcW8BZSk8pBYKtyhbx yu+XqjzAa66VX471V9jx2tGCe8Gsp41DAwLe/JlzcdxbNwejnKdXWjJ5EHBdRxlW+On3 oLvFThKFuRUiLF1R0lxoiabL7HNQF1ygTH312Q2fAwl2wFrcV+4lb8+rIfzrUZiEjw+0 PLpG8wfgVzIxhzq7FoS4CdUqRPtp+NX8ZrlTohHdTCwIGWIPf6DvPYNdkoWRf601jWEz LQcg==
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=BiwEaMjqBdA9mBl8V+PcdTExK8ptjDxyYGPlH8yiSZw=; b=gQiaggmnxyydr/9fu4gvtKM3ihZ2TNHEEXeEbk9Myuogw8OU39JAyv4tcJvwP261Uw A994c2xt3Tj8rNxvi3JyhKWn+g//ZPalaC+wbt97xFpDcfmt9jez5Z7Jvd0QJKPquCjG Qb2ko400AvIz2qv6EXnmhdWhUta2xTcJPZd/OeEBVCJWSmq6pegHizDBktlRhJwPWObv F4isaRt8UShssHTZ/BPryUI5FyKz5dtliOH+POEUgLL7Yk2yO30D6cT6qr8dnKCC6zjQ S1jASBARouDP1su0EAxm9HdyWYpLtMDR+sNY4bOd7q9xi2Fjarudizbo8vUYsUqZIGrf fo2g==
X-Gm-Message-State: APjAAAXVSDZv5qM2/fsraXJ7i8hvtLAqO2lOgIEy6k7043WblwpltJyY tY11ZX/y6UxjshccnpcdeebPfOf5Cy/LwZMnbKw=
X-Google-Smtp-Source: APXvYqyGKSQo0b8B19/sBHkETZ4JihKOZi/aqWikpfiFJmj4hXRHQ8u2CbgmS2PZwzSiFiKcXQ92SeXLD60OdCYw32Y=
X-Received: by 2002:a5d:51c1:: with SMTP id n1mr2771265wrv.254.1564612841211; Wed, 31 Jul 2019 15:40:41 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Tom Herbert <>
Date: Wed, 31 Jul 2019 15:40:30 -0700
Message-ID: <>
To: Greg Mirsky <>
Cc: "Brian Trammell (IETF)" <>, IPPM Chairs <>, IETF IPPM WG <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [ippm] Adoption call for draft-mizrahi-ippm-ioam-flags Re: Regarding draft-mizrahi-ippm-ioam-flags
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 31 Jul 2019 22:40:45 -0000

On Wed, Jul 31, 2019 at 11:53 AM Greg Mirsky <> wrote:
> Dear Authors,
> thank you for bringing this proposal for the discussion. When considering WG AP, I use the following criteria:
> is the document reasonably well-written;
> does it addresses a practical problem;
> is the proposed solution viable?
> On the first point, I commend you - the draft is easy to read.
> On the second point, I have several questions:
> What is the benefit of using Loopback flag in the Trace mode?

This is unclear to me also. Additionally, I am concerned that protocol
blindly reflects the packet back to the source without any regard to
what else the packet contains. For instance, if a TCP packet is
reflected by ten intermediate nodes this is nonsensical. The
possibility of an amplification attack is obvious and in fact
mentioned in the security section, however I'm skeptical that the
proposed mitigation of rate limiting is sufficient.

Minimally, it seems like the reflected packets should be wrapped in
ICMP to mitigate spoofing attacks. Also, I wonder if traceroute
methodology could be used for tracing, i.e. one sent packet results in
at most one return packet (ICMP), to mitigate the amplification


> Why is it important to limit the applicability of Loopback to only Trace mode?
> What is the benefit of collecting the same, as I understand the description, data on the return path to the source?
> What is the benefit of using Active flag comparing to existing active OAM protocols?
> What is the benefit of using Immediate flag comparing to Postcard-Based Telemetry (PBT) proposal?
> On the third point, I'd appreciate your clarification on these points:
> In which transports (I find that iOAM encapsulation has been proposed for all known transports) you've envisioned to use Loopback flag?
> The third bullet in Section 5 refers to a replica of the data packet that follows the same path as the original packet. What controls that replication?
> The last paragraph in the Security Consideration section relies on "restricted administrative domain" to mitigate the threat of malicious attacks using a combination of iOAM extensions. That might be the case when operating in a PNF environment, but it is much more challenging to maintain such a trusted domain in VNF environment. How can these new security risks be mitigated in a VNF environment?
> Appreciate your consideration and clarifications to my questions.
> Regards,
> Greg
> On Thu, Jul 25, 2019 at 2:07 PM Brian Trammell (IETF) <> wrote:
>> hi Greg,
>> Thanks for the feedback; absolutely, we can do this the normal way. Authors: let's do a normal two-week adoption call for this document before publishing the update.
>> This adoption call starts now.
>> IPPM, please respond to this message with an indication to the mailing list of your support for adopting draft-mizrahi-ippm-ioam-flags as a working group document, in partial fulfillment of our charter milestone "submit a Standards Track draft on inband OAM based measurement methodologies to the IESG" (obviously, depending on how many documents we end up sending to the IESG, we may have to change the plurality of this milestone). If you do not support this, please send a message to the list explaining why.
>> Thanks, cheers,
>> Brian (as IPPM co-chair)
>> > On 25 Jul 2019, at 13:15, Greg Mirsky <> wrote:
>> >
>> > Dear Chairs, et al.,
>> > I appreciate that editors of draft-ietf-ippm-ioam-data followed on the decision of the WG reached at the meeting in Prague to extract material not directly related to the definition of iOAM data elements from the document. The new draft was presented earlier this week and generated many comments. I feel that it would be right to discuss the draft and its relevance to the charter of the IPPM WG before starting WG adoption poll.
>> >
>> > Regards,
>> > Greg
> _______________________________________________
> ippm mailing list