Skip to main content

Last Call Review of draft-ietf-6man-sids-03
review-ietf-6man-sids-03-secdir-lc-dunbar-2023-10-25-00

Request Review of draft-ietf-6man-sids
Requested revision No specific revision (document currently at 06)
Type IETF Last Call Review
Team Security Area Directorate (secdir)
Deadline 2023-10-27
Requested 2023-10-13
Authors Suresh Krishnan
I-D last updated 2024-10-21 (Latest revision 2024-02-15)
Completed reviews Dnsdir Telechat review of -05 by Petr Špaček (diff)
Secdir Telechat review of -05 by Linda Dunbar (diff)
Intdir Telechat review of -05 by Juan-Carlos Zúñiga (diff)
Opsdir IETF Last Call review of -03 by Yingzhen Qu (diff)
Secdir IETF Last Call review of -03 by Linda Dunbar (diff)
Genart IETF Last Call review of -03 by Reese Enghardt (diff)
Assignment Reviewer Linda Dunbar
State Completed
Request IETF Last Call review on draft-ietf-6man-sids by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/qXm0DYie1S4Iu9jathX7EKjs140
Reviewed revision 03 (document currently at 06)
Result Not ready
Completed 2023-10-25
review-ietf-6man-sids-03-secdir-lc-dunbar-2023-10-25-00
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.

Summary: this document is intended to clarify the relationship of SRv6 SIDs to
the IPv6 Addressing Architecture.

Major issue:
The document explains the SRv6 SID characteristics very well, which was the
repeat of RFC8754. As the SRv6 SID is the same as the IPv6 address, the
document fails to explain if there are any forwarding behavior differences on
the  non-SRv6 capable intermediate nodes. As the intermediate SRv6 nodes use
the next SID (a standard IPv6 address) as the packet's outer destination, does
it mean that those non-SRv6 intermediate nodes forward the packets the same as
before?  If Yes, why need this document?

What if a malicious Man-in-middle actor alters the SID sequence in the SRH? and
a non-SRv6 intermediate node does not having the address in its Forwarding
Table?

Thank you,
Linda