RFC 8212

RFC 8212: Default External BGP (EBGP) Route Propagation Behavior without Policies 🎀

Okay so the title block is giving a whole lineup 💅 This is an Internet Engineering Task Force (IETF) Request for Comments, and it's a Standards Track doc 👑, which means it's official. It was written by Jared Mauch (Akamai), Job Snijders (NTT), and Greg Hankins (Nokia), and it was published in July 2017 🌸 with ISSN 2070-1721. It updates RFC 4271 ✨, which is the BGP-4 spec, so this one changes how BGP behaves by default. Its title block doesn't list any RFCs it obsoletes.

Abstract ✨

This doc updates [RFC4271] to define what a BGP speaker does by default when there's no Import or Export Policy attached to an External BGP session. 🦋

Status of This Memo 📝

This is an Internet Standards Track document. 👑

It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 7841. 🫶

For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc8212. 🌈

Copyright Notice ©️

Copyright (c) 2017 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 (http://trustee.ietf.org/license-info), as they were in effect on the date this document was published. Please read these carefully, because they spell out your rights and restrictions for this doc. Code Components pulled from this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License. 🙈

Table of Contents 🧚

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   3.  Changes to RFC 4271 . . . . . . . . . . . . . . . . . . . . .   3
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Appendix A.  Transition Considerations for BGP Implementers . . .   6
     A.1.  "N+1 N+2" Release Strategy  . . . . . . . . . . . . . . .   6
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   6
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1. Introduction 💖

BGP routing security has to be fixed to make the Internet more stable. Route leaks [RFC7908] are part of the problem, but software defects or operator misconfiguration can also cause trouble. This doc updates [RFC4271] so that routes are neither imported nor exported unless configuration specifically turns that on. This shrinks the damage these problems can cause and makes the default level of Internet routing security better. 🔥

Lowkey, a lot of deployed BGP speakers send and accept any and all route announcements between their BGP neighbors by default. 💀 This goes back to the early days of the Internet, when operators were super permissive about sending routing info so all networks could reach each other. As the Internet got more densely interconnected, a misbehaving BGP speaker started posing serious risks to Internet routing. 😭

This spec is trying to fix that by requiring explicit configuration of both BGP Import and Export Policies for any External BGP (EBGP) session, like customers, peers, or confederation boundaries, for all enabled address families. Once this requirement is codified, operators get consistent behavior across different BGP implementations. It's giving main character energy ✨

BGP speakers following this spec don't use or send routes on EBGP sessions unless they're specifically configured to. 🦋

2. Terminology 🌸

[RFC4271] describes a Policy Information Base (PIB) that holds local policies which can be applied to the information in the Routing Information Base (RIB). This doc sorts policies by how they're applied. 🧚

Import Policy: a local policy applied to the information in the Adj-RIBs-In. As Section 3.2 [RFC4271] explains, the Adj-RIBs-In hold information learned from other BGP speakers, and applying the Import Policy gives you the routes the local BGP speaker will consider in the Decision Process. 📥

Export Policy: a local policy applied when selecting the information in the Adj-RIBs-Out. As Section 3.2 [RFC4271] explains, the Adj-RIBs-Out hold information that's been selected for advertisement to other BGP speakers. 📤

2.1. Requirements Language 🎀

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 💅

3. Changes to RFC 4271 🍓

This section updates [RFC4271] to define the default behavior of a BGP speaker when there are no Import or Export Policies attached to a particular EBGP session. A BGP speaker MAY offer a configuration option to deviate from the updated behaviors below. 🔥

Here's the paragraph being added to Section 9.1 (Decision Process), after the fifth paragraph (the one ending in "route aggregation and route information reduction"):

   Routes contained in an Adj-RIB-In associated with an EBGP peer
   SHALL NOT be considered eligible in the Decision Process if no
   explicit Import Policy has been applied.

And here's the paragraph being added to Section 9.1.3 (Phase 3: Route Dissemination), after the third paragraph (the one ending in "by means of an UPDATE message (see 9.2)."):

   Routes SHALL NOT be added to an Adj-RIB-Out associated with an
   EBGP peer if no explicit Export Policy has been applied.

4. Security Considerations 🔐

Permissive default routing policies can cause inadvertent effects like route leaks [RFC7908], which usually send traffic down an unexpected path. 😬 An operator can use monitoring to spot unexpected flows, but there's no general framework for that. These policies can also expose software defects or misconfiguration, and those can have unforeseen technical and business impacts. 💀

The update to [RFC4271] in this document is meant to eliminate those inadvertent effects. Operators must explicitly configure Import and Export Policies to hit their goals. Of course, there's no protection against a malicious or incorrect explicit configuration. 🙈

The security considerations in [RFC4271] and the vulnerability analysis in [RFC4272] also apply to this document. 🫶

5. IANA Considerations 🌈

This document does not require any IANA actions. ✨

6. References 📚

6.1. Normative References 💜

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <http://www.rfc-editor.org/info/rfc2119>.

[RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
           Border Gateway Protocol 4 (BGP-4)", RFC 4271,
           DOI 10.17487/RFC4271, January 2006,
           <http://www.rfc-editor.org/info/rfc4271>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <http://www.rfc-editor.org/info/rfc8174>.

6.2. Informative References 🦋

[RFC4272]  Murphy, S., "BGP Security Vulnerabilities Analysis",
           RFC 4272, DOI 10.17487/RFC4272, January 2006,
           <http://www.rfc-editor.org/info/rfc4272>.

[RFC7908]  Sriram, K., Montgomery, D., McPherson, D., Osterweil, E.,
           and B. Dickson, "Problem Definition and Classification of
           BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June
           2016, <http://www.rfc-editor.org/info/rfc7908>.

Appendix A. Transition Considerations for BGP Implementers 🧚

This appendix is not normative. 🙈

For an implementer, moving to a compliant BGP implementation may take a process that can run several years. ⏳

It's understood and acknowledged that operators who are taking advantage of an undefined behavior will always be surprised when that behavior changes. 💀

A.1. "N+1 N+2" Release Strategy 🚀

An implementer could use what's called the "N+1 and N+2" release strategy. In release N+1, the implementer adds a new default configuration parameter that indicates the BGP speaker is running in "ebgp insecure-mode". The implementer could also start showing informational warnings to the operator that parts of the configuration are incomplete. This way, in release N+1, operators learn that a configurable default exists and can prepare for it. 🎀 In release N+2 or later, the inverse of the default parameter introduced in release N+1 becomes the new default. 🌸

So any new install of release N+2 will follow this document. Installs upgraded from release N+1 keep the old insecure behavior, unless someone changed the "ebgp insecure-mode" configuration parameter. 💅

Acknowledgments 🫶

The authors would like to thank the following people for their comments, support, and review: Shane Amante, Christopher Morrow, Robert Raszuk, Greg Skinner, Adam Chappell, Sriram Kotikalapudi, Brian Dickson, Jeffrey Haas, John Heasley, Ignas Bagdonas, Donald Smith, Alvaro Retana, John Scudder, and Dale Worley. 🌟

Contributors 🌷

The following people helped make the solution in this document successfully deployed: 🍓

Jakob Heitz
Cisco

Email: jheitz@cisco.com


Ondrej Filip
CZ.NIC

Email: ondrej.filip@nic.cz

Authors' Addresses 🗺️

Jared Mauch
Akamai Technologies
8285 Reese Lane
Ann Arbor  Michigan 48103
United States of America

Email: jared@akamai.com


Job Snijders
NTT Communications
Theodorus Majofskistraat 100
Amsterdam  1065 SZ
The Netherlands

Email: job@ntt.net


Greg Hankins
Nokia
777 E. Middlefield Road
Mountain View, CA  94043
United States of America

Email: greg.hankins@nokia.com

That's the whole RFC, bestie! 🌈💖 The big takeaway: BGP speakers stop using or sending EBGP routes unless you explicitly configure policies. No cap, that's iconic. 👑