Skip to main content

SRv6 Segment Identifiers in the IPv6 Addressing Architecture
draft-ietf-6man-sids-06

Note: This ballot was opened for revision 05 and is now closed.

Erik Kline
Yes
Gunter Van de Velde
No Objection
Comment (2024-04-08) Not sent
reviewed draft-ietf-6man-sids-06

I like the clarifications introduced with latest revision.
Jim Guichard
(was Discuss) No Objection
John Scudder
(was Discuss) No Objection
Comment (2024-02-21) Sent
Thanks for the update.
Murray Kucherawy
No Objection
Comment (2024-01-30 for -05) Sent
I support John Scudder's DISCUSS.  I also support Jim Guichard's DISCUSS, except for the minor nit that I wouldn't use a normative "MAY" in an abstract.
Paul Wouters
No Objection
Comment (2024-01-31 for -05) Sent
I too support the DISCUSS position of Andrew, Jim and John and of Warren's ABSTAIN position.

As this is currently being deployed with leaks, I think the prefix has a chance to improve
things with vendors putting in default block rules for these prefixes in their devices. I
don't think it will makes things worse. Networks not using/blocking these prefixes won't be
further harmed by this document's actions.
Roman Danyliw
No Objection
Comment (2024-01-31 for -05) Not sent
I support the DISCUSS position of Andrew, Jim and John.

I am also supportive of the security concerns raised by Warren in his ABSTAIN position.
Zaheduzzaman Sarker
No Objection
Comment (2024-02-01 for -05) Not sent
Thanks for working on this document. This document is not related to transport protocol aspects, hence no objection.

It was clear to me that this informational draft is for the "transit node" and I think the prefix would be helpful for filtering. However, I also don't think it solves the related security concerns.
Éric Vyncke
No Objection
Comment (2024-01-31 for -05) Sent
# Éric Vyncke, INT AD, comments for draft-ietf-6man-sids-05

Thank you for the work put into this very much needed document. It is short, straight to the points, and not easy to write albeit easy to read with the logical flow.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Jen Linkova for the shepherd's detailed write-up including the WG consensus _and_ the justification of the intended status.

Other thanks to Juan-Carlos Zúñiga, the Internet directorate reviewer (at my request), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-6man-sids-05-intdir-telechat-zuniga-2024-01-30/

Other thanks to Petr Špaček, the DNS directorate reviewer (at my request), please consider this dns-dir review:
https://datatracker.ietf.org/doc/review-ietf-6man-sids-05-dnsdir-telechat-spacek-2024-01-15/ (and I have read Suresh's reply)

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS (non-blocking)

## Abstract

Like others, I would suggest moving the last sentence (about the prefix) in a separate paragraph (as it is not closely related to the rest of the paragraph) and use "may" (non-normative as it is informational).

## Use of BCP14 terminology

Is the BCP14 template required in an informational document? I only saw one "SHOULD" about the DNS part.

## Section 4.1

This should be removed before publication probably via a note to the RFC editor.

## Section 7

Should there be a recommendation to filter 5ff0::/16 via routing (e.g., static route to /dev/null, or adding it to the global martians/bogons list) rather than ACL -- this could be easier / more performant ? Or would it be too BCP-like ?

# NITS (non-blocking / cosmetic)

## Section 5

s/As an added factor of safety/As an added factor of security/ ? I.e., "safety" is often used when physical harm done to a living being/animal.
Warren Kumari
Abstain
Comment (2024-01-30 for -05) Not sent
I am balloting Abstain (a non-blocking position) because there is no way to ballot Discuss on one part of a document and NoObj (or Yes) on another part. 

Abstain" means "I cannot support sending this document forward.", and I'm using it in the "I oppose this document but understand that others differ and am not going to stand in the way of the others." sense (see https://www.ietf.org/standards/process/iesg-ballots/ for the subtleties).


The DISCUSSy part:
I am still deeply concerned about the security, operational and architectural implications of stuffing something other than an IP address in the source or destination fields of a packet. I understand why the document is so handwavey about whether or not SIDS are IP addresses (e.g: "Due to this 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."), and think that the author has done a good job of dancing around this point -- but it's still an issue for me.

Now the NoObj part:
One of my primary concerns with SRv6 is that these can and do leak (both inbound and outbound). For this reason, I'm supportive of there being a prefix set aside for this use. The document says that "usage of the prefix allocated by this document improves security by making it simpler to filter traffic at the edge of the SR domains." -- this is true, but it is only a marginal improvement; operators still need to manually filter at the edge of the domain. Having a prefix set aside this just makes it that you do the moral equivalent of 'deny ipv6 any 5f00::/16' instead of 'deny ipv6 any {some_internal_prefix_I_have_to_remember}::/32'. There is also the advantage that I can filter this range inbound and if I see any packets hitting the filter, I can tell that my neighbor is leaking -- so, yes, this is an improvement, but it's not a massive one. If the document also specified a default behavior of dropping packets with these addresses, or that device vendors could provide syntactic sugar to help with the filtering, I'd be much more supportive.

But, again, an abstain is not a blocking position...
Andrew Alston Former IESG member
Discuss
Discuss [Treat as non-blocking comment] (2024-02-01 for -05) Sent
*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?
Robert Wilton Former IESG member
No Objection
No Objection (2024-01-29 for -05) Sent
Hi Suresh,

Thanks for this draft.  I believe that allocating a block for SID allocation is a good idea.

A couple of minor comments on the document:

Minor level comments:

(1) p 4, sec 4.1.  Applicability to other forms of compressed SIDs

   The spring working group is in the process of analyzing multiple
   mechanisms for compressing the SRv6 SID list as described in
   [I-D.ietf-spring-compression-analysis].  Even though this document
   focuses on [CSID], the considerations specified in this document
   might also be applicable to the other mechanisms being analyzed and
   compared.

I was slightly confused by the reference to 'this' document, which I interpreted to be referring to this draft (i.e., the one on the telechat) which doesn't focus or discuss CSIDs at all.  Possibly it would be clearer to refer the document as 'that document'?

E.g.,
                                            Even though that document
   focuses on [CSID], the considerations specified in this document
   might also be applicable to the other mechanisms being analyzed and
   compared.



Nit level comments:

(2) p 3, sec 3.  SRv6 SIDs and the IPv6 Addressing Architecture

   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.  They look and act similar to other mechanisms that use
   IPv6 addresses with different formats such as [RFC6052] that defines
   the IPv6 Addressing of IPv4/IPv6 Translators and [RFC7343] that
   describes ORCHIDv2 (a cryptographic hash identifier format).

Perhaps 'look and act similarly'?

Regards,
Rob