Subject: [ippm] DEX Draft Updated

From: Tal Mizrahi <[email-masked]>
Date: Thu, 1 Jul 2021 15:54:30 +0300

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 <[email-masked]> 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
>
>

---

From: Martin Duke <[email-masked]>
Date: Thu, 1 Jul 2021 12:16:41 -0700

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 <[email-masked]>
wrote:

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

---

From: Tal Mizrahi <[email-masked]>
Date: Mon, 12 Jul 2021 13:45:10 +0300

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 <[email-masked]> wrote:
> (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."
>
> 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 <[email-masked]> wrote:
>>
>> Hi,
>>

---

From: Martin Duke <[email-masked]>
Date: Mon, 12 Jul 2021 08:13:29 -0700

Looks good to me.