Re: [IPv6] Andrew Alston's Discuss on draft-ietf-6man-sids-05: (with DISCUSS and COMMENT)

[Suresh Krishnan <[e-mail]>]

Hi Andrew,
  Thanks for your discussion points. Please find responses inline.

> On Jan 30, 2024, at 6:36 AM, Andrew Alston via Datatracker <[e-mail]> wrote:
> 
> Andrew Alston has entered the following ballot position for
> draft-ietf-6man-sids-05: 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/about/groups/iesg/statements/handling-ballot-positions/ 
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-6man-sids/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Hi,
> 
> Thank you for the document.  There are various portions of this document that I
> feel are worthy of a discussion.
> 
> In Abstract the document states:
> 
> "Due to the underlying use of IPv6, Segment Identifiers (SIDs) used by SRv6 can
> resemble IPv6 addresses and behave like them while exhibiting slightly
> different behaviors in some situations"
> 
> I believe this to be inaccurate - you state further down in the document that
> these SID's are used by transit nodes to forward, and treated (not
> differentiated) from IPv6 addresses.

I am not sure why this is inaccurate. For transit nodes these addresses are treated like any other IPv6 packets. For nodes implementing SRv6 and having the destination address of the packet SRv6 behaviors are implemented.

>  Now, the way I see it this document is
> attempting to have this both ways - either an SRv6 SID is IPv6 address address
> - or it isn't.  If indeed it is an IPv6 address - it should conform.  

This was the exact question spring put forward to 6man to clarify. The document clearly states that SRv6 SIDs are not compliant with [RFC4291]. This is the relevant text in Section 3

"It is clear that this format for SRv6 SIDs is not compliant with the requirements set forth in [RFC4291] for IPv6 addresses but it is also clear that SRv6 SIDs are not intended for assignment onto interfaces on end hosts."

> If it's
> not - then SRv6 is indeed a separate data plane with all the caveats that come
> with that.  Further more, by stating that SID's are not IPv6 addresses, it
> creates an impression that SID's are not routable over the general internet -
> which - without special precautions / filters etc - they most certainly are. 
> Hence I have deep concerns about the impressions this document will create
> vis-a-vie the security of SRv6.

I do not see the security concern created by this document. Can you please explain an attack that is made possible by this document that is not possible otherwise?

> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Section 4.1 of the document is no longer relevant - Spring Working group is
> considering CSID (Next/Replace) and only those two, so this section of the
> document is probably unnecessary.
> 
> I would also question if since we are talking about special handling of CSID's
> - would this document not also be the correct place to deal with fact that in
> certain circumstances CSID's result in broken L4 Checksums?

Section 4.1 is there only for historical context. Since both you and Jim brought it up as a concern, I think it makes sense to remove it and leave CSID questions to spring.

Thanks
Suresh