Skip to main content

BGP Overlay Services Based on Segment Routing over IPv6 (SRv6)
draft-ietf-bess-srv6-services-15

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

Erik Kline
(was Discuss) No Objection
Comment (2022-03-21 for -13) Sent
I agree that "fail closed" is more a forwarding plane (SRv6 data plane) issue.

Thanks for all the discussion.
John Scudder
(was Discuss) No Objection
Comment (2022-03-22) Sent for earlier
Thanks for working through the issues in my DISCUSS. While I continue to be unexcited about the failure modes discussed in #2, I accept that this is long-standing practice. I hope we might aspire to do better in the future.

---old discuss for posterity:

1. The shepherd writeup for this document says “It also received an RTG DIR review and cross-reviewed with the IDR working group”. Searching in my IDR inbox and the IDR mailing list archives, I don’t find any sign of the cross-review — can you please point me to it?


2. One area of concern I would have hoped IDR might have looked into is, the document makes a creative use of the MPLS Label field of the NLRI to carry the Function part of the SID. This means the SID is effectively split across the NLRI and the Prefix-SID attribute. What are the potential error modes if the Prefix-SID attribute should be lost from the route, while the NLRI is retained?

(An obvious way of addressing this particular concern would be to define a new NLRI type with the desired semantics, instead of creatively repurposing fields within an existing NLRI type contrary to their definitions. Such an NLRI type would, for example, presumably state in its specification that if it was received without an accompanying Prefix-SID attribute, that would constitute an error.)


3. As Warren Kumari points out in his DISCUSS, “leaks happen”. Subsequent discussion turned quickly to the assertion that no, they don’t, in VPN address families. Let’s accept that claim for the sake of conversation. It’s still the case that sometimes (often?) routes are distributed from VPN address families into the Global Internet table. When this is done, by default, all the path attributes come along for the ride. Anyone who thinks this is just a hypothetical case might want to look back to (for example) significant network outages that were caused around a decade ago by leakage of BGP Attribute 128 (ATTR_SET, RFC 6368) into the global Internet.



The SIDs contained in these if-they-were-to-leak routes potentially give an attacker a means of directing packets into a VPN customer’s internal network.


4. Speaking of Warren’s DISCUSS, the shepherd’s writeup indicates “solid [WG] consensus”; however, there doesn’t seem to be consensus even amongst the authors as to whether Sections 5.3 and 5.4 are appropriate. This is a fairly fundamental disagreement! An illustration of the disagreement is https://mailarchive.ietf.org/arch/msg/bess/K1JKxGn19BXALs3rUzUAaGTZi0Y/:



“So I can see why some people may have thought oh since transport in SRv6 comes for free let's load it with services in an attribute and be done. Yes I can see that flattening this make it potentially easier (one less SAFI to enable), *but I am not sure we have reached a broad agreement here.* This comes as a consequence of moving service prefixes from MP_REACH_NLRI (perhaps new format and new SAFI) to an attribute.”



(Emphasis added.)

It's of course possible for an author to be in the rough as regards consensus, just as any other WG contributor, but it's a little unusual, and this disagreement doesn't even seem to have been previously aired. For this reason, I have to question the strength of the consensus behind this document, and ask the WG chairs to weigh in regarding whether consensus on at least this point needs to be checked before we proceed forward.


5. Finally, I have to question the length of the author list. As I’m sure you know, the guidance is to limit author lists to no more than five, other than under unusual circumstances. I would have expected to find an explanation of the circumstances around the author list of this document in the shepherd writeup; there is none. (It’s a specific check item in Guidelines to Authors of Internet-Drafts, https://www.ietf.org/how/ids/guidelines/)



The easiest way to resolve this would be to trim the author list per the suggestions in RFC 7322 §4.1.1, of course.

---comment:

1. I support Warren Kumari’s DISCUSS. 

2. (Further comments TBD and I apologize for not providing them now; I wanted to get this sent off though.)
Murray Kucherawy
No Objection
Comment (2022-02-16 for -11) Sent
Just to double-check: Are we okay with having seven authors on this document when the guidelines specify a limit of five?
Roman Danyliw
No Objection
Comment (2022-02-15 for -10) Sent
Thank you to Joseph Salowey for the SECDIR review.

Thank you to the authors for the implementation report pointer (draft-matsushima-spring-srv6-deployment-status)

I support Alvaro Retana’s DISCUSS position.

I also support Warren Kumari’s DISCUSS position.  In particular, discussing the magnitude of the exposure of an internal topology due to a BGP leak would be helpful to document.

** Section 8.  It would be worth repeating the two key security assumptions from RFC8402:

OLD
SRv6 operates within a trusted SR domain with filtering of traffic at
   the domain boundaries. 

NEW
SRv6 operates within a trusted SR domain with filtering of traffic at the domain boundaries. Likewise, there is an assumed trust model such that any node adding an SRH to the packet is assumed to be allowed to do so.
Zaheduzzaman Sarker
No Objection
Comment (2022-02-17 for -11) Not sent
Thanks for working on this specification. I looked for transport related issues and found none, hence balloting No Objection.
Éric Vyncke
(was Discuss) No Objection
Comment (2022-02-15 for -10) Sent
[updating after the intdir review] 

Thank you for the work put into this document. This protocol is important for scalable and deployable SRv6 services. With revised -10, all my blocking DISCUSS points are addressed, I am therefore clearing my DISCUSS ballot (the points are kept below for archiving). As replied by email, the -10 also addresses most of my previous COMMENTs.

Special thanks to Matthew Bocci for the shepherd's write-up including the section about the WG consensus and document history. 

Thanks as well for Ron Bonica's INT directorate review (<https://datatracker.ietf.org/doc/review-ietf-bess-srv6-services-10-intdir-telechat-bonica-2022-02-14/>), I am satisfied to see the authors exchanging with Ron on his review.

I hope that this helps to improve the document,

Regards,

-éric


# previous DISCUSS (for archiving)

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics:


## Section 3.1

"IANA registry defined in section 9.2 of [RFC8986]" but there is no section 9.2 in RFC 8986. I guess it is section 10.2. Moreover, IANA registries are usually referred to via their name/URL, e.g., https://www.iana.org/assignments/segment-routing/segment-routing.xhtml, and not by a section of the RFC that created them.

## Section 3.2.1

Where is "locator node" defined ? "locator block" is defined in section 3.1 of RFC 8986 but not the node (I can only guess that this is the "N" in the "B:N" notation used in RFC 8986).

## Section 6

Section 9 of draft-ietf-bess-evpn-igmp-mld-proxy-16 indeed defines route types 7 and 8 but it uses non IPv4-only wording. So, s/IGMP join sync route/Multicast Membership Report Synch Route/ + same for type 8.

# COMMENTS

## Section 1

More details on the encapsulation (plain IP in IPv6 ?) will be welcome in "The
   ingress PE encapsulates the payload in an outer IPv6 header where the
   destination address is the SRv6 Service SID provided by the egress
   Provider Edge (PE). "

## Section 3.2.1

The transposition field appears to be about "labels", which are not qualified. Should the reader assume that those are "MPLS labels" ? A reference to some text would be welcome. Not being a SRv6 expert (but somehow knowledgeable on the topic), all the text about transposition is completely opaque to me. 

The section 4 appears to give some information, but there should at least be a forward reference to it in section 3.2.1 or even better the section 4 should be moved before section 3.2.1.

## Section 4

This section would benefit from examples & figures.

While the specification probably works well, mapping a 128-bit IPv6 SID into what looks like a 20-bit MPLS label looks like a smart kludge (for compression efficiency) but still...

## Section 5

"...optionally insert an SRH [RFC8754] when required..." looks like an oxymoron to me, i.e., if it is required then it is no more optional. Same issue in other places (notably section 6).

5th § "the ingress PE encapsulates the payload in an outer IPv6 header", is it "payload" of the ingress packet or the whole packet itself ?

## Section 10

The protocol defined in this document is a sibling of the EPVN and other layer-3 VPN using BGP as a control plane. I would have expected to have a mostly identical security section. The similarity is indeed indicated in the 2nd § but this 2nd § would benefit by also giving the RFC titles rather than a dry list of RFCs.

The 3rd § appears a little self-contradicting to my reading. The first part rightfully confirms that SRv6 domain should be closed and makes reference to SRH and network-programming security sections, i.e., isolation/protection in the data plane. Then, the last part of this § is "Therefore, precaution is necessary to ensure that the BGP service information (including associated SRv6 SID) advertised via BGP sessions are limited to peers within this trusted SR domain. " which seems to contradict the first part. IMHO, the words "is necessary" is an overkill, something like "Precautions should be taken to ensure..." would be more appropriate.

To elaborate on the previous comment:

- isn't it *exactly* the same security issues as for EPVN and other BGP-based VPN ? So, already covered by the 2nd § ?

- even if there is yet-another BGP leak with SRv6 SID, then what are the consequences ? SRv6 data plane (as explained in the first sentences of this 3rd §) MUST be protected anyway and will protect the SRv6 domain completely, else the operator has more critical issues.

In short, readers will benefit from a shorter and clearer 3rd paragraph.

Final suggestion for the security section: what happens when the length of all sub-sub-TLVs exceeds the length of the sub-TLV ? And similar corner cases. This is of course more an implementation issue but should it be mentioned here ?

I note that the security directorate review result is "ready".
Warren Kumari
(was Discuss) Abstain
Comment (2022-03-07 for -12) Sent
With the updated text in the Security Considerations in Version 12, I'm clearing my DISCUSS.

I still don't love this (hence the Abstain), but my disquiet is caused caused by the security considerations in SRv6, not this document itself.

I'd like to specifically call out and thank Ketan Talaulikar, who did an outstanding job at communicating, addressing the concerns, and defusing the situation in general.
Martin Vigoureux Former IESG member
Yes
Yes (for -09) Unknown

                            
Alvaro Retana Former IESG member
(was Discuss) No Objection
No Objection (2022-03-17 for -12) Sent for earlier
[Thanks for addressing my DISCUSS.]
Martin Duke Former IESG member
(was Discuss) No Objection
No Objection (2022-03-17 for -12) Sent
Having received a response to my DISCUSS, it's apparently common practice in this area to have routers be non-interoperable without a priori knowledge of neighbor capabilities. I still support John Scudder's second DISCUSS, but if he's happy, I'm happy.

This document was very difficult to follow without a thorough grounding in the references, but I managed to have some comments anyway:

- I support John Scudder's second DISCUSS.

- Please expand VRF, SLA, RIB, NLRI, and all other acronyms on first use.

(3.2.1) "      The Transposition Offset MUST be less than LBL+LNL+FL+AL

      The sum of Transposition Offset and Transposition Length MUST be
      less than LBL+LNL+FL+AL"

The second condition makes the first redundant for all Transposition Length >= 0!
It makes me think there's a typo.

(5) and (6) "The SRv6 Service SID SHOULD be routable within the AS of the egress
   PE"

SHOULD? Under what circumstances would it be OK for it not to be routable? [I see Alvaro also commented on this, but I'd like to call out that Sec 6 does the same thing]
Robert Wilton Former IESG member
No Objection
No Objection (2022-03-05 for -12) Sent
Hi,

Thanks for this document.  I have no comments on this document that haven't previously been captured in other ballot positions.

I find the security section in the latest revision of the document to be significantly improved and more helpful than the previous telechat revision, so thank you for your efforts in this regard.

Rob