Subject: [Idr] Benjamin Kaduk's Discuss on draft-ietf-idr-tunnel-encaps-20: (with DISCUSS and COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Tue, 01 Dec 2020 10:18:14 -0800

Benjamin Kaduk has entered the following ballot position for
draft-ietf-idr-tunnel-encaps-20: 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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-idr-tunnel-encaps/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I support Erik's discuss.

I see that Roman has already suggested adding normative language
regarding the limitation to a single administrative domain (in addition
to the "MUST filter by default for EBGP sessions"), which I agree with.
However, I think there is an additional consideration regarding the
limitation of use to a single administrative domain, wherein the domain
of use for the tunnel encapsulation attribute may diverge from the
domain of use of segment routing, that seems to place this document in
conflict with the requirements of RFC 8402.  In particular,
RFC 8402 says, for SR-MPLS and SRv6, that boundary routers "MUST filter
any external traffic", and additionally for SRv6 that "explicit routing
information MUST NOT be leaked through the boundaries of the
administrered domain".  In §3.7 of this document, though, we find that
for the Prefix-SID sub-TLV, "the receiving BGP speaker need not even be
in the same Segment Routing Domain as the tunnel's egress endpoint, and
there is no implication that the prefix-SID for the advertised prefix is
the same in the Segment Routing domains of the BGP speaker that
originated the sub-TLV and the BGP speaker that received it", which
seems to suggest violation of the RFC 8402 requirement.  I think we need
to have greater clarity on what relationship is actually intended
between the SR domain and the tunnel encapsulation usage domain, and if
they are to diverge, we need to both somehow rectify this behavior with
RFC 8402 and to very clearly document how the 8402-mandated filtering at
the SR domain boundary is supposed to happen when the boundary includes
tunneled traffic.

I also would like to ensure that we have had adequate discussion of the
relationship between this document and RFC 8365.  The IESG has received
comments recently (in the context of a different document) that it is
irresponsible to effectively obsolete or deprecate existing work without
identifying or explicitly updating such work, and without indicating
whose responsibility it is to find discrepancies.  That seems like it
might apply to what's currently in Appendix A, which on first reading
suggests "there might be a problem here, but we aren't saying exactly
what or how to fix it, or even who is going to do that work".

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

It's good to see that the shepherd writeup got updated as things
changed; thank you for keeping it up to date!

[I initially wrote some inline comments about handling internal
inconsistencies within a given tunnel specification as malformed and
ignoring the tunnel entirely vs specifying a precedence order (the
latter being what this document does).  I removed them, because this
seems to be a generic topic where security types tend to fail-closed and
routing types tend to aim to provide some kind of service when possible,
and I don't have anything new to add to the discussion for these
particular cases.]

I didn't see a response to the secdir review; it would be good to get a
response to that, in particular to hear what amount of consideration
has been given to what new ways this provides to attack BGP.

Abstract

   of certain other SAFIs.  This document adds support for additional
   Tunnel Types, and allows a remote tunnel endpoint address to be
   specified for each tunnel.  This document also provides support for

The shepherd writeup suggests that the "remote tunnel endpoint"
terminology was switched to be "tunnel egress endpoint"; was this spot
missed?

Section 1.4

   o  Defining a new "Tunnel Egress Endpoint sub-TLV" (Section 3.1) that
      can be included in any of the TLVs contained in the Tunnel
      Encapsulation attribute.  This sub-TLV can be used to specify the
      remote endpoint address of a particular tunnel.

["remote endpoint" again]

Section 3.1

I agree with Martin V that there must be a story about this Reserved
field and why it's only SHOULD send as zero.  I don't know whether this
information needs to end up in the RFC but I think we should talk about
why it is this way.  In particular, the current requirements suggest
that it could be (mis?)used as an additional data channel by
collaborating implementations (that ignore the "MUST be disregarded"),
without actually writing up a specification for those semantics.

   If the Address Family subfield has any value other than IPv4 or IPv6,
   the Tunnel Egress Endpoint sub-TLV is considered "unrecognized" (see

We probably need to repeat the carve-out for the value 0 here, as well.
(I dithered about remarking about the earlier "assumes that the Address
Family is either IPv4 or IPv6" since the "one special case" is a few
paragraphs later.)

   o  It can be determined that the IP address in the sub-TLV's address
      subfield does not belong to the Autonomous System (AS) that
      originated the route that contains the attribute.  Section 3.1.1
      describes an optional procedure to make this determination.

This check seems highly important for the security of the system and
should get called out in the security considerations.

Section 3.1.1

   sub-TLV is considered not to be valid.  In some cases a network
   operator who controls a set of Autonomous Systems might wish to allow
   a Tunnel Egress Endpoint to reside in an AS other than Route_AS;
   configuration MAY allow for such a case, in which case the check
   becomes, if Egress_AS is not within the configured set of permitted
   AS numbers, then the Tunnel Egress Endpoint sub-TLV is considered to
   be "malformed".

(nit?) maybe "the configured set of permitted AS numbers that contains
Route_AS"?  The current wording implies that there can only be one such
configured set and that it is used regardless of Route_AS, which does
not seem right...

Section 3.2

   This section defines Encapsulation sub-TLVs for the following tunnel
   types: VXLAN ([RFC7348]), NVGRE ([RFC7637]), MPLS-in-GRE ([RFC4023]),
   L2TPv3 ([RFC3931]), and GRE ([RFC2784]).

Thanks for putting the links all in one place, here.  I, at least, would
have benefited from also putting the links/references in the
corresponding sections, but that is probably just a matter of style.

Section 3.2.1

      R: The remaining bits in the 8-bit flags field are reserved for
      further use.  They MUST always be set to 0 by the originator of
      the sub-TLV.  Intermediate routers MUST propagate them without
      modification.  Any receiving routers MUST ignore these bits upon a
      receipt of the sub-TLV.

nit: spurious "a" in "upon a receipt" (and diffing this section against
§3.2.2 it seems that maybe the "of the sub-TLV" is also superfluous?).

   o  If the V bit is not set, and the BGP UPDATE message has AFI/SAFI
      other than Ethernet VPNs (EVPN) then the VXLAN tunnel cannot be
      used.

If this is intended to refer to SAFI 70 (from RFC 7432), I note that the
IANA entry is named "BGP EVPNs".

[I also don't understand why it's okay for EVPN to not have a VN-ID when
using the VXLAN tunnel, but assume that's just my ignorance.]

Section 3.2.2

      Reserved (two fields): MUST be set to zero on transmission and
      disregarded on receipt.

(nit) I only see one field marked "Reserved" (this format is the same
layout as for VXLAN).

   o  The values of the V, M, and R bits are NOT copied into the flags
      field of the NVGRE header.  The flags field of the VXLAN header is
      set as per [RFC7637].

(nit) stray "VXLAN"?

Section 3.2.5

   While it is not really necessary to have both the GRE and MPLS-in-GRE
   tunnel types, both are included for reasons of backwards
   compatibility.

It might be nice to have a few more words about which one is the
"backward compatible" option and what it's compatible with.

Section 3.3

   If an outer Encapsulation sub-TLV occurs in a TLV for a Tunnel Type
   that does not use the corresponding outer encapsulation, the sub-TLV
   MUST be treated as if it were an unknown type of sub-TLV.

nit: this is the only instance of "unknown" in the document; using
"unrecognized" seems to be the common case (and makes it easier to find
Section 13).

Section 3.3.1

I think we may need to discuss the semantics of the DS field here -- as
I understand it, the attribute advertised in this TLV is the DSCP value
that the BGP speaker would like to receive in traffic destined to the
tunnel egress endpoint (which may be a different node than the BGP
speaker itself, but is expected to be under the control of the same
administrative entity).  Additionally, the interpretation of DSCP values
is subject to local interpretation on a given network.  Since the tunnel
encapsulation attribute is transitive, it will be propagated potentially
across multiple BGP hops and multiple ASes, so that the tunnel ingress
endpoint is not necessarily adjacent to the tunnel egress endpoint.
Although we do say that we expect the tunnel encapsulation information
to only be propagated within an administrative boundary, there is no
guarantee that the administrative boundary in question uses a unified
DSCP handling procedure throughout it.  As such, it may be possible to
end up in a regime where the requested DSCP codepoint has a different,
and potentially hazardous, interpretation, at the ingress of the tunnel.
So, it seems that we need to say something about either local policy for
DSCP value filtering, or only using this value when "directly" connected
to the egress AS, or similar; we do have something like this already for
the TC portion of the MPLS label stack entries.

Section 3.5

   labeled address family, then the sub-TLV MUST be disregarded.  If the
   sub-TLV is contained in a TLV whose Tunnel Type does not have a
   virtual network identifier in its encapsulation header, the sub-TLV
   MUST be disregarded.  In those cases where the sub-TLV is ignored, it
   SHOULD NOT be stripped from the TLV before the route is propagated.

Why only SHOULD NOT here?  I thought we hat MUST-level requirements to
preserve things unchaged in similar situations.

Section 4.1

   In the remainder of this specification, when a route is referred to
   as containing a Tunnel Encapsulation attribute with a TLV identifying
   a particular Tunnel Type, it implicitly includes the case where the
   route contains a Tunnel Encapsulation Extended Community identifying
   that Tunnel Type.

I searched the entire document for the string "identifying" and did not
find any instances where a route was referred to as containing a Tunenl
Encapsulation attribute with a TLV identifying a particular tunnel type.
Perhaps I should be looking for the "attribute" keyword, but there are
over 200 instances of that string; could you confirm whether this
implicit inclusion is actually used anywhere (and if so, give an example
of such usage)?

Section 6

   [RFC5512] specifies the use of the Tunnel Encapsulation attribute in
   BGP UPDATE messages of AFI/SAFI 1/7 and 2/7.  That document restricts
   the use of this attribute to UPDATE messages of those SAFIs.  This
   document removes that restriction.

I believe another reviewer commented on the ambiguity of "that", which I
first thought referred to "this" vs "that"; I now see that there is
additional ambituity as to whether it is the SAFI restriction or the
UPDATE message restriction that is lifted, and suggest clarification
of that as well.

   Once it is determined to send a packet through the tunnel specified
   in a particular Tunnel TLV of a particular Tunnel Encapsulation
   attribute, then the tunnel's egress endpoint address is the IP
   address contained in the sub-TLV.  If the Tunnel TLV contains a

nit: I think we have to say "Tunnel Egress Endpoint sub-TLV"; the use of
the definite article is not justified by the preceding context.

Section 8

   However, suppose that one of the TLVs in U2's Tunnel Encapsulation
   attribute contains the Color Sub-TLV.  In that case, packet P MUST
   NOT be sent through the tunnel contained in that TLV, unless U1 is
   carrying the Color Extended Community that is identified in U2's
   Color Sub-TLV.

We should probably reword this in light of Section 13's discussion that
a given Tunnel TLV can have more than one Color sub-TLV present.

Section 9.2

   Three of the tunnel types that can be specified in a Tunnel
   Encapsulation TLV have virtual network identifier fields in their
   encapsulation headers.  In the VXLAN encapsulation, this field is
   called the VNI (Virtual Network Identifier) field; in the NVGRE
   encapsulation, this field is called the VSID (Virtual Subnet
   Identifier) field.

We start off by saying "three" types but list only two.  What's the
third type?

Section 9.2.2.2

   If the TLV identifying the tunnel does not contain an Encapsulation
   sub-TLV whose V bit is set, the virtual network identifier field of
   the encapsulation header is set as follows:

This perhaps sets us up for a nasty surprise in light of the
error-handling behavior in §13, where we are supposed to disregard the
second and subsequent instances of the Encapsulation sub-TLV.  This
language is not particularly clear about whether it applies to only the
first sub-TLV or all instances.

   o  If the TLV does not contain an Embedded Label Handling sub-TLV, or
      if it contains an Embedded Label Handling sub-TLV whose value is
      2, the embedded label is copied into the lower 3 octets of the
      virtual network identifier field of the encapsulation header.

nit: I think "lower" is unneeded, since all the VNI fields are exactly 3
octets now.

Section 10

   Note that if the Tunnel Encapsulation attribute is attached to a VPN-
   IP route [RFC4364], and if Inter-AS "option b" (see section 10 of
   [RFC4364]) is being used, and if the Tunnel Egress Endpoint sub-TLV
   contains an IP address that is not in same AS as the router receiving
   the route, it is very likely that the embedded label has been
   changed.  [...]

I'm not sure that I'm understanding this scenario properly.  The label
has been "changed" with respect to what baseline?  I'm also not sure why
the tunnel egress endpoint would need to be in the same AS as the router
receiving (vs originating) the route.

   Other documents may define other ways to signal tunnel information in
   BGP.  For example, [RFC6514] defines the "P-Multicast Service
   Interface Tunnel" (PMSI Tunnel) attribute.  In this specification, we
   do not consider the effects of advertising the Tunnel Encapsulation
   Attribute in conjunction with other forms of signaling tunnels.  Any
   document specifying such joint use should provide details as to how
   interactions should be handled.

It seems like we should perhaps go a step further and explicitly
recommend not advertising such combinations in the absence of a
specification for their combined use?  Otherwise implementations will
have to come up with their own interpretations, which could easily be
uninteroperable.

Section 13

   The following sub-TLVs defined in this document MUST NOT occur more
   than once in a given Tunnel TLV: Tunnel Egress Endpoint (discussed
   below), Encapsulation, DS, UDP Destination Port, Embedded Label
   Handling, MPLS Label Stack, Prefix-SID.  [...]

Ah, thanks for listing these out.  I had been wondering about this
situation earlier in the doc, and it would have helped if the "not more
than once" limitation was mentioned at each sub-TLV's definition (even
if the actual error handling stays here).

Section 14.3

Why do we only move "BGP Tunnel Encapsulation Attribute Sub-TLVs" (but
not "BGP Tunnel Encapsulation Attribute Tunnel Types") to the new "BGP
Tunnel Encapsulation Parameters" grouping?

Section 14.9

It might be useful to indicate in the registry metadata how many flags
are available (and, I suppose, in which order the bits are numbered).

Section 15

We briefly discuss in the main body text the possibility that a tunnel
will direct encapsulated traffic with (e.g) MPLS labels to a node that
will misinterpret those labels; it might be worth reiterating the risk
of such misinterpretation in the security considerations as well (or
just referencing the previous discussion as security-relevant).

I guess there's also a theoretical possibility that the flexibility in
tunnel specification (including the type of expected content) could
facilitate cross-protocol attacks, where the attacker causes the sender
and recipient of encapsulated traffic to think that they should
interpret the records in question as different protocols.  But this
seems so remote, and unlikely to succeed given different protocols'
message structure, that it is probably not worth mentioning.

Section 18.2

If we're using RFC 5462 as a reference for a field in an MPLS label,
that seems to make it normative.

We seem to depend on procedures from RFC 6811 in a few places, which
also seems to make it normative.

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 1 Dec 2020 14:44:26 -0500

Benjamin: 

Since the IESG has engaged in a previous discussion regarding two documents, would let me know what you think is an "adequate" discussion.  Are you looking for a joint discussion with the two working groups (IDR and BESS) on the mail list plus a written report?  Or something else? 

Thank you, Sue  

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Benjamin Kaduk via Datatracker
Sent: Tuesday, December 1, 2020 1:18 PM
To: The IESG
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: [Idr] Benjamin Kaduk's Discuss on draft-ietf-idr-tunnel-encaps-20: (with DISCUSS and COMMENT)

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

I see that Roman has already suggested adding normative language regarding the limitation to a single administrative domain (in addition to the "MUST filter by default for EBGP sessions"), which I agree with.
However, I think there is an additional consideration regarding the limitation of use to a single administrative domain, wherein the domain of use for the tunnel encapsulation attribute may diverge from the domain of use of segment routing, that seems to place this document in conflict with the requirements of RFC 8402.  In particular, RFC 8402 says, for SR-MPLS and SRv6, that boundary routers "MUST filter any external traffic", and additionally for SRv6 that "explicit routing information MUST NOT be leaked through the boundaries of the administrered domain".  In §3.7 of this document, though, we find that for the Prefix-SID sub-TLV, "the receiving BGP speaker need not even be in the same Segment Routing Domain as the tunnel's egress endpoint, and there is no implication that the prefix-SID for the advertised prefix is the same in the Segment Routing domains of the BGP speaker that originated the sub-TLV and the BGP speaker that received it", which seems to suggest violation of the RFC 8402 requirement.  I think we need to have greater clarity on what relationship is actually intended between the SR domain and the tunnel encapsulation usage domain, and if they are to diverge, we need to both somehow rectify this behavior with RFC 8402 and to very clearly document how the 8402-mandated filtering at the SR domain boundary is supposed to happen when the boundary includes tunneled traffic.

I also would like to ensure that we have had adequate discussion of the relationship between this document and RFC 8365.  The IESG has received comments recently (in the context of a different document) that it is irresponsible to effectively obsolete or deprecate existing work without identifying or explicitly updating such work, and without indicating whose responsibility it is to find discrepancies.  That seems like it might apply to what's currently in Appendix A, which on first reading suggests "there might be a problem here, but we aren't saying exactly what or how to fix it, or even who is going to do that work".

It's good to see that the shepherd writeup got updated as things changed; thank you for keeping it up to date!

[I initially wrote some inline comments about handling internal inconsistencies within a given tunnel specification as malformed and ignoring the tunnel entirely vs specifying a precedence order (the latter being what this document does).  I removed them, because this seems to be a generic topic where security types tend to fail-closed and routing types tend to aim to provide some kind of service when possible, and I don't have anything new to add to the discussion for these particular cases.]

I didn't see a response to the secdir review; it would be good to get a response to that, in particular to hear what amount of consideration has been given to what new ways this provides to attack BGP.

Abstract

The shepherd writeup suggests that the "remote tunnel endpoint"
terminology was switched to be "tunnel egress endpoint"; was this spot missed?

Section 1.4

Section 3.1

I agree with Martin V that there must be a story about this Reserved field and why it's only SHOULD send as zero.  I don't know whether this information needs to end up in the RFC but I think we should talk about why it is this way.  In particular, the current requirements suggest that it could be (mis?)used as an additional data channel by collaborating implementations (that ignore the "MUST be disregarded"), without actually writing up a specification for those semantics.

We probably need to repeat the carve-out for the value 0 here, as well.
(I dithered about remarking about the earlier "assumes that the Address Family is either IPv4 or IPv6" since the "one special case" is a few paragraphs later.)

This check seems highly important for the security of the system and should get called out in the security considerations.

Section 3.1.1

(nit?) maybe "the configured set of permitted AS numbers that contains Route_AS"?  The current wording implies that there can only be one such configured set and that it is used regardless of Route_AS, which does not seem right...

Section 3.2

Thanks for putting the links all in one place, here.  I, at least, would have benefited from also putting the links/references in the corresponding sections, but that is probably just a matter of style.

Section 3.2.1

If this is intended to refer to SAFI 70 (from RFC 7432), I note that the IANA entry is named "BGP EVPNs".

[I also don't understand why it's okay for EVPN to not have a VN-ID when using the VXLAN tunnel, but assume that's just my ignorance.]

Section 3.2.2

(nit) I only see one field marked "Reserved" (this format is the same layout as for VXLAN).

(nit) stray "VXLAN"?

Section 3.2.5

It might be nice to have a few more words about which one is the "backward compatible" option and what it's compatible with.

Section 3.3

nit: this is the only instance of "unknown" in the document; using "unrecognized" seems to be the common case (and makes it easier to find Section 13).

Section 3.3.1

I think we may need to discuss the semantics of the DS field here -- as I understand it, the attribute advertised in this TLV is the DSCP value that the BGP speaker would like to receive in traffic destined to the tunnel egress endpoint (which may be a different node than the BGP speaker itself, but is expected to be under the control of the same administrative entity).  Additionally, the interpretation of DSCP values is subject to local interpretation on a given network.  Since the tunnel encapsulation attribute is transitive, it will be propagated potentially across multiple BGP hops and multiple ASes, so that the tunnel ingress endpoint is not necessarily adjacent to the tunnel egress endpoint.
Although we do say that we expect the tunnel encapsulation information to only be propagated within an administrative boundary, there is no guarantee that the administrative boundary in question uses a unified DSCP handling procedure throughout it.  As such, it may be possible to end up in a regime where the requested DSCP codepoint has a different, and potentially hazardous, interpretation, at the ingress of the tunnel.
So, it seems that we need to say something about either local policy for DSCP value filtering, or only using this value when "directly" connected to the egress AS, or similar; we do have something like this already for the TC portion of the MPLS label stack entries.

Section 3.5

Why only SHOULD NOT here?  I thought we hat MUST-level requirements to preserve things unchaged in similar situations.

Section 4.1

I searched the entire document for the string "identifying" and did not find any instances where a route was referred to as containing a Tunenl Encapsulation attribute with a TLV identifying a particular tunnel type.
Perhaps I should be looking for the "attribute" keyword, but there are over 200 instances of that string; could you confirm whether this implicit inclusion is actually used anywhere (and if so, give an example of such usage)?

Section 6

I believe another reviewer commented on the ambiguity of "that", which I first thought referred to "this" vs "that"; I now see that there is additional ambituity as to whether it is the SAFI restriction or the UPDATE message restriction that is lifted, and suggest clarification of that as well.

nit: I think we have to say "Tunnel Egress Endpoint sub-TLV"; the use of the definite article is not justified by the preceding context.

Section 8

We should probably reword this in light of Section 13's discussion that a given Tunnel TLV can have more than one Color sub-TLV present.

Section 9.2

We start off by saying "three" types but list only two.  What's the third type?

Section 9.2.2.2

This perhaps sets us up for a nasty surprise in light of the error-handling behavior in §13, where we are supposed to disregard the second and subsequent instances of the Encapsulation sub-TLV.  This language is not particularly clear about whether it applies to only the first sub-TLV or all instances.

nit: I think "lower" is unneeded, since all the VNI fields are exactly 3 octets now.

Section 10

I'm not sure that I'm understanding this scenario properly.  The label has been "changed" with respect to what baseline?  I'm also not sure why the tunnel egress endpoint would need to be in the same AS as the router receiving (vs originating) the route.

It seems like we should perhaps go a step further and explicitly recommend not advertising such combinations in the absence of a specification for their combined use?  Otherwise implementations will have to come up with their own interpretations, which could easily be uninteroperable.

Section 13

Ah, thanks for listing these out.  I had been wondering about this situation earlier in the doc, and it would have helped if the "not more than once" limitation was mentioned at each sub-TLV's definition (even if the actual error handling stays here).

Section 14.3

Why do we only move "BGP Tunnel Encapsulation Attribute Sub-TLVs" (but not "BGP Tunnel Encapsulation Attribute Tunnel Types") to the new "BGP Tunnel Encapsulation Parameters" grouping?

Section 14.9

It might be useful to indicate in the registry metadata how many flags are available (and, I suppose, in which order the bits are numbered).

Section 15

We briefly discuss in the main body text the possibility that a tunnel will direct encapsulated traffic with (e.g) MPLS labels to a node that will misinterpret those labels; it might be worth reiterating the risk of such misinterpretation in the security considerations as well (or just referencing the previous discussion as security-relevant).

I guess there's also a theoretical possibility that the flexibility in tunnel specification (including the type of expected content) could facilitate cross-protocol attacks, where the attacker causes the sender and recipient of encapsulated traffic to think that they should interpret the records in question as different protocols.  But this seems so remote, and unlikely to succeed given different protocols'
message structure, that it is probably not worth mentioning.

Section 18.2

If we're using RFC 5462 as a reference for a field in an MPLS label, that seems to make it normative.

We seem to depend on procedures from RFC 6811 in a few places, which also seems to make it normative.

_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 1 Dec 2020 11:51:10 -0800

Hi Sue,

Thanks for asking.

I don't really have a concrete definition for "adequate", and am hoping
that the rest of the IESG can help determine that.
My primary goal here is to call the IESG's attention to the earlier
comments we had received on the other document and the question of whether
those comments apply to the matter at hand.  I expect that we will talk
about it on the telechat on thursday and that that will result in either me
clearing this discuss point or a set of concrete actionable criteria that
need to be met.

Does that help?

Thanks,

Ben

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 1 Dec 2020 15:29:53 -0500

Ben: 

Thank you for the quick response. I look forward to getting suggestions from
the IESG.  

The authors have taken care to try to carefully insert the new technology
into the deployed web of BGP technology.  I agree with the IESG stance that
it is critical to make sure we clearly state what other standards need to be
fixed when deprecate non-working technology and insert new technology. 

John, I and Alvaro discussed a number of options as he crafted the appendix
on RFC 8365.  It would be good to hear from the collective wisdom of the
Routing ADs and the IESG on this subject. 

Sue 

-----Original Message-----
From: Benjamin Kaduk [mailto:[email-masked]] 
Sent: Tuesday, December 1, 2020 2:51 PM
To: Susan Hares
Cc: 'The IESG'; [email-masked]; [email-masked];
[email-masked]
Subject: Re: [Idr] Benjamin Kaduk's Discuss on
draft-ietf-idr-tunnel-encaps-20: (with DISCUSS and COMMENT)

Hi Sue,

Thanks for asking.

I don't really have a concrete definition for "adequate", and am hoping that
the rest of the IESG can help determine that.
My primary goal here is to call the IESG's attention to the earlier comments
we had received on the other document and the question of whether those
comments apply to the matter at hand.  I expect that we will talk about it
on the telechat on thursday and that that will result in either me clearing
this discuss point or a set of concrete actionable criteria that need to be
met.

Does that help?

Thanks,

Ben

On Tue, Dec 01, 2020 at 02:44:26PM -0500, Susan Hares wrote:
> Benjamin: 
> 
> Since the IESG has engaged in a previous discussion regarding two
documents, would let me know what you think is an "adequate" discussion.
Are you looking for a joint discussion with the two working groups (IDR and
BESS) on the mail list plus a written report?  Or something else? 
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: [Idr] Benjamin Kaduk's Discuss on 
> draft-ietf-idr-tunnel-encaps-20: (with DISCUSS and COMMENT)
> 
> email addresses included in the To and CC lines. (Feel free to cut 
> this introductory paragraph, however.)
> 
> 
> Please refer to 
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> I see that Roman has already suggested adding normative language regarding
the limitation to a single administrative domain (in addition to the "MUST
filter by default for EBGP sessions"), which I agree with.
> However, I think there is an additional consideration regarding the
limitation of use to a single administrative domain, wherein the domain of
use for the tunnel encapsulation attribute may diverge from the domain of
use of segment routing, that seems to place this document in conflict with
the requirements of RFC 8402.  In particular, RFC 8402 says, for SR-MPLS and
SRv6, that boundary routers "MUST filter any external traffic", and
additionally for SRv6 that "explicit routing information MUST NOT be leaked
through the boundaries of the administrered domain".  In §3.7 of this
document, though, we find that for the Prefix-SID sub-TLV, "the receiving
BGP speaker need not even be in the same Segment Routing Domain as the
tunnel's egress endpoint, and there is no implication that the prefix-SID
for the advertised prefix is the same in the Segment Routing domains of the
BGP speaker that originated the sub-TLV and the BGP speaker that received
it", which seems to suggest violation of the RFC 8402 requirement.  I think
we need to have greater clarity on what relationship is actually intended
between the SR domain and the tunnel encapsulation usage domain, and if they
are to diverge, we need to both somehow rectify this behavior with RFC 8402
and to very clearly document how the 8402-mandated filtering at the SR
domain boundary is supposed to happen when the boundary includes tunneled
traffic.
relationship between this document and RFC 8365.  The IESG has received
comments recently (in the context of a different document) that it is
irresponsible to effectively obsolete or deprecate existing work without
identifying or explicitly updating such work, and without indicating whose
responsibility it is to find discrepancies.  That seems like it might apply
to what's currently in Appendix A, which on first reading suggests "there
might be a problem here, but we aren't saying exactly what or how to fix it,
or even who is going to do that work".
> seems to be a generic topic where security types tend to fail-closed 
> and routing types tend to aim to provide some kind of service when 
> possible, and I don't have anything new to add to the discussion for 
> these particular cases.]
> 
response to that, in particular to hear what amount of consideration has
been given to what new ways this provides to attack BGP.
missed?
> I agree with Martin V that there must be a story about this Reserved field
and why it's only SHOULD send as zero.  I don't know whether this
information needs to end up in the RFC but I think we should talk about why
it is this way.  In particular, the current requirements suggest that it
could be (mis?)used as an additional data channel by collaborating
implementations (that ignore the "MUST be disregarded"), without actually
writing up a specification for those semantics.
> (I dithered about remarking about the earlier "assumes that the 
> Address Family is either IPv4 or IPv6" since the "one special case" is 
> a few paragraphs later.)
> 
Route_AS"?  The current wording implies that there can only be one such
configured set and that it is used regardless of Route_AS, which does not
seem right...
> Thanks for putting the links all in one place, here.  I, at least, would
have benefited from also putting the links/references in the corresponding
sections, but that is probably just a matter of style.
> 
> [I also don't understand why it's okay for EVPN to not have a VN-ID 
> when using the VXLAN tunnel, but assume that's just my ignorance.]
> 
> Section 3.2.2
> 
layout as for VXLAN).
> It might be nice to have a few more words about which one is the "backward
compatible" option and what it's compatible with.
> 
> Section 3.3.1
> 
> I think we may need to discuss the semantics of the DS field here -- as I
understand it, the attribute advertised in this TLV is the DSCP value that
the BGP speaker would like to receive in traffic destined to the tunnel
egress endpoint (which may be a different node than the BGP speaker itself,
but is expected to be under the control of the same administrative entity).
Additionally, the interpretation of DSCP values is subject to local
interpretation on a given network.  Since the tunnel encapsulation attribute
is transitive, it will be propagated potentially across multiple BGP hops
and multiple ASes, so that the tunnel ingress endpoint is not necessarily
adjacent to the tunnel egress endpoint.
> Although we do say that we expect the tunnel encapsulation information to
only be propagated within an administrative boundary, there is no guarantee
that the administrative boundary in question uses a unified DSCP handling
procedure throughout it.  As such, it may be possible to end up in a regime
where the requested DSCP codepoint has a different, and potentially
hazardous, interpretation, at the ingress of the tunnel.
> So, it seems that we need to say something about either local policy for
DSCP value filtering, or only using this value when "directly" connected to
the egress AS, or similar; we do have something like this already for the TC
portion of the MPLS label stack entries.
> Perhaps I should be looking for the "attribute" keyword, but there are
over 200 instances of that string; could you confirm whether this implicit
inclusion is actually used anywhere (and if so, give an example of such
usage)?
first thought referred to "this" vs "that"; I now see that there is
additional ambituity as to whether it is the SAFI restriction or the UPDATE
message restriction that is lifted, and suggest clarification of that as
well.
> We should probably reword this in light of Section 13's discussion that a
given Tunnel TLV can have more than one Color sub-TLV present.
error-handling behavior in §13, where we are supposed to disregard the
second and subsequent instances of the Encapsulation sub-TLV.  This language
is not particularly clear about whether it applies to only the first sub-TLV
or all instances.
octets now.
> I'm not sure that I'm understanding this scenario properly.  The label has
been "changed" with respect to what baseline?  I'm also not sure why the
tunnel egress endpoint would need to be in the same AS as the router
receiving (vs originating) the route.
> It seems like we should perhaps go a step further and explicitly recommend
not advertising such combinations in the absence of a specification for
their combined use?  Otherwise implementations will have to come up with
their own interpretations, which could easily be uninteroperable.
> Ah, thanks for listing these out.  I had been wondering about this
situation earlier in the doc, and it would have helped if the "not more than
once" limitation was mentioned at each sub-TLV's definition (even if the
actual error handling stays here).
> 
> Section 14.3
> 
> Why do we only move "BGP Tunnel Encapsulation Attribute Sub-TLVs" (but not
"BGP Tunnel Encapsulation Attribute Tunnel Types") to the new "BGP Tunnel
Encapsulation Parameters" grouping?
> 
> Section 14.9
> 
> It might be useful to indicate in the registry metadata how many flags are
available (and, I suppose, in which order the bits are numbered).
> We briefly discuss in the main body text the possibility that a tunnel
will direct encapsulated traffic with (e.g) MPLS labels to a node that will
misinterpret those labels; it might be worth reiterating the risk of such
misinterpretation in the security considerations as well (or just
referencing the previous discussion as security-relevant).
tunnel specification (including the type of expected content) could
facilitate cross-protocol attacks, where the attacker causes the sender and
recipient of encapsulated traffic to think that they should interpret the
records in question as different protocols.  But this seems so remote, and
unlikely to succeed given different protocols'

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 3 Dec 2020 05:09:41 -0800

On December 1, 2020 at 1:18:15 PM, Benjamin Kaduk wrote:

Ben:

Hi!

I’m just addressing your second DISCUSS point.

Thanks!

Alvaro.

> ———————————————————————————————————
…
> what or how to fix it, or even who is going to do that work”.

First of all, the part (in §1.5) about obsoleting rfc8365 is wrong.  I
had pointed that out and expected it to be fixed, then lost track of
the updates.  To be fair to the authors, I sent my note in the middle
of the IETF week.

On to Appendix A.

rfc8365 Normatively references rfc5512 (the main RFC we're
Obsoleting).  This document includes the functionality (Encapsulation
Extended Community) that rfc8365 uses from rfc5512, so no change
there.

The functionality specified in this document (specifically carrying
the Tunnel Encapsulation Attribute in other AFI/SAFIs) means that the
attribute, and not just the Encapsulation Extended Community, could
also be used to signal the same thing.  The appendix is then pointing
out that if this "new" signaling mechanism is used then there might be
some things to consider.  But we're not making any change to rfc8365.

IOW, there's no problem, rfc8365 implementations can continue to work
as specified.

To your point about indicating who/how/where any additional work
should be done.  In general, I tend to agree with the point.  In this
case, related to rfc8365 there's nothing that has to be done.  If at
some point in the future a potential rfc8365bis wants to make use of
the Tunnel Encapsulation Attribute then it may want to consider
Appendix A.

This document is Obsoleting 2 documents.  Yes, I know the header says
3, but -21 should have also pointed at an Update (not Obsolete) for
rfc5640.

This document replaces rfc5512, so there's no work left unaddressed there.

As far as rfc5566, the WG had checked on implementations and/or
interest in updating it along with this document, but the Chairs came
up empty: no current interest or implementations.  There is however
other work that is "replacing" the IPsec functionality described in
rfc5566 (but independent of it):
draft-dunbar-idr-sdwan-edge-discovery,
draft-sajassi-besss-secure-evpn, and draft-hujun-idr-bgp-ipsec.

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 3 Dec 2020 06:04:31 -0800

Hi Alvaro,

Thanks for this; it causes a lot of the pieces to fit together better and
make sense.

Regarding just one thing:

> related to rfc8365 there's nothing that has to be done.

The Appendix does mention that "a review of Section 8.3.1 of RFC 8365 is
called for" regarding the split horizon procedures.  Am I correct in
understanding that this review is only needed in the case that someone
decides to use RFC 8365 with the expanded functionality provided by the
Tunnel Encapsulation Attribute (rather than the preexisting extended
community)?  In some sense, that would just be saying that "the combination
of the two is out of scope for this document", which is something that we
see fairly often and does not seem problematic.

Anyway, I think we can consider this discuss point resolved.

Thanks again!

-Ben

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 3 Dec 2020 06:38:01 -0800

Yes, you’re right.

Thanks!

Alvaro.

On December 3, 2020 at 9:04:39 AM, Benjamin Kaduk ([email-masked]) wrote:

Hi Alvaro,

Thanks again!

-Ben

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 3 Dec 2020 09:59:43 -0500

Ben: 

The statement of "a review of Section 8.3.1 of RFC 8365 is called for" regarding the split horizon procedures”. 

Is providing a specific detail to the common phrase  "the combination of the two is out of scope for this document".  

Why did we do this? There are new drafts documents in the BESS pipeline that suggest putting the two together so it was a hint for these new documents where to look for issues.   

Sue 

From: Idr [mailto:[email-masked]] On Behalf Of Alvaro Retana
Sent: Thursday, December 3, 2020 9:38 AM
To: Benjamin Kaduk
Cc: [email-masked]; Benjamin Kaduk via Datatracker; The IESG; [email-masked]; [email-masked]; Susan Hares
Subject: Re: [Idr] Benjamin Kaduk's Discuss on draft-ietf-idr-tunnel-encaps-20: (with DISCUSS and COMMENT)

Yes, you’re right.

Thanks!

Alvaro.

Hi Alvaro, 

Thanks again! 

-Ben

---

From: John Scudder <[email-masked]>
Date: Fri, 4 Dec 2020 01:35:16 +0000

Hi Benjamin,

Thanks for your detailed review. Sorry my response has taken longer than the others, that’s what you get when you send such a comprehensive set of comments :-). You should have seen how long it took us to respond to Alvaro’s initial review! Anyhow, my responses are below.

> On Dec 1, 2020, at 1:18 PM, Benjamin Kaduk via Datatracker <[email-masked]> wrote:
> 
> [External Email. Be cautious of content]
> 
> 
> Please refer to https://urldefense.com/v3/__https://www.ietf.org/iesg/statement/discuss-criteria.html__;!!NEt6yMaO-gk!V6ZSnNHbpZSZrxPOIUPMT288dwgQIlfv1AnMX8u5GwjRGKj5VzXkTysVMfVqhA$
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-idr-tunnel-encaps/__;!!NEt6yMaO-gk!V6ZSnNHbpZSZrxPOIUPMT288dwgQIlfv1AnMX8u5GwjRGKj5VzXkTys5KSbgTg$
> 
> 
> 

We’ll respond to this later, I need to discuss it with my coauthors and didn’t want to hold up the rest of the response any longer than I have.

> what or how to fix it, or even who is going to do that work".

You and Sue are already discussing this one, we will await some conclusion to that discussion.

Thanks for pointing that out, we hadn’t noticed it since it came along after the other ones. The question you’re referring to is,

"In a nutshell, the document deprecates one way of defining how to tunnel specific types of traffic, and then defines a different way to accomplish this. I'm not a BGP expert, and that's part of why it's taken me so long to respond. The main question I have is, does this introduce new ways to attack BGP, ways that have not already been considered?”

Since the question is focused on the BGP protocol itself, I think the short answer is “no”. The slightly longer answer is that if we broaden the question to mean, does it introduce new attacks that could be conducted using BGP as a vector, paragraph 2 of section 15 details the one we were able to identify, and paragraph 3 talks about mitigations. 

> terminology was switched to be "tunnel egress endpoint"; was this spot

It’s about to be moot since the abstract rewrite Éric spurred eliminates this text.

> ["remote endpoint" again]

I think lower-case “remote endpoint” is OK, it’s being used descriptively and not as the proper name of a protocol element. The thing that had the WG tearing their hair out was the latter.

If you think it’s confusing, let me know, but to my eye it’s OK. This is especially true since it’s merely a summary of changes, not protocol definition.

> why it is this way.  

See my reply to Martin.

> In particular, the current requirements suggest

There’s already ample opportunity to stuff all manner of arbitrary bit strings into BGP Updates (for example, the Communities path attribute) so my first reaction to this is not to be concerned.

> Family is either IPv4 or IPv6" since the "one special case" is a few

Changed to “… if the Address Family subfield has any value other than IPv4, IPv6, or the special value 0…”

> should get called out in the security considerations.

Third paragraph of the Security Considerations section:

   In order to further mitigate the risk of diversion of traffic from
   its intended destination, Section 3.1.1 provides an optional
   procedure to check that the destination given in a Tunnel Egress
   Endpoint sub-TLV is within the AS that was the source of the route.

> configured set and that it is used regardless of Route_AS, which does

As it’s written right now, my reading is that the implementation MAY do either one of the things you say — provide a set of permitted aliases per AS, or provide a global set of trusted other ASes, or even both. The text is unspecific, and so the implementor is free to exercise creativity. I grant that creativity can be dangerous, but on the other hand I don’t want to overconstrain the implementor. 

> corresponding sections, but that is probably just a matter of style.

Added refs/links.

> §3.2.2 it seems that maybe the "of the sub-TLV" is also superfluous?).

Thanks, fixed.

> IANA entry is named "BGP EVPNs".

Changed.

> using the VXLAN tunnel, but assume that's just my ignorance.]

Mine, too. :-/ Perhaps one of my coauthors can follow up with the reason for this carveout.

> (nit) I only see one field marked "Reserved" (this format is the same

Fixed.

>      field of the NVGRE header.  The flags field of the VXLAN header is

Fixed.

> "backward compatible" option and what it's compatible with.

Now says:

   Although the MPLS-in-GRE tunnel type is just a special case of the
   GRE tunnel type and thus is not strictly necessary, it is included
   for reasons of backwards compatibility with, for example,
   implementations of [RFC8365].

> "unrecognized" seems to be the common case (and makes it easier to find

Fixed.

> the TC portion of the MPLS label stack entries.

How about this?

   Because the interpretation of the DSCP field at the recipient may be
   different from its interpretation at the originator, an
   implementation MAY provide a facility to use policy to filter or
   modify the DS Field.

> preserve things unchaged in similar situations.

I can’t think of any good reason. Changed to MUST NOT.

> implicit inclusion is actually used anywhere (and if so, give an example

I’m a little confused here. We could certainly re-word this some other way, but the “identifying” language is used in many other places. A quick search finds:

   A TLV identifying a particular Tunnel Type may contain a sub-TLV that
   is meaningless for that Tunnel Type.  For example, perhaps the TLV
...
   If the MPLS Label Stack sub-TLV is included in a TLV identifying a
   Tunnel Type that uses virtual network identifiers (see Section 9),
...
   Note that this sub-TLV can appear within a TLV identifying any type
   of tunnel, not just within a TLV identifying an MPLS tunnel.
   However, if this sub-TLV appears within a TLV identifying an MPLS
   tunnel (or an MPLS-in-X tunnel), this sub-TLV plays the same role
…
   The Prefix-SID sub-TLV can occur in a TLV identifying any type of
   tunnel.  If an Originator SRGB is specified in the sub-TLV, that SRGB
…
   If the TLV identifying the tunnel contains an Encapsulation sub-TLV
   whose V bit is set, the virtual network identifier field of the
…
   If the TLV identifying the tunnel contains an Encapsulation sub-TLV
   whose V bit is set, the virtual network identifier field of the
…
   If the TLV identifying the tunnel does not contain an Encapsulation
   sub-TLV whose V bit is set, the virtual network identifier field of

Is it the association with the word “route” that’s bugging you, or can you otherwise be more specific? If a short call would make it easier to explain, that’s fine.

> UPDATE message restriction that is lifted, and suggest clarification

Resolved by removing the paragraph entirely — in the spirit of Éric’s observation that ancient history didn’t need to be in the abstract, it doesn’t need to be here, either. It’s enough that the following (now first) paragraph of Section 6 says what AFI/SAFI the attribute MAY be carried with.

> the definite article is not justified by the preceding context.

Fixed.

> a given Tunnel TLV can have more than one Color sub-TLV present.

Now says:

   However, suppose that one of the TLVs in U2's Tunnel Encapsulation
   attribute contains one or more Color Sub-TLVs.  In that case, packet
   P MUST NOT be sent through the tunnel contained in that TLV, unless
   U1 is carrying a Color Extended Community that is identified in one
   of U2's Color Sub-TLVs.

> We start off by saying "three" types but list only two.  What's the

On the cutting room floor. Thanks, I’ve updated this to say “two”.

> first sub-TLV or all instances.

I see. To me, it’s clear that “disregarded” means “every other procedure in this specification should pretend the disregarded sub-TLV doesn’t exist”; in that context I think the language is clear as written.

If there’s a fix to be made (on which subject I’m open to further discussion) I think it’s in Section 13. I think my first offer on the fix would be to insert a definition like the one above.

> nit: I think "lower" is unneeded, since all the VNI fields are exactly 3

Fair point, but since “lower” is harmless and potentially useful if there’s a future extension with a different size VNI, I think it’s OK to let it stand.

> receiving (vs originating) the route.

Option B always makes my head hurt, but as I recall the point here is that in Option B, the VPN label gets rewritten at the AS border. Since the Tunnel Encapsulation attribute sneaks right past that rewrite step, the procedures would be messed up, and we all know what happens when you cross the beams. 

The point about the egress endpoint and the router receiving the route is a restatement of the same point. Essentially the two ASes comprise different namespaces with respect to VPN labels. In Option B, mapping between the namespaces is done at the border. So, if you remain in the same namespace, i.e. don’t cross an AS border, it’s all good and you can use the Tunnel Encapsulation attribute. But if you change namespaces, it all goes pear-shaped because you’ve bypassed the mapping.

> have to come up with their own interpretations, which could easily be

Fair point. I changed “should” to “MUST”. Clear enough?

> if the actual error handling stays here).

An earlier reviewer pointed out the perils and pitfalls of specifying things in more than one place and there was actually a pass to try to eliminate redundancy. (I’m sure we missed plenty.) 

I can see the merits of both positions, I’m willing to bend either way, but for now will leave the text as written.

> Tunnel Encapsulation Parameters" grouping?

I think that was an oversight, thanks for catching it. I added a subsection to move it.

> are available (and, I suppose, in which order the bits are numbered).

Updated.

> just referencing the previous discussion as security-relevant).

Thanks, I added a paragraph.

> message structure, that it is probably not worth mentioning.

Roger wilco. Not mentioned! :-)

> also seems to make it normative.

Both moved.

Regards,

—John

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 3 Dec 2020 21:08:07 -0800

Hi John,

Yes, the reward for doing good work is more work :)
Also inline...

> We’ll respond to this later, I need to discuss it with my coauthors and didn’t want to hold up the rest of the response any longer than I have.

Sounds good.  I am not surprised that this one is going to require more
discussion; it seems like a tricky task to figure out the right thing to
do.

> You and Sue are already discussing this one, we will await some conclusion to that discussion.

This discussion has concluded based on Alvaro's extended explanation.  (I
updated my ballot in the datatracker but it didn't seem worth sending
another mail and confusing things by having all the rest of it be the
same.)

Thanks!

> It’s about to be moot since the abstract rewrite Éric spurred eliminates this text.

Ah, yes, that was a good point Éric made, and thanks for the rewrite.

> If you think it’s confusing, let me know, but to my eye it’s OK. This is especially true since it’s merely a summary of changes, not protocol definition.

I think you're right and this should be okay.  I just wanted to check that
it was known and accepted.

> There’s already ample opportunity to stuff all manner of arbitrary bit strings into BGP Updates (for example, the Communities path attribute) so my first reaction to this is not to be concerned.

Fair enough :)

> Third paragraph of the Security Considerations section:

Oops.  This is what I get for not checking over my comments before
sending.

Thanks for the reminder.

> As it’s written right now, my reading is that the implementation MAY do either one of the things you say — provide a set of permitted aliases per AS, or provide a global set of trusted other ASes,…

Reading it again, I do think your reading makes sense.  No change here is
fine.

> Mine, too. :-/ Perhaps one of my coauthors can follow up with the reason for this carveout.

I will keep an eye out for if such a follow-up appears.

>    implementations of [RFC8365].

Thank you!

>    implementation MAY provide a facility to use policy to filter or

Works for me; thanks.

> Is it the association with the word “route” that’s bugging you, or can you otherwise be more specific? If a short call would make it easier to explain, that’s fine.

I think it's the association with the word "route", yes -- the particular
wording of the current lead-in made me expect to see complicated (and
unwieldly!) phrases involving a route, the attribute in the route, and the
TLV in the attribute.  Our actual usage seems to be closer to "when we say
that a TLV identifies a given tunnel type, this implicitly includes the
case when the tunnel encapsulation extended community is used instead of
the tunnel encapsulation attribute", with the existence of a route, and
often the tunnel encapsulation attribute as well, left implicit.

Seeing you go over things again has been enough to clarify the intent for
me, and while we could certainly try to tweak the wording of the disclaimer
to more closely resemble the actual usage in the body text, it's not clear
to me that it's worth the effort.

Thanks!

> I see. To me, it’s clear that “disregarded” means “every other procedure in this specification should pretend the disregarded sub-TLV doesn’t exist”; in that context I think the language is clear a…

Okay.  My "perhaps" was intended to allow for this meaning of disregarded,
so I think we are roughly on the same page.

> If there’s a fix to be made (on which subject I’m open to further discussion) I think it’s in Section 13. I think my first offer on the fix would be to insert a definition like the one above.

I would lean towards making the change in Section 13, but please use your
own judgment.

> The point about the egress endpoint and the router receiving the route is a restatement of the same point. Essentially the two ASes comprise different namespaces with respect to VPN labels. In Opti…

Ah, thank you very much for this explanation; it seems to cover the
important facets of the situation well.  If I understand correctly (still
far from a given), the normal operation here for live traffic being
forwarded involves changing the VPN label at the AS boundary, and the issue
is that the BGP announcement has circumvented that procedure and has the
label from the "wrong" AS (which is, thus, also wrong).  In that sense, the
issue is that the embedded label has *not* changed, or rather, that the
embedded label will be interpreted differently in the different ASes.
So I would suggest tweaking the "has been changed" wording (assuming that
my my understanding above is correct, of course).

> Fair point. I changed “should” to “MUST”. Clear enough?

Clear, yes, though we often hear that using normative language to attempt
to bind authors of future protocol documents (vs implementors) is overkill.
So maybe just "must" is enough?

> I can see the merits of both positions, I’m willing to bend either way, but for now will leave the text as written.

Okay.

> > also seems to make it normative.

Many thanks for all of this,

Ben

---

From: John Scudder <[email-masked]>
Date: Fri, 11 Dec 2020 15:43:36 +0000

Hi Ben,

In this reply I’ll just address your open Discuss:

On Dec 4, 2020, at 12:08 AM, Benjamin Kaduk <[email-masked]<mailto:[email-masked]>> wrote:

We did a review of RFC 8402’s definition of an “SR domain”. Here’s 8402, from the Terminology section, emphasis added:

   Segment Routing domain (SR domain): the set of nodes participating in
   the source-based routing model.  These nodes may be connected to the
   same physical infrastructure (e.g., a Service Provider's network).
   They may as well be remotely connected to each other (e.g., an
   enterprise VPN or an overlay).  If multiple protocol instances are
   deployed, the SR domain most commonly includes all of the protocol
   instances in a network.  However, some deployments may wish to
   subdivide the network into multiple SR domains, each of which
   includes one or more protocol instances.  It is expected that all
   nodes in an SR domain are managed by the same administrative entity.

Other parts of 8402 imply other properties of an SR domain. One is that all the participating routers share a Prefix-SID namespace (this is my interpretation, not the wording of 8402), another is the text in Section 8.1 you quote above, about filtering external traffic.

The text that bothered you in tunnel-encaps (“need not even be in the same Segment Routing Domain”) was directed only toward the namespace aspect: the two ends of the tunnel may be using different prefix-SID namespaces. But as we see above, the namespace isn’t a defining attribute of the SR domain. So, I think the best way forward is to strike the offending text from tunnel-encaps. The paragraph stands just as well (arguably better) without it:

   The Prefix-SID sub-TLV has slightly different semantics than the
   Prefix-SID attribute.  When the Prefix-SID attribute is attached to a
   given route, the BGP speaker that originally attached the attribute
   is expected to be in the same Segment Routing domain as the BGP
   speakers who receive the route with the attached attribute.  The
   Label-Index tells the receiving BGP speakers what the prefix-SID is
   for the advertised prefix in that Segment Routing domain.  When the

   Prefix-SID sub-TLV is used, the receiving BGP speaker need not even

   be in the same Segment Routing Domain as the tunnel's egress
   endpoint, and there is no implication that the prefix-SID for the
   advertised prefix is the same in the Segment Routing domains of the
   BGP speaker that originated the sub-TLV and the BGP speaker that
   received it.

We’d also add something like the following to the Security Considerations section:

   RFC 8402 specifies that "SR domain boundary routers MUST filter any
   external traffic" ([RFC 8402] Section 8.1). For these purposes,
   traffic introduced into a SR domain using the Prefix-SID sub-TLV lies
   within the SR domain, even though the prefix-SIDs used by the routers
   at the two ends of the tunnel may be different, as discussed in
   Section 3.7. This implies that the duty to filter external traffic
   extends to all routers participating in such tunnels.

What do you think?

Thanks,

—John

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 17 Dec 2020 16:45:23 -0500

Ben:

Hi!

Any thoughts on this?

Thanks!

Alvaro.

On December 11, 2020 at 10:43:40 AM, John Scudder ([email-masked]) wrote:

Hi Ben,

On Dec 4, 2020, at 12:08 AM, Benjamin Kaduk <[email-masked]> wrote:

We’ll respond to this later, I need to discuss it with my coauthors and
didn’t want to hold up the rest of the response any longer than I have.

We did a review of RFC 8402’s definition of an “SR domain”. Here’s 8402,
from the Terminology section, emphasis added:

   *They may as well be remotely connected to each other (e.g., an*
   *enterprise VPN or an overlay).*  If multiple protocol instances are

Other parts of 8402 imply other properties of an SR domain. One is that all
the participating routers share a Prefix-SID namespace (this is my
interpretation, not the wording of 8402), another is the text in Section
8.1 you quote above, about filtering external traffic.

The text that bothered you in tunnel-encaps (“need not even be in the same
Segment Routing Domain”) was directed only toward the namespace aspect: the
two ends of the tunnel may be using different prefix-SID namespaces. But as
we see above, the namespace isn’t a defining attribute of the SR domain.
So, I think the best way forward is to strike the offending text from
tunnel-encaps. The paragraph stands just as well (arguably better) without
it:

We’d also add something like the following to the Security Considerations
section:

What do you think?

Thanks,

—John