Re: [ippm] Roman Danyliw's Discuss on draft-ietf-ippm-ioam-direct-export-09: (with DISCUSS and COMMENT)

Martin Duke <> Thu, 30 June 2022 16:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 017F2C13CDB1; Thu, 30 Jun 2022 09:38:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.104
X-Spam-Status: No, score=-7.104 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 pq6uXYGkP5Kf; Thu, 30 Jun 2022 09:38:10 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::e30]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 15907C13CDB5; Thu, 30 Jun 2022 09:38:07 -0700 (PDT)
Received: by with SMTP id j1so18757206vsj.12; Thu, 30 Jun 2022 09:38:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=82q+UKY8OVUSYYNaszXhdHRBgIaA9hqnZG72ZMWmQ3o=; b=TEFcCtdUWDhJhAXgCRUDtwquMFABRZDNhG9pk+UuJK7armwYQpQcHwX9YqJ+/gYul4 502btJHsoe8uaXllwl3MD0FVyuI8UehpTPMv5JNxy2BImEh2cymVleEVHx88coJ+OGYC slREV9xjXbUmgfOvz+PvitfD5mA/mmdiVsMOF8P8KRGtobTr1BKeE7oBceFxaBlTkVoW cQ1kysQev0HWSqMBVjBF/cREHe7BIpnGaJyVPG7UV+VCyCDrNPkGakGQZwJLEHINDQiX mL736m0I53K8dwCCTDbM9pMN4knUt03gfUccSHNX15so4HDXNuj2J4cQrzHxqcw5kUws zWrw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=82q+UKY8OVUSYYNaszXhdHRBgIaA9hqnZG72ZMWmQ3o=; b=1R71b5r8Mcyxa77Pviob4rfVL1taZdga/jhoBuQaF5f4StQ3g6noglZyq9e6IkSNP9 IijgZXuzk7jOtA02O7d8DC4bnPjZniPEd0TiTk3fQIypfyoPWGCxV5wa15dbQNenaRNl OgYkcjRoYxs9uXtZHWpKBpA2GJFYBB6CemJJUtaI5bURZSBUvC7H4vVKmAJ0G9zMZayi VejgIGvQsZTL/5oEfkg5lua1lDa8anYkZX2WxNSsiImFjqRXkyRirtRUQENWEs4Qk+xR Ql+vPUFGprRGBOX8HCsDvf+ft+3zqSvAJNso6hJFu59NigsvThSxAEViaV+bVvzCIKAf OikA==
X-Gm-Message-State: AJIora9oxae/0wPTsbtNmIsSHoIP74/Q1MRuFQSxRJ6kAAFAfNd8g7N1 PJIGO+ENKeK97IZofR98cJXZujc8aN778Hf8JQY=
X-Google-Smtp-Source: AGRyM1uVM4qT8r7/3cAkuEZgMkWr8sO/FFAtOFJyroRNO7rEo6zqdHqEzLEa4ohNILqqqavF1gMbiTSzHheZHBvtxxI=
X-Received: by 2002:a67:e3d5:0:b0:354:453e:b2b2 with SMTP id k21-20020a67e3d5000000b00354453eb2b2mr8041130vsm.52.1656607085933; Thu, 30 Jun 2022 09:38:05 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Martin Duke <>
Date: Thu, 30 Jun 2022 09:37:55 -0700
Message-ID: <>
To: Roman Danyliw <>
Cc: The IESG <>,, IPPM Chairs <>, IETF IPPM WG <>, Tommy Pauly <>
Content-Type: multipart/alternative; boundary="000000000000e3bf7105e2ace4e0"
Archived-At: <>
Subject: Re: [ippm] Roman Danyliw's Discuss on draft-ietf-ippm-ioam-direct-export-09: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 30 Jun 2022 16:38:11 -0000

To summarize discussion of this review from the telechat:

- We agree that the design intends for export to leave the domain, and that
this is in principle acceptable. It would be good to make this somewhat
more explicit early in the text.

- Roman would like to see further discussion of the security/privacy
implications of this. We are exploding the assumption that IOAM is a purely
single-domain operation. Are there opportunities for traffic analysis? Are
there any assumptions related to limited domains that have to be

Do the authors have any ideas on what could go here?

On Wed, Jun 29, 2022 at 6:35 AM Roman Danyliw via Datatracker <> wrote:

> Roman Danyliw has entered the following ballot position for
> draft-ietf-ippm-ioam-direct-export-09: Discuss
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> Please refer to
> for more information about how to handle DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> It isn’t clear whether DEX can be exported outside of the IOAM domain.  If
> it
> can, more is needed to describe the implications.  There are the following
> related statements:
> (a) Section 3.1.2 says:
>    Exported packets SHOULD NOT be exported over a path or a tunnel that
>    is subject to IOAM direct exporting.
> (b) Section 6 says:
>    IOAM is assumed to be deployed in a restricted administrative domain,
>    thus limiting the scope of the threats above and their affect.  This
>    is a fundamental assumption with respect to the security aspects of
>    IOAM, as further discussed in [RFC9197].
> (c) Section 6 says:
>    Although the exporting method is not within the scope of this
>    document, any exporting method MUST secure the exported data from the
>    IOAM node to the receiving entity.  Specifically, an IOAM node that
>    performs DEX exporting MUST send the exported data to a pre-
>    configured trusted receiving entity.  Furthermore, an IOAM node MUST
>    gain explicit consent to export data to a receiving entity before
>    starting to send exported data.
> Statement (b) is the usual caveat that IOAM traffic stays inside the
> domain.
> However, this new option type is something different – there are the
> packets
> themselves and the telemetry generated from them (i.e., the export
> packets).
> Statement (c) is clear and helpful but doesn’t resolve if these entities
> are in
> the IOAM domain.  Statement (a) seems to mitigation for not creating loops
> but
> like (c) silent on clarifying whether in the IOAM domain.
> If export can only happen in the IOAM domain, consider adding something as
> simple as the following in the Security Considerations:
> NEW:
> DEX exporting MUST NOT be to entities outside of the IOAM domain.
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Thank you to Stephen Farrell for the SECDIR review.