Roman Danyliw's Discuss on draft-ietf-6man-spring-srv6-oam-11: (with DISCUSS and COMMENT)

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

Roman Danyliw has entered the following ballot position for
draft-ietf-6man-spring-srv6-oam-11: 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/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6man-spring-srv6-oam/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

The privacy implications of the O-flag needs to be more clearly articulated. 
It provides a dual use capability -- there is tangible benefit for OAM use
cases, but also reduces the friction for surveillance uses cases.

The SECDIR review
(https://mailarchive.ietf.org/arch/msg/secdir/FeTu7x7-okw7w7-T6dZRFhJHpAo/)
pointed this out in -09.  The changes made to the Security Considerations in
-10 were helpful, but primarily focused on reiterating the security assumptions
of the SR domain boundary and the degree of protection of the SRH.

My recommendation would be for an explicit Privacy Considerations section with
the following (approximate) text:

NEW
7.  Privacy Considerations

The per-packet marking capabilities of the O-flag provides a granular mechanism
to collect telemetry.  When this collection is deployed by an operator with
knowledge and consent of the users, it will enable a variety of diagnostics and
monitoring to support the OAM and security operations use cases needed for
resilient network operations.  However, this collection mechanism will also
provide an explicit protocol mechanism to operators for surveillance and
pervasive monitoring use cases done contrary to the users’ consent.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you to Dan Harkins for the SECDIR review.

** Section 5.  Even with the trust assumptions of the SR domain, it would be
worth mentioning that:

The security properties of the channel used to send exported packets marked by
the O-flag will depend on the specific OAM processes used.  An on-path attacker
able to observe this OAM channel could conduct traffic analysis, or potentially
eavesdropping (depending on the OAM configuration), of this telemetry for the
entire SR domain from such a vantage point.

** Section 5.  Per “Additionally, SRH Flags are protected by the HMAC TLV, as
described in Section 2.1.2.1 of [RFC8754]”, I didn’t follow to what this was
referring to.  Also, isn’t this TLV optional?