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

[Martin Duke <[e-mail]>]

Zahed,

Does draft-10 address the non-Roman part of your DISCUSS?

On Thu, Aug 18, 2022 at 6:17 AM Tal Mizrahi <[e-mail]>
wrote:

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