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

[Zaheduzzaman Sarker <[e-mail]>]

Hi,

The proposed change looks good to me. With this I will clear my discuss. Thanks for working on making this specification better.

//Zahed

> On 19 Sep 2022, at 14:54, Tal Mizrahi <[e-mail]> wrote:
> 
> 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