Re: [ippm] DEX Draft Updated

Martin Duke <martin.h.duke@gmail.com> Mon, 12 July 2021 15:13 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 AC49A3A1CD8; Mon, 12 Jul 2021 08:13:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.197
X-Spam-Level:
X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[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 y5-XXumFW7_l; Mon, 12 Jul 2021 08:13:42 -0700 (PDT)
Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (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 E05F43A0D2B; Mon, 12 Jul 2021 08:13:41 -0700 (PDT)
Received: by mail-il1-x129.google.com with SMTP id z1so19907783ils.0; Mon, 12 Jul 2021 08:13:41 -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=QTaJLQn3c5HWIF0X0q233HMPDtQNckC8C87YC8xsgcE=; b=EtrKyqAgdAk+bLR0HlLJV54+GFlEe8KtxsBraZQs6e+Hy6OG3RlNUPH3dy56ezIndz E0tZEJ8VL7EC9WdFrRbyihGO8v0ZAumX4ptiG9Oi63RcrfWX3OJDze5VrYX+WSD1DzyC IObJdfA2yA3p6G8XddO9Y2Qn9ovgy7IezKyh0FrQ9clRgTaxksQtJ3zm/CvxIaW6Oz61 YljMzcmYuXONMYt7cdHvteSIUkjEhTKVUcuSAoorWxXKARqMWjfzY2Zu+LnVR9+xOHhW Es34RB0NNhZJ876JNNvRznP2pP7HGPOjExNZjuU3xRw0vw+g5uAd+Y1992yHFnjqcC5F Nc5A==
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=QTaJLQn3c5HWIF0X0q233HMPDtQNckC8C87YC8xsgcE=; b=l4bgSgsx76JUyUxwtTRJwVZQ8V00SLPQ/kXOmrS5e+8eYGTLyT8pG4cUD11rIsRtlB X/NPmUi17xQzcvA8w4o78HEnDW4Db13nGXVgGIgdA6+rWqX1xk02JrMDx3AROOhI4Chk CS7j8fXyksH1SwCh0RxchcEwg0sPvA/EBMSzANo3gnZzA2KrgjY1sDjjVjgByV22H5ed ZmwKpxAqe8bS61SNuNE5HoS5J5ProbiIaAq9Hiw9NztPzkqki92z6nTC4Oq4Id9GCqLK AMEhc8eun7U9v0F7PcL1AaxPIIcjVP86+e2ky5Y8CVCYzp8mm/1CsrJposGRX7DLysnA /XDQ==
X-Gm-Message-State: AOAM531DGXlqdp6htNnkxzs9V9q7tDZygVud/7aPUX4YGOzpQsviO/Ye 87WmXIv/PXrAHhH8rNe3EnU2A2OpfltUCTpzGrI=
X-Google-Smtp-Source: ABdhPJzoWMo1yW+8ofqq3zLbqXkhZsyQBk1Yj6t0Wok54pk5LQbGO+6O8X+GNY5wy7rKbTvMhpQcq1orX+21CvbwBM8=
X-Received: by 2002:a92:c543:: with SMTP id a3mr31204134ilj.303.1626102820667; Mon, 12 Jul 2021 08:13:40 -0700 (PDT)
MIME-Version: 1.0
References: <162514156275.10687.5210311195217579136@ietfa.amsl.com> <CABUE3Xki7N77Z1cKUtg6Y_VcGnH4nZ_b7ae6LcTxLUiac==Dvg@mail.gmail.com> <CAM4esxQtTQ_Xr5E3WdO8hd3K2OJBv5TC4LhXF1W0RQ5u7ej8Pg@mail.gmail.com> <CABUE3X=NsBDE=OSm3TT=36RruJVyiapP3cCDDaTpfW3QmTe=Gg@mail.gmail.com>
In-Reply-To: <CABUE3X=NsBDE=OSm3TT=36RruJVyiapP3cCDDaTpfW3QmTe=Gg@mail.gmail.com>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Mon, 12 Jul 2021 08:13:29 -0700
Message-ID: <CAM4esxQkCAOErDjBOEdt7tTWFm8KwVu2-iJ0jSpwzLfsYui49w@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>, draft-ietf-ippm-ioam-direct-export@ietf.org
Content-Type: multipart/alternative; boundary="000000000000fe85fe05c6ee905b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/ncWHHBrPfcSqJqQNfW3EUYR4Fcc>
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: Mon, 12 Jul 2021 15:13:47 -0000

Looks good to me.

On Mon, Jul 12, 2021 at 3:45 AM Tal Mizrahi <tal.mizrahi.phd@gmail.com>
wrote:

> Hi,
>
> An updated version of the draft has been posted.
> https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-direct-export-05
>
> Martin, Many thanks for your comments below.
> These comments have been addressed in this version of the draft.
>
> If there are no further comments about the security-related content,
> we plan to apply similar changes to the flag draft, namely consisting
> of the following components to mitigate the security issues of the
> loopback flag:
> - Selective loopback trigger for a small fraction of the traffic at
> IOAM encapsulating nodes.
> - Rate limiting of loopback response at IOAM transit nodes.
> - Avoid encapsulating IOAM-with-loopback to exported / looped back packets.
>
> These are (similar to) the main components we added to the DEX draft,
> and we believe they are relevant to the loopback flag.
>
> Cheers,
> Tal.
>
>
> On Thu, Jul 1, 2021 at 10:16 PM Martin Duke <martin.h.duke@gmail.com>
> wrote:
> >
> > 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
> >> >
> >> >
>