Re: [ippm] Zaheduzzaman Sarker's Discuss on draft-ietf-ippm-ioam-direct-export-09: (with DISCUSS)

[Tal Mizrahi <[e-mail]>]

Dear Zahed,

Thanks for the comments.

Here is an  updated version of the draft:
https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-direct-export/

Regarding the following DISCUSS point:

[snip]
> Thanks to Colin Perkins for his valuable TSVART review. I find the TSVART early
> reviewer's concern on rate limiting the exported traffic triggered by DEX
> Option-type as only protection mechanism
> (https://mailarchive.ietf.org/arch/msg/tsv-art/1WNgYWGJmxLd4f3RAiDk-LJ-S8Y/)
> very valid but haven't seen it addressed. In this discuss, I would like to
> bring back attention to that concern and would like to discuss why there should
> not be a circuit breaker kind of functionality required here?
[snip]

The rate limiting is just one of the security measures in this
document. There was a long discussion in the IPPM working group about
amplification attacks and how to mitigate them:
https://mailarchive.ietf.org/arch/msg/ippm/PyfokOEsBBCTtRdNYG-Vr-674Nw/
https://mailarchive.ietf.org/arch/msg/ippm/JNiX94A7fN6tUPsA-VQizQEBWms/

Following this discussion, what we came up with in order to mitigate
these attacks is a combination of the following components:
- Rate limiting (1/N) at the encap node.
- Export traffic rate limiting (1/N) at the exporting node.
- No exporting over DEX-enabled tunnels.
- The DEX option is not pushed into packets that already include an IOAM encap.
- Exporting over a secure connection to a trusted destination.

We believe that this combination of components, which are discussed in
the document, provides reasonable measures to address the threat.

Please let us know what you think.

Thanks,
Tal.



On Thu, Jun 30, 2022 at 12:20 AM Zaheduzzaman Sarker via Datatracker
<[e-mail]> wrote:
>
> Zaheduzzaman Sarker 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 https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-direct-export/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Thanks for working on this specification.
>
> Thanks to Colin Perkins for his valuable TSVART review. I find the TSVART early
> reviewer's concern on rate limiting the exported traffic triggered by DEX
> Option-type as only protection mechanism
> (https://mailarchive.ietf.org/arch/msg/tsv-art/1WNgYWGJmxLd4f3RAiDk-LJ-S8Y/)
> very valid but haven't seen it addressed. In this discuss, I would like to
> bring back attention to that concern and would like to discuss why there should
> not be a circuit breaker kind of functionality required here?
>
> I also think this specification should be explicit about not exporting IOAM
> data to any receiver outside of IOAM limited domain. Hence supporting Roman's
> discuss.
>
> for example - The introduction section can state-
>
> OLD text-
>
>    A
>    "receiving entity" in this context can be, for example, an external
>    collector, analyzer, controller, decapsulating node, or a software
>    module in one of the IOAM nodes.
>
> New text-
>
>    A
>    "receiving entity" in this context can be, for example, an external
>    collector, analyzer, controller, decapsulating node, or a software
>    module in one of the IOAM nodes with in IOAM limited domain.
>
>
>
>
>