Hi Linda, Thanks a lot for your review. Please find responses inline. > On Oct 25, 2023, at 4:38 PM, Linda Dunbar via Datatracker <noreply@xxxxxxxx> wrote: > > Reviewer: Linda Dunbar > Review result: Not Ready > > 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? Yes. For the non-SRv6 intermediate nodes (“transit nodes”) the forwarding behavior is as specified in [BCP198] and described further in Section 3. > If Yes, why need this document? This document describes how SRv6 SIDs are structured and how this structure is different from RFC4291. The fact that the SRv6 SIDs do not affect non-SRv6 transit nodes is by design and a key fact to be emphasized. The transit nodes treat them as any IPv6 destination addresses performing a longest prefix match as usual. Please let me know if you would like me to clarify any of the text in Section 3. > > 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? The packet will simply be dropped if there is no matching entry in the forwarding table (and there is no default route that would match). Furthermore, this document does not specify any new protocol operations. As mentioned in Section 7, the security considerations for the use of Segment Routing [RFC8402], SRv6 [RFC8754], and SRv6 network programming [RFC8986] apply to the use of these address.The only thing this document does on the security front is that it makes ingress/egress filtering easier by allowing the use of a well known prefix. Thanks Suresh -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
