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

[Andrew Alston via Datatracker <[e-mail]>]

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:
----------------------------------------------------------------------

*Updated* - While unusual and having now gone through this with even more
diligence - I am adding certain additional points to this discuss ballot.

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.  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.  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.

The document states:

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.

However - this would seem to conflict with RFC8402 which states:

Hosts MAY be part of an SR domain.  A centralized controller can
   inform hosts about policies either by pushing these policies to hosts
   or by responding to requests from hosts.

A host participating in an SR domain is going to almost certainly have
interaction with those SID's.

Further - While this document seems to wish to hand wave about if a SID is or
isn't an IPv6 address - RFC8402 states explicitly that it is in Section 2 of
the terminology - which states: SRv6 SID: an IPv6 address explicitly associated
with the segment.

This is further reiterated in section 3.1.3 on RFC8402 which states:

 When SR is used over the IPv6 data plane:

   o  A Prefix-SID is an IPv6 address.

Basically - as stated above this document seems to have it both ways - and this
may be because while a SID clearly does not conform to RFC4291 - it is also
clear from RFC8402 that according to the authors - SID's are IPv6 addresses. 
This leaves this document in a very difficult position since it seems to want
it both ways.  I believe if we are going to say that SID's are not conformant
to RFC4291 - this constitutes an errata in RFC8402 (Or worthy of a -BIS) to
make it clear that these are NOT IPv6 addresses.  But I do not see how a
document can seem to have it both ways while the architectural basis for
Segment Routing as found in RFC8402 makes explicitly contradictory statements.

It is possible that this could be addressed by changing this document into a
BIS that resolves the conflicts found above?


----------------------------------------------------------------------
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?