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

[Tal Mizrahi <[e-mail]>]

Dear Colin,

Thanks again for your review.
I am revisiting this thread as the draft is in IETF last call.

I believe most of the comment have already been addressed - see the
current version of the draft:
https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-flags-08

There is one comment that is still outstanding, regarding your comment
about integrity protection. We propose to add the following paragraph
to the Security Considerations section:

   The integrity of the DEX option can be protected through
   a mechanism of the encapsulating protocol, or by incorporating
   the mechanisms specified in [I-D.ietf-ippm-ioam-data-integrity].

If there are no further comments, we will include this paragraph in
the next version of the draft.

Thanks,
Tal.

On Fri, Nov 26, 2021 at 3:40 PM Colin Perkins <[e-mail]> wrote:
>
> 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/
>
>
>
>