Re: [ippm] DEX Draft Updated

Martin Duke <martin.h.duke@gmail.com> Thu, 01 July 2021 19:16 UTC

Return-Path: <martin.h.duke@gmail.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA1B73A176E; Thu, 1 Jul 2021 12:16:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
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: 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 KPVBEBqqZh50; Thu, 1 Jul 2021 12:16:53 -0700 (PDT)
Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 423A03A1776; Thu, 1 Jul 2021 12:16:53 -0700 (PDT)
Received: by mail-il1-x134.google.com with SMTP id g3so6208586ilq.10; Thu, 01 Jul 2021 12:16:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fM05K8C4eKGH0Y9UKdxFfASdDRHn52tvbRxs1WjkwG0=; b=cBnfQU8nhL1KC1AqJ0XljqZIXYpoygCtLOEfvdH4i6EHPvUsQiIUo8RED4KLDOCe5X 1hAMo1GQqsM40DilwzTNXvQGgfmFk0hZ41jz5pC5P3hRBQZ3nMiCDNBY4PXpMklfjEou 4VYO7D+peIdh7kWUqauFZ4BkqoVwYI0z/Qd9t/BW8W8WhK5tddKI+oPoPQH1lRy4+hBh QFZ5LI0jhMk2gJfdaAXjXjQQDSATeoXkZIFpN+/x/P7Ougv+Uekc7rIFqHQl4GggmkNK 9S2Oogga+SW2HfxnoBzRYe/fAF2fJRAKVEIpuba5gNGEKViYyzhJqSxGuTdIBhUAjT4O 1c0Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fM05K8C4eKGH0Y9UKdxFfASdDRHn52tvbRxs1WjkwG0=; b=YeHdziAKU0vtafyHWVbqaRveCJKwnJF980rk/+GgQS/6VKbyjwFiXDev1bVsu7UkWo iOLguzwKTHCd78VbT4cG223GZ1evGsMo6ry9MYsM/5XvrFCYj1EDVed5J2aOVgekA17I uGEzz5uxUSQeEPCHLWlYKKGtPVwCylNSae0fm801qsq5kzJeEFX4fUOESLkrbURPNsPL M998weQ3xPDup+TfL/cxzgkKFoLMqqMpTVMfil0CbaezRERU7FQBhLIuyYldssO0z6wu FBPdFBRcMO7W//svB9iw+PPekocZICNqJ0Rmix4MCX4mikV1G2W93UwjySL1IohK+qX/ FO/g==
X-Gm-Message-State: AOAM532dVDJxj1RYwRauldHszjKEM915uKIZa+nfVLf/DI5JClFCwqcO iB9L+Qg+aXN1Ta/luCQKJQ5Cr7vNbSZRRiVdsrE=
X-Google-Smtp-Source: ABdhPJxJ6OOYTxJX68nF3NMC0SgNgAht1l0gxonzyz1dhDb7P6yxALpmWjCmdVOpFS6IlCyeUAE+eJOKsUrS43Zobd8=
X-Received: by 2002:a92:1901:: with SMTP id 1mr668862ilz.237.1625167012052; Thu, 01 Jul 2021 12:16:52 -0700 (PDT)
MIME-Version: 1.0
References: <162514156275.10687.5210311195217579136@ietfa.amsl.com> <CABUE3Xki7N77Z1cKUtg6Y_VcGnH4nZ_b7ae6LcTxLUiac==Dvg@mail.gmail.com>
In-Reply-To: <CABUE3Xki7N77Z1cKUtg6Y_VcGnH4nZ_b7ae6LcTxLUiac==Dvg@mail.gmail.com>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Thu, 1 Jul 2021 12:16:41 -0700
Message-ID: <CAM4esxQtTQ_Xr5E3WdO8hd3K2OJBv5TC4LhXF1W0RQ5u7ej8Pg@mail.gmail.com>
To: Tal Mizrahi <tal.mizrahi.phd@gmail.com>
Cc: IETF IPPM WG <ippm@ietf.org>, IPPM Chairs <ippm-chairs@ietf.org>, Mirja Kuehlewind <ietf@kuehlewind.net>, Barak Gafni <gbarak@nvidia.com>, Frank Brockners <fbrockne@cisco.com>, Haoyu Song <haoyu.song@huawei.com>, Ramesh Sivakolundu <sramesh@cisco.com>, Shwetha Bhandari <shwetha.bhandari@thoughtspot.com>, Tianran Zhou <zhoutianran@huawei.com>, Zhenbin Li <lizhenbin@huawei.com>
Content-Type: multipart/alternative; boundary="00000000000074475c05c614aef4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/GyDzhKjqXT9e1FERKkGxp9CHGYc>
X-Mailman-Approved-At: Thu, 01 Jul 2021 12:21:41 -0700
Subject: Re: [ippm] DEX Draft Updated
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Jul 2021 19:16:58 -0000

Hi Tal,

Thanks for the changes. Some comments on the diff:

(3.1.2) - "The rate of exported packets SHOULD be limited so that the
number of exported
packets is significantly lower than the number of packets that are exported
by the device."

I think there's a typo here? s/exported/received in the second instance?

- s/SHOULD not/SHOULD NOT

- "Furthermore, IOAM encapsulating
  nodes that push a DEX option into traversing packets MUST avoid
  pushing an IOAM header into IOAM exported packets."

but the DEX format is undefined, so I don't know how they could possibly
meet this requirement in the general case. Instead, perhaps
"Furthermore, IOAM encapsulation nodes that can identify a packet as an
IOAM direct export MUST NOT insert a DEX option in those packets"

On Thu, Jul 1, 2021 at 5:54 AM Tal Mizrahi <tal.mizrahi.phd@gmail.com>
wrote:

> Hi,
>
> The draft was significantly revised (see links below) following the
> security-related feedback from the last IETF meeting, and based on
> further discussion that were held at the IOAM design team meetings.
>
> Thanks again, Martin and Mirja, for your feedback.
>
> The main changes compared to the previous version:
> - Two sections were added, "DEX Packet Selection", and "Responding to
> the DEX Trigger". These two sections are specifically intended to
> address Martin's feedback regarding amplification attacks.
> - New requirements were added to the security consideration section in
> response to the comments in the last IETF meeting:
>   - Selective DEX at IOAM encapsulating nodes - in response to
> Martin's comments.
>     and
>   - Rate limiting at IOAM transit nodes - in response to Martin's comments.
>
>   - Avoid pushing the DEX option onto exported packets - in response
> to Martin's comments.
>
>   - Only export to trusted nodes - in response to Mirja's comments.
>
> Please let us know if there are further comments, and specifically
> regarding the security aspects of the draft.
>
> Cheers,
> Tal.
>
>
>
> On Thu, Jul 1, 2021 at 3:12 PM <internet-drafts@ietf.org> wrote:
> >
> >
> > A new version of I-D, draft-ietf-ippm-ioam-direct-export-04.txt
> > has been successfully submitted by Tal Mizrahi and posted to the
> > IETF repository.
> >
> > Name:           draft-ietf-ippm-ioam-direct-export
> > Revision:       04
> > Title:          In-situ OAM Direct Exporting
> > Document date:  2021-07-01
> > Group:          ippm
> > Pages:          12
> > URL:
> https://www.ietf.org/archive/id/draft-ietf-ippm-ioam-direct-export-04.txt
> > Status:
> https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-direct-export/
> > Htmlized:
> https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-direct-export
> > Diff:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-ioam-direct-export-04
> >
> > Abstract:
> >    In-situ Operations, Administration, and Maintenance (IOAM) is used
> >    for recording and collecting operational and telemetry information.
> >    Specifically, IOAM allows telemetry data to be pushed into data
> >    packets while they traverse the network.  This document introduces a
> >    new IOAM option type called the Direct Export (DEX) option, which is
> >    used as a trigger for IOAM data to be directly exported or locally
> >    aggregated without being pushed into in-flight data packets.  The
> >    exporting method and format are outside the scope of this document.
> >
> >
> >
> >
> > The IETF Secretariat
> >
> >
>