RFC 5566

BGP IPsec Tunnel Encapsulation Attribute

📅 published June 2009, from ietf

RFC 5566: BGP IPsec Tunnel Encapsulation Attribute 💖

Network Working Group, Request for Comments: 5566, June 2009. This one is on the Standards Track. The authors are L. Berger (LabN), R. White, and E. Rosen (Cisco Systems). The title block doesn't list anything it obsoletes or updates. 🦋

Status of This Memo ✨

Okay so this doc is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶. If you want to know where this protocol stands in standardization, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited, so share it with everyone 💅.

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication. The link is http://trustee.ietf.org/license-info. Please read these carefully, bestie, because they spell out your rights and restrictions for this document 🙈.

Abstract 🌸

So the BGP Encapsulation Subsequent Address Family Identifier (SAFI) is the thing that lets BGP speakers dynamically swap encapsulation info and say which encapsulation protocol to use for each next hop 🧚. Right now GRE, L2TPv3, and IP in IP tunnel types are already defined. This document adds support for IPsec tunnel types, and it's giving main character energy 👑.

Table of Contents 🍓

   1. Introduction ....................................................2
      1.1. Conventions Used in This Document ..........................2
   2. Tunnel Encapsulation Types ......................................3
   3. Use of IPsec Tunnel Types .......................................3
   4. IPsec Tunnel Authenticator sub-TLV ..............................4
      4.1. Use of the IPsec Tunnel Authenticator sub-TLV ..............5
   5. Security Considerations .........................................5
   6. IANA Considerations .............................................6
   7. References ......................................................7
      7.1. Normative References .......................................7
      7.2. Informative References .....................................7
   8. Acknowledgments .................................................8

1. Introduction ✨

Okay so the BGP [RFC4271] Encapsulation Subsequent Address Family Identifier (SAFI) lets you communicate tunnel info and link that info to a BGP next hop 🦋. You can use the Encapsulation SAFI to map prefixes to next hops and tunnels within the same address family, IPv6 prefixes to IPv4 next hops and tunnels using [RFC4798], and IPv4 prefixes to IPv6 next hops and tunnels using [RFC5549]. It also works for mapping VPN prefixes to tunnels when those VPN prefixes get advertised per [RFC4364] or [RFC4659]. For extra context on how the Encapsulation SAFI gets used, [RFC5565] has you covered 💜.

The Encapsulation SAFI itself is defined in [RFC5512]. That same doc also covers the GRE [RFC2784], L2TPv3 [RFC3931], and IP in IP [RFC2003] tunnel types. This document builds on [RFC5512] and adds IPsec tunnels 🔥. There's support for IP Authentication Header (AH) in tunnel mode [RFC4302] and for IP Encapsulating Security Payload (ESP) in tunnel mode [RFC4303]. The IPsec architecture is defined in [RFC4301]. This doc also defines support for IP in IP [RFC2003] and MPLS-in-IP [RFC4023] protected by IPsec Transport Mode 🌈.

The Encapsulation Network Layer Reachability Information (NLRI) Format is not modified by this document. No changes to the NLRI, iykyk 🙈.

1.1. Conventions Used in This Document 📝

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🎀.

2. Tunnel Encapsulation Types 💅

Per [RFC5512], the tunnel type gets indicated in the Tunnel Encapsulation attribute. This document defines the following tunnel type values:

  - Transmit tunnel endpoint: Tunnel Type = 3

  - IPsec in Tunnel-mode: Tunnel Type = 4 [RFC4302], [RFC4303]

  - IP in IP Tunnel with IPsec Transport Mode: Tunnel Type = 5
    [RFC2003], [RFC4303]

  - MPLS-in-IP Tunnel with IPsec Transport Mode: Tunnel Type = 6
    [RFC4023]

Note, see Section 4.3 of [RFC5512] for a discussion on the advertisement and use of multiple tunnel types 🧠.

Note, the specification in [RFC4023] for MPLS-in-IP tunnels with IPsec Transport mode applies as well to IP in IP tunnels ⭐.

This document does not specify the use of the sub-TLV types defined in [RFC5512] with these tunnel types. Below you'll find the definition of a specific sub-TLV for use with the defined tunnel types 🫶.

3. Use of IPsec Tunnel Types 🔐

The IPsec tunnel types are defined above with the values 4, 5, and 6 💜. Here's the deal. Say R1 is a BGP speaker and it gets an Encapsulation SAFI update from another BGP speaker, R2. If R1 has any data packets whose BGP next hop is R2, then R1 MUST initiate an IPsec SA (security association) of the specified "tunnel type", and all of those data packets MUST be sent through that SA 🚀.

Now picture R1 and R2 as two BGP speakers that might send data packets through R3, so the packets from R1 and R2 can both land on R3 over the same interface 👀. In that case, when R3 sends an Encapsulation SAFI indicating an IPsec tunnel type to R2, R3 SHOULD also send an update to R1 specifying an Encapsulation SAFI with an IPsec tunnel type. Basically, on a given interface, if IPsec is required for any data packets, it SHOULD be required for all of them 🍓. This means you don't depend on the IPsec selector mechanisms to tell apart traffic that needs protecting from traffic that doesn't, which is so much less stress 😭.

Security policy works at the granularity of BGP speaker to BGP speaker 🛡️. The required security policies must be configured into the BGP speakers. Policies for each SA will typically be set up using IKEv2 (Internet Key Exchange) [RFC4306], with either public-key or pre-shared key authentication. The SA MAY also be configured via manual techniques. The manual configuration specification and considerations are defined in [RFC4301], [RFC4302], and [RFC4303], and they cover keys, Security Parameter Index (SPI) numbers, the IPsec protocol, integrity/encryption algorithms, and sequence number mode 🧚.

4. IPsec Tunnel Authenticator sub-TLV 🔑

This document defines a new sub-TLV for use with the Tunnel Encapsulation attribute defined in [RFC5512] ✨. The new sub-TLV is called the "IPsec Tunnel Authenticator sub-TLV". One or more of these sub-TLVs MAY be included in any Encapsulation SAFI NLRI [RFC5512] that indicates a tunnel type defined in this document 🎀. Support for the IPsec Tunnel Authenticator sub-TLV MUST be implemented whenever the tunnel types defined in this document are implemented. However, using it is OPTIONAL, and that's a matter of policy 🫶.

The sub-TLV type of the IPsec Tunnel Authenticator sub-TLV is 3. The sub-TLV length is variable. The structure of the sub-TLV is as follows 🧩:

  • Authenticator Type: two octets

This document defines authenticator type 1, "SHA-1 hash of public key", as defined in Section 3.7 of RFC 4306 🌸.

  • Value: (variable)

A value used to authenticate the BGP speaker that generated this NLRI. The length of this field is not encoded explicitly, but it can be calculated as (sub-TLV length - 2) 🧮.

For authenticator type 1, this field contains the 20-octet value of the hash 💜.

A BGP speaker that sends the IPsec Tunnel Authenticator sub-TLV with authenticator type 1 MUST be configured with a private key / public key pair. The public key is the key whose hash gets sent in the value field of the sub-TLV 🔐. The BGP speaker MUST either (a) be able to generate a self-signed certificate for the public key, or else (b) be configured with a certificate for the public key 📜.

When the IPsec Tunnel Authenticator sub-TLV is used, it is highly RECOMMENDED that the integrity of the BGP session itself be protected 🛡️. This is usually done by using the TCP MD5 option [RFC2385] 💅.

4.1. Use of the IPsec Tunnel Authenticator sub-TLV 🧠

If an IPsec Tunnel Authenticator sub-TLV with authenticator type 1 is present in the Encapsulation SAFI update, then R1 (as defined above in Section 3) MUST use IKEv2 [RFC4306] to obtain a certificate from R2 (as defined above in Section 3). R2 MUST send a certificate for the public key whose hash occurred in the value field of the IPsec Tunnel Authenticator sub-TLV. R1 MUST NOT attempt to establish an SA to R2 UNLESS the public key in the certificate hashes to the same value that occurs in one of the IPsec Tunnel Authenticator sub-TLVs 🚫.

R2 MUST also perform the reciprocal processing 🔁. Specifically, when R2 is establishing an SA from R1 and R1 has advertised the IPsec Tunnel Authenticator sub-TLV with authenticator type 1, R2 MUST use IKEv2 [RFC4306] to obtain a certificate from R1. R1 MUST send a certificate for the public key whose hash occurred in the value field of the IPsec Tunnel Authenticator sub-TLV. R2 MUST NOT attempt to establish an SA to R1 UNLESS the public key in the certificate hashes to the same value that occurs in one of the IPsec Tunnel Authenticator sub-TLVs 🦋.

Note that the "Transmit tunnel endpoint" tunnel type (value = 3) may be used by a BGP speaker that does not want to be the receiving endpoint of an IPsec tunnel but only the transmitting endpoint 🌈.

5. Security Considerations 🔐✨

Okay bestie, security is the main character of this whole section 😭🫶 This document uses IP-based tunnel technologies for data plane transport, so the security considerations of those tunnel technologies apply too. It defines support for IPsec AH [RFC4302] and ESP [RFC4303], and the security considerations from those documents, plus [RFC4301], apply to the data plane aspects of this document 🛡️

As with [RFC5512], changing the information used to form encapsulation headers, to choose a tunnel type, or to choose a particular tunnel for a particular payload type can cause user data packets to get misrouted, misdelivered, and/or dropped 💀 Misdelivery is less of a problem when IPsec is in use, because it's likely to end in an authentication or decryption failure at the receiver 🙈 Also, in environments where authentication of BGP speakers is wanted, the IPsec Tunnel Authenticator sub-TLV defined in Section 4 may be used 🎀

The security considerations for carrying IP reachability information using BGP are discussed in [RFC4271] and [RFC4272], and they apply just as much to the extensions in this document 💅

If the integrity of the BGP session isn't protected by itself, then an imposter could mount a denial-of-service attack by setting up loads of BGP sessions and forcing an IPsec SA to be created for each one 😳 That said, an imposter like that could wreak havoc on the entire routing system, so this particular sort of attack is probably not of any special importance 🙄

It's worth noting that a BGP session may itself be carried over an IPsec tunnel. Those IPsec tunnels can give a BGP session extra security 🔥 Managing those IPsec tunnels is outside the scope of this document 🧚

6. IANA Considerations 🗂️🌸

IANA administers the assignment of new namespaces, and new values for the namespaces defined and reviewed in this section, so this is their area 💖

IANA has made the following assignments in the "BGP Tunnel Encapsulation Attribute Tunnel Types" registry:

Value  Name                                        Reference
-----  ----                                        ---------
  3    Transmit tunnel endpoint                    [RFC5566]

  4    IPsec in Tunnel-mode                        [RFC5566]

  5    IP in IP tunnel
          with IPsec Transport Mode                [RFC5566]

  6    MPLS-in-IP tunnel
          with IPsec Transport Mode                [RFC5566]

IANA has also made the following assignment in the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry:

Value  Name                                        Reference
-----  ----                                        ---------
  3    IPsec Tunnel Authenticator                  [RFC5566]

7. References 📚

7.1. Normative References

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
  • [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
  • [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
  • [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
  • [RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
  • [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute", RFC 5512, April 2009.

7.2. Informative References

  • [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
  • [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
  • [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
  • [RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed., "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
  • [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, March 2005.
  • [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, January 2006.
  • [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
  • [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, "BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN", RFC 4659, September 2006.
  • [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)", RFC 4798, February 2007.
  • [RFC5549] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop", RFC 5549, May 2009.
  • [RFC5565] Wu, J., Cui, Y., Metz, C. and E. Rosen, "Softwire Mesh Framework", RFC 5565, June 2009.

8. Acknowledgments 🫶

The authors want to thank Sam Hartman and Tero Kivinen for their help with the security-related issues 💜

Authors' Addresses 🦋

Lou Berger LabN Consulting, L.L.C. Phone: +1-301-468-9228 EMail: lberger@labn.net

Russ White Cisco Systems EMail: riw@cisco.com

Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA, 01719 EMail: erosen@cisco.com

And that's the whole spec, bestie! 🌈👑 You made it through 💅✨

📦 where this page comes from