Subject: [Idr] I-D Action: draft-ietf-idr-tunnel-encaps-16.txt

From: [email-masked]
Date: Mon, 13 Jul 2020 12:50:45 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing WG of the IETF.

        Title           : The BGP Tunnel Encapsulation Attribute
        Authors         : Keyur Patel
                          Gunter Van de Velde
                          Srihari R. Sangli
                          John Scudder
	Filename        : draft-ietf-idr-tunnel-encaps-16.txt
	Pages           : 43
	Date            : 2020-07-13

Abstract:
   RFC 5512 defines a BGP Path Attribute known as the "Tunnel
   Encapsulation Attribute".  This attribute allows one to specify a set
   of tunnels.  For each such tunnel, the attribute can provide the
   information needed to create the tunnel and the corresponding
   encapsulation header.  The attribute can also provide information
   that aids in choosing whether a particular packet is to be sent
   through a particular tunnel.  RFC 5512 states that the attribute is
   only carried in BGP UPDATEs that use the "Encapsulation Subsequent
   Address Family (Encapsulation SAFI)".  This document deprecates the
   Encapsulation SAFI (which has never been used in production), and
   specifies semantics for the attribute when it is carried in UPDATEs
   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
   specifying fields of any inner or outer encapsulations that may be
   used by a particular tunnel.

   This document obsoletes RFC 5512.  Since RFCs 5566 and 5640 rely on
   RFC 5512, they are likewise obsoleted.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-tunnel-encaps/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-idr-tunnel-encaps-16
https://datatracker.ietf.org/doc/html/draft-ietf-idr-tunnel-encaps-16

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-tunnel-encaps-16

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: John Scudder <[email-masked]>
Date: Mon, 13 Jul 2020 19:59:40 +0000

Hi All,

This version addresses Alvaro’s review. Alvaro, we think we’ve addressed all your points, or responded to you to say why we aren’t.

It’s a big enough diff that I’m not going to try to summarize; it’s probably best for people to review the rfcdiff for themselves. I do want to address the biggest change, though, which is that the security architecture got pretty seriously worked over.

You’ll see that the first field of the Tunnel Egress Endpoint Sub-TLV went from being an AS number in -15, to a reserved field in -16. This is because as we worked to write text explaining exactly how to use that number, and exactly how it would benefit the security of the solution, we realized that… it didn’t. Instead, we added section 3.1.1. The gist of that section is, the tunnel endpoint of route R should be resolved by a route that has the same origin AS as R itself does. Of course origin AS is, itself, spoofable, but if you want to fix that, there are various solutions on the table, including but not limited to BGPsec (this is discussed in the Security Considerations section).

I believe, but do not promise, that this is the only normative change. Other than that, well, take a look at the diff. The only other thing I was tempted to do in the revision was to take a chainsaw to all the places the draft talks about “BGP UPDATEs” and change them to refer to “routes” instead, in the formal sense defined by RFC 4271:

   Route
      A unit of information that pairs a set of destinations with the
      attributes of a path to those destinations.  The set of
      destinations are systems whose IP addresses are contained in one
      IP address prefix carried in the Network Layer Reachability
      Information (NLRI) field of an UPDATE message.  The path is the
      information reported in the path attributes field of the same
      UPDATE message.

However, there are something like 61 occurrences of “BGP UPDATE” in the document. I’m willing to do the work if there’s demand from the WG but otherwise I’ll let sleeping dogs lie, even if it does make my eyes hurt.

Thanks,

—John

> On Jul 13, 2020, at 3:50 PM, [email-masked] wrote:
> 
> 
...