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

["Zafar Ali (zali)" <[e-mail]>]

Hi Roman

Many thanks for your detailed review and the comments and suggested text; much appreciated!

Thanks

Regards … Zafar


From: Roman Danyliw <[e-mail]>
Date: Monday, January 10, 2022 at 2:48 PM
To: "Zafar Ali (zali)" <[e-mail]>, The IESG <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: Roman Danyliw's Discuss on draft-ietf-6man-spring-srv6-oam-11: (with DISCUSS and COMMENT)

Hi Zafar!

Thanks for the revisions in -12.  They address my DISCUSS and COMMENTs feedback.  I’ve cleared my ballot.

Roman

From: Zafar Ali (zali) <[e-mail]>
Sent: Monday, November 29, 2021 1:45 AM
To: Roman Danyliw <[e-mail]>; The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; Ole Trøan <[e-mail]>; Zafar Ali (zali) <[e-mail]>
Subject: Re: Roman Danyliw's Discuss on draft-ietf-6man-spring-srv6-oam-11: (with DISCUSS and COMMENT)

Hi Roman,

Many thanks for your detailed review and the suggested text; highly appreciated!
I am sorry for the late follow-up on these comments (due to some personal reasons)

We have addressed your comments in the revision 12 (https://datatracker.ietf.org/doc/html/draft-ietf-6man-spring-srv6-oam-12)
Summary of how your comments are addressed is as follows:


·         A section on “Privacy Considerations” has been added with the text suggested by you; Thanks!

·         We have updated the security section with the text suggested by you

Please also see details in-lined with [ZA]

Thanks

Regards … Zafar


From: Roman Danyliw via Datatracker <[e-mail]<mailto:[e-mail]>>
Reply-To: Roman Danyliw <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, June 2, 2021 at 9:43 PM
To: The IESG <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Roman Danyliw's Discuss on draft-ietf-6man-spring-srv6-oam-11: (with DISCUSS and COMMENT)
Resent-From: <[e-mail]<mailto:[e-mail]>>
Resent-To: <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>
Resent-Date: Wednesday, June 2, 2021 at 9:43 PM

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.

[ZA] We have added section on privacy consideration with the above mentioned text suggested by you. Thanks!

----------------------------------------------------------------------
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.

[ZA] The security consideration section has been updated with your prosed text. Thanks!


** 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?

[ZA] RFC8754 includes SRH.flags field in the HMAC computation. Please see https://datatracker.ietf.org/doc/html/rfc8754#section-2.1.2.1. However, you are right, the use of HMAC in a deployment is optional.