Re: [ippm] Roman Danyliw's Discuss on draft-ietf-ippm-ioam-direct-export-09: (with DISCUSS and COMMENT)

[Martin Duke <[e-mail]>]

To summarize discussion of this review from the telechat:

- We agree that the design intends for export to leave the domain, and that
this is in principle acceptable. It would be good to make this somewhat
more explicit early in the text.

- Roman would like to see further discussion of the security/privacy
implications of this. We are exploding the assumption that IOAM is a purely
single-domain operation. Are there opportunities for traffic analysis? Are
there any assumptions related to limited domains that have to be
re-examined?

Do the authors have any ideas on what could go here?

On Wed, Jun 29, 2022 at 6:35 AM Roman Danyliw via Datatracker <
[e-mail]> wrote:

> Roman Danyliw has entered the following ballot position for
> draft-ietf-ippm-ioam-direct-export-09: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-direct-export/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> It isn’t clear whether DEX can be exported outside of the IOAM domain.  If
> it
> can, more is needed to describe the implications.  There are the following
> related statements:
>
> (a) Section 3.1.2 says:
>    Exported packets SHOULD NOT be exported over a path or a tunnel that
>    is subject to IOAM direct exporting.
>
> (b) Section 6 says:
>    IOAM is assumed to be deployed in a restricted administrative domain,
>    thus limiting the scope of the threats above and their affect.  This
>    is a fundamental assumption with respect to the security aspects of
>    IOAM, as further discussed in [RFC9197].
>
> (c) Section 6 says:
>    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.
>
> Statement (b) is the usual caveat that IOAM traffic stays inside the
> domain.
> However, this new option type is something different – there are the
> packets
> themselves and the telemetry generated from them (i.e., the export
> packets).
> Statement (c) is clear and helpful but doesn’t resolve if these entities
> are in
> the IOAM domain.  Statement (a) seems to mitigation for not creating loops
> but
> like (c) silent on clarifying whether in the IOAM domain.
>
> If export can only happen in the IOAM domain, consider adding something as
> simple as the following in the Security Considerations:
>
> NEW:
> DEX exporting MUST NOT be to entities outside of the IOAM domain.
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thank you to Stephen Farrell for the SECDIR review.
>
>
>
>