Re: [bess] John Scudder's Discuss on draft-ietf-bess-srv6-services-11: (with DISCUSS and COMMENT)

[Robert Raszuk <[e-mail]>]

Hi John,

As you have quoted my note in point #4 I feel that I need to comment on it.

So yes original discussions and major contributions of this work were
focusing on VPN use case and I admit when carefully re- reading it to find
some text there beyond VPN use case.

So we discussed it among co-authors. The point of adding 5.3 & 5.4 is
targeting the networks where Internet routes are not present at each node
and network uses summarization of infrastructure routes (no end to end /128
leaking in the IGP).

The text perhaps may require some clarification that use of SAFI 1 is left
for the operators to choose if the attribute should be attached to Internet
routes - when operator is offering an IP transit or it can be attached just
to next hops which are part of the infrastructure. Let's also not forget
that if this is IP transit in most networks you can reach all hops along
the path anyway (modulo transit SP/ISP policy).

I think major concern expressed from Warren was the potential compromise to
the VPNs when SID demuxing it would leak. Well as we know SAFI 128 or 70
are not public. Yes customer may advertise his routes to SAFI 1 and leak
but no one has control over it and it is orthogonal to what happens in the
SP network.

With that I think that #3 and #4 are no longer a concern.

Best regards,
Robert


On Wed, Feb 16, 2022 at 10:39 PM John Scudder via Datatracker <
[e-mail]> wrote:

> John Scudder has entered the following ballot position for
> draft-ietf-bess-srv6-services-11: 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/blog/handling-iesg-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-bess-srv6-services/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> 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.)
>
>
>
>