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

[Tal Mizrahi <[e-mail]>]

Hi Zahed,


On Sun, Sep 11, 2022 at 8:37 PM Zaheduzzaman Sarker
<[e-mail]> wrote:

> This is good. I haven’t noticed any requirements on exporting over a secure connection to and trusted destination in this specification. I may have missed this, could you please point me to that?


Yes, the following paragraph addresses this topic:

   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 that is in the same IOAM domain
   as the exporting IOAM node.  Furthermore, an IOAM node MUST gain
   explicit consent to export data to a receiving entity before starting
   to send exported data.

Cheers,
Tal.

On Sun, Sep 11, 2022 at 8:37 PM Zaheduzzaman Sarker
<[e-mail]> wrote:
>
>
>
> > On 18 Aug 2022, at 15:16, Tal Mizrahi <[e-mail]> wrote:
> >
> > Dear Zahed,
> >
> > Thanks for the comments.
> >
> > Here is an  updated version of the draft:
> > https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-1191a6b94b1b8ef3&q=1&e=832af60a-d8a4-4ce6-b114-803e40c69f48&u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ippm-ioam-direct-export%2F
> >
> > 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://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-f1a8e03896e17207&q=1&e=832af60a-d8a4-4ce6-b114-803e40c69f48&u=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Ftsv-art%2F1WNgYWGJmxLd4f3RAiDk-LJ-S8Y%2F)
> >> 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://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-85de22596797bb61&q=1&e=832af60a-d8a4-4ce6-b114-803e40c69f48&u=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fippm%2FPyfokOEsBBCTtRdNYG-Vr-674Nw%2F
> > https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-a9aaeff04156da3d&q=1&e=832af60a-d8a4-4ce6-b114-803e40c69f48&u=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fippm%2FJNiX94A7fN6tUPsA-VQizQEBWms%2F
> >
> > 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.
>
> This is good. I haven’t noticed any requirements on exporting over a secure connection to and trusted destination in this specification. I may have missed this, could you please point me to that?
>
> //Zahed
>