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

[Tal Mizrahi <[e-mail]>]

Hi Zahed,

I propose the following text edit. Given that this is a general
requirement and the specific exporting method is not within the scope
of this document, I believe the following change seems reasonable.

OLD:
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.
NEW:
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, in order to protect the confidentiality and
guarantee the integrity of the exported data. 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 Mon, Sep 19, 2022 at 12:14 PM Zaheduzzaman Sarker
<[e-mail]> wrote:
>
> I have noticed that paragraph, however,  I didn’t interpreted that immediately to use of secure connection in that paragraph. May be we should be a bit more specific/descriptive about what is included in the "secure the export of data”.
>
> //Zahed
>
> > On 15 Sep 2022, at 17:12, Tal Mizrahi <[e-mail]> wrote:
> >
> > 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
>