Re: [Tsv-art] Tsvart early review of draft-ietf-ippm-ioam-direct-export-06

[Colin Perkins <[e-mail]>]

Hi,

Apologies – I realise I’m replying to this very late.

> On 4 Oct 2021, at 08:13, Tal Mizrahi <[e-mail]> wrote:
> 
> Dear Colin,
> 
> Thanks for the feedback.
> 
> Please see below a comment and a question regarding your feedback.
> 
> 
> On Fri, Sep 3, 2021 at 5:54 PM Colin Perkins via Datatracker
> <[e-mail]> wrote:
> [snip]
> 
>> It may be worth considering to require the exporting mechanism to perform an
>> authenticated handshake with the destination to which it will export data, to
>> gain explicit consent to export the data to that destination, before starting
>> to send exported data.
> 
> [TM] The point is well-taken. The following text edit is proposed,
> borrowing some of the text from your comment:
> 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.
> 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.  Specifically, an IOAM node that
>   performs DEX exporting MUST send the exported data to a pre-
>   configured trusted receiving entity. Furthermore, an IOAM node
>   MUST gain explicit consent to export data to a receiving entity before
>   starting to send exported data.

Something like that would seem appropriate. 

>> It may also be worth considering to add authentication
>> of IOAM DEX triggers, to ensure they come from a known and trusted source,
>> before acting on export requests.
>> 
> 
> [TM] Can you please clarify what you mean by "add authentication of
> IOAM DEX triggers"? What is the threat that you have in mind?


As the security considerations section notes, there’s a risk that an attackers could inject a spoof packet containing an export trigger. One way to prevent that would be to use a digital signature to authenticate the trigger messages as being from an authorised source. Maybe the larger IOAM framework already includes this, or a discussion of why it’s not appropriate, in which case it’s sufficient to add a (clearer) reference to that discussion. But if not, then the draft could usefully either add that, or add some discussion about why it’s not needed/appropriate. 

-- 
Colin Perkins
https://csperkins.org/