Skip to main content

Last Call Review of draft-ietf-6man-spring-srv6-oam-09
review-ietf-6man-spring-srv6-oam-09-secdir-lc-harkins-2021-04-15-00

Request Review of draft-ietf-6man-spring-srv6-oam
Requested revision No specific revision (document currently at 13)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2021-03-22
Requested 2021-03-08
Authors Zafar Ali , Clarence Filsfils , Satoru Matsushima , Daniel Voyer , Mach Chen
Draft last updated 2021-04-15
Completed reviews Rtgdir Last Call review of -09 by Stig Venaas (diff)
Tsvart Last Call review of -09 by Magnus Westerlund (diff)
Secdir Last Call review of -09 by Dan Harkins (diff)
Genart Last Call review of -09 by Matt Joras (diff)
Opsdir Last Call review of -10 by Dan Romascanu (diff)
Intdir Telechat review of -10 by Carlos J. Bernardos (diff)
Secdir Telechat review of -10 by Dan Harkins (diff)
Assignment Reviewer Dan Harkins
State Completed
Review review-ietf-6man-spring-srv6-oam-09-secdir-lc-harkins-2021-04-15
Posted at https://mailarchive.ietf.org/arch/msg/secdir/FeTu7x7-okw7w7-T6dZRFhJHpAo
Reviewed revision 09 (document currently at 13)
Result Has Issues
Completed 2021-04-08
review-ietf-6man-spring-srv6-oam-09-secdir-lc-harkins-2021-04-15-00
   Hello,

   First of all, my apologies for the tardiness of this review....

   I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

The summary of the review is (almost) Ready With Issues.

   This draft defines a flag in the Segment Routing Header that when
set will result a copy of the packet being made and forwarded for
"telemetry data collection and export." That has tremendous security
and privacy implications that are not mentioned at all in the Security
Considerations. The Security Considerations just say that there's
nothing here beyond those described in <list of other RFCs>. I don't
think that's the case.

   Maybe I'm completely missing something but this sounds to me like
it enables what we used to call "service spy mode" on a router-- take
a flow and fork a copy off to someone else. I think there needs to be
a lot more discussion of the implications of this.

   Again, sorry for the tardiness of this review.

   regards,

   Dan.

-- 
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius