idnits 2.17.00 (12 Aug 2021) /tmp/idnits22636/draft-ietf-grow-bgp-reject-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 24, 2017) is 1816 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Global Routing Operations J. Mauch 3 Internet-Draft Akamai 4 Updates: 4271 (if approved) J. Snijders 5 Intended status: Standards Track NTT 6 Expires: November 25, 2017 G. Hankins 7 Nokia 8 May 24, 2017 10 Default EBGP Route Propagation Behavior Without Policies 11 draft-ietf-grow-bgp-reject-08 13 Abstract 15 This document updates RFC4271 by defining the default behavior of a 16 BGP speaker when there is no Import or Export Policy associated with 17 an External BGP session. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in RFC 2119 [RFC2119]. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on November 25, 2017. 42 Copyright Notice 44 Copyright (c) 2017 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Changes to RFC4271 . . . . . . . . . . . . . . . . . . . . . 3 62 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 65 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 4 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 68 8.2. Informative References . . . . . . . . . . . . . . . . . 5 69 Appendix A. Transition Considerations for BGP Implementers . . . 5 70 A.1. "N+1 N+2" Release Strategy . . . . . . . . . . . . . . . 5 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 73 1. Introduction 75 BGP routing security issues need to be addressed in order to make the 76 Internet more stable. Route leaks [RFC7908] are part of the problem, 77 but software defects or operator misconfiguration can contribute too. 78 This document updates [RFC4271] so that routes are neither imported 79 nor exported unless specifically enabled by configuration. This 80 change reduces the consequences of these problems, and improves the 81 default level of Internet routing security. 83 Many deployed BGP speakers send and accept any and all route 84 announcements between their BGP neighbors by default. This practice 85 dates back to the early days of the Internet, where operators were 86 permissive in sending routing information to allow all networks to 87 reach each other. As the Internet has become more densely 88 interconnected, the risk of a misbehaving BGP speaker poses 89 significant risks to Internet routing. 91 This specification intends to improve this situation by requiring the 92 explicit configuration of both BGP Import and Export Policies for any 93 External BGP (EBGP) session such as customers, peers, or 94 confederation boundaries for all enabled address families. Through 95 codification of the aforementioned requirement, operators will 96 benefit from consistent behaviour across different BGP 97 implementations. 99 BGP speakers following this specification do not use or send routes 100 on EBGP sessions, unless specifically configured to do so. 102 2. Terminology 104 [RFC4271] describes a Policy Information Base (PIB) which contains 105 local policies that can be applied to the information in the Routing 106 Information Base (RIB). This document distinguishes the type of a 107 policy based on its application. 109 Import Policy: a local policy to be applied to the information 110 contained in the Adj-RIBs-In. As described in Section 3.2 [RFC4271], 111 the Adj-RIBs-In contain information learned from other BGP speakers, 112 and the application of the Import Policy results in the routes that 113 will be considered in the Decision Process by the local BGP speaker. 115 Export Policy: a local policy to be applied in selecting the 116 information contained in the Adj-RIBs-Out. As described in 117 Section 3.2 [RFC4271], the Adj-RIBs-Out contain information that has 118 been selected for advertisement to other BGP speakers. 120 3. Changes to RFC4271 122 This section updates [RFC4271] to specify the default behavior of a 123 BGP speaker when there are no Import or Export Policies associated 124 with a particular EBGP session. A BGP speaker MAY provide a 125 configuration option to deviate from the following updated behaviors. 127 The following paragraph is added to Section 9.1 (Decision Process) 128 after the fifth paragraph, which ends in "route aggregation and route 129 information reduction": 131 Routes contained in an Adj-RIB-In associated with an EBGP peer 132 SHALL NOT be considered eligible in the Decision Process if no 133 explicit Import Policy has been applied. 135 The following paragraph is added to Section 9.1.3 (Phase 3: Route 136 Dissemination) after the third paragraph, which ends in "by means of 137 an UPDATE message (see 9.2).": 139 Routes SHALL NOT be added to an Adj-RIB-Out associated with an 140 EBGP peer if no explicit Export Policy has been applied. 142 4. Acknowledgments 144 The authors would like to thank the following people for their 145 comments, support and review: Shane Amante, Christopher Morrow, 146 Robert Raszuk, Greg Skinner, Adam Chappell, Sriram Kotikalapudi, 147 Brian Dickson, Jeffrey Haas, John Heasley, Ignas Bagdonas, Donald 148 Smith, Dale Worley, Alvaro Retana, John Scudder, and Dale Worley. 150 5. Security Considerations 152 Permissive default routing policies can result in inadvertent effects 153 such as route leaks [RFC7908], in general resulting in routing of 154 traffic through an unexpected path. While it is possible for an 155 operator to use monitoring to detect unexpected flows, there is no 156 general framework that can be applied. These policies also have the 157 potential to expose software defects or misconfiguration that could 158 have unforeseen technical and business impacting effects. 160 The update to [RFC4271] specified in this document is intended to 161 eliminate those inadvertent effects. Operators must explicitly 162 configure Import and Export Policies to achieve their expected goals. 163 There is of course no protection against a malicious or incorrect 164 explicit configuration. 166 The security considerations described in [RFC4271] and the 167 vulnerability analysis discussed in [RFC4272] also apply to this 168 document. 170 6. IANA Considerations 172 This document has no actions for IANA. 174 7. Contributors 176 The following people contributed to successful deployment of solution 177 described in this document: 179 Jakob Heitz 180 Cisco 182 Email: jheitz@cisco.com 184 Ondrej Filip 185 CZ.NIC 187 Email: ondrej.filip@nic.cz 189 8. References 191 8.1. Normative References 193 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 194 Requirement Levels", BCP 14, RFC 2119, 195 DOI 10.17487/RFC2119, March 1997, 196 . 198 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 199 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 200 DOI 10.17487/RFC4271, January 2006, 201 . 203 8.2. Informative References 205 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 206 RFC 4272, DOI 10.17487/RFC4272, January 2006, 207 . 209 [RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., 210 and B. Dickson, "Problem Definition and Classification of 211 BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June 212 2016, . 214 Appendix A. Transition Considerations for BGP Implementers 216 This appendix is non-normative. 218 For an implementer, transitioning to a compliant BGP implementation 219 may require a process that can take several years. 221 It is understood and acknowledged that operators who are taking 222 advantage of an undefined behavior will always be surprised by 223 changes to said behavior. 225 A.1. "N+1 N+2" Release Strategy 227 An implementer could leverage an approach described as the "N+1 and 228 N+2" release strategy. In release N+1, the implementer introduces a 229 new default configuration parameter to indicate that the BGP speaker 230 is operating in "ebgp insecure-mode". In addition to the 231 introduction of the new parameter, an implementer could begin to 232 display informational warnings to the operator that certain parts of 233 the configuration are incomplete. In release N+1, operators of the 234 BGP implementation become aware that a configurable default exists in 235 the implementation, and can prepare accordingly. In release N+2 or 236 later, the inverse of the previous default configuration parameter 237 that was introduced in release N+1 becomes the new default. 239 As a result, any new installation of release N+2 will adhere to this 240 document. Installations upgraded from version release N+1 will 241 adhere to the previous insecure behavior, if no modification was made 242 to the "ebgp insecure-mode" configuration parameter. 244 Authors' Addresses 246 Jared Mauch 247 Akamai Technologies 248 8285 Reese Lane 249 Ann Arbor Michigan 48103 250 US 252 Email: jared@akamai.com 254 Job Snijders 255 NTT Communications 256 Theodorus Majofskistraat 100 257 Amsterdam 1065 SZ 258 NL 260 Email: job@ntt.net 262 Greg Hankins 263 Nokia 264 777 E. Middlefield Road 265 Mountain View, CA 94043 266 USA 268 Email: greg.hankins@nokia.com