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

Hi Justin,

Thanks for the heads up. You raised a good point.

I suggest the following text instead.

      The integrity of the DEX option can be protected through a mechanism
      of the encapsulating protocol. While [I-D.ietf-ippm-ioam-data-integrity]
      introduces an integrity protection mechanism that protects the
      integrity of IOAM data fields, the DEX option does not include IOAM
      data fields, and therefore these integrity protection mechanisms are not
      applicable to the DEX option. As discussed in the threat analysis of
      [I-D.ietf-ippm-ioam-data-integrity], injection or modification of IOAM
      option headers are threats that are not addressed in IOAM.

+ please see an additional comment below, marked [[TM]].

Cheers,
Tal.

On Tue, Jun 14, 2022 at 11:00 AM Justin Iurman <justin.iurman@uliege.be> wrote:
>
> Hi Tal,
>
> I believe the new paragraph should be:
>
>      The integrity of the DEX option can be protected through a mechanism
>      of the encapsulating protocol.
>
> Indeed, integrity protection of headers is out of scope regarding
> [I-D.ietf-ippm-ioam-data-integrity]. Only the integrity protection of
> IOAM-Data-Fields is proposed in this draft. And, the DEX Option-Type has
> no IOAM-Data-Fields, per se.
>
> Actually, [I-D.ietf-ippm-ioam-data-integrity] could be applied between
> the IOAM transit nodes and the collector (or entity, whatever it is
> called), once triggered by the DEX Option-Type.

[[TM]] Let's not go there. The exporting format is something that is
not currently within the scope of any working group document, and
specifically the integrity of the exporting format is currently out of
scope. It will be in scope once the working group adopts an exporting
format.

>
> Thanks,
> Justin
>
> On 6/14/22 09:17, Tal Mizrahi wrote:
> > 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 <csp@csperkins.org> wrote:
> >>
> >> Hi,
> >>
> >> Apologies – I realise I’m replying to this very late.
> >>
> >>> On 4 Oct 2021, at 08:13, Tal Mizrahi <tal.mizrahi.phd@gmail.com> 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
> >>> <noreply@ietf.org> 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/
> >>
> >>
> >>
> >>
> >
> > _______________________________________________
> > ippm mailing list
> > ippm@ietf.org
> > https://www.ietf.org/mailman/listinfo/ippm