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

[Roman Danyliw via Datatracker <[e-mail]>]

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.