Suresh,
Thank you for the explanation.
See my comments & questions added below:
Linda
-----Original Message-----
From: Suresh Krishnan <suresh.krishnan@xxxxxxxxx>
Sent: Thursday, October 26, 2023 9:54 AM
To: Linda Dunbar <linda.dunbar@xxxxxxxxxxxxx>
Cc: secdir@xxxxxxxx; draft-ietf-6man-sids.all@xxxxxxxx; ipv6@xxxxxxxx; last-call@xxxxxxxx
Subject: Re: Secdir last call review of draft-ietf-6man-sids-03
From: Suresh Krishnan <suresh.krishnan@xxxxxxxxx>
Sent: Thursday, October 26, 2023 9:54 AM
To: Linda Dunbar <linda.dunbar@xxxxxxxxxxxxx>
Cc: secdir@xxxxxxxx; draft-ietf-6man-sids.all@xxxxxxxx; ipv6@xxxxxxxx; last-call@xxxxxxxx
Subject: Re: Secdir last call review of draft-ietf-6man-sids-03
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.
[Linda] It would be very helpful to add the following explanation to Section 3:
- When both SRH and IPv6 Hop-by-hop Extension header are present in the packet, does the intermediate nodes process the Hop-by-Hop header in the same way as if there is no SRH?
- There are lots of studies showing that IPv6 packets with Extension Headers tend to be dropped in the network. Does it happen to IPv6 packets with SRH?
- If IPv6 addresses not compliant with the requirement set forth in RFC4291 get forwarded without error, why need the requirements of RFC4291?
>
> 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
