idnits 2.17.1 draft-ietf-grow-bgp-reject-07.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 (Using the creation date from RFC4271, updated by this document, for RFC5378 checks: 2006-01-13) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 8, 2017) is 2546 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 (==), 2 comments (--). 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 9, 2017 G. Hankins 7 Nokia 8 May 8, 2017 10 Default EBGP Route Propagation Behavior Without Policies 11 draft-ietf-grow-bgp-reject-07 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 9, 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 . . . . . . . . . . . . . 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] in order to improve the default level 79 of Internet routing security. 81 Many deployed BGP speakers send and accept any and all route 82 announcements between their BGP neighbors by default. This practice 83 dates back to the early days of the Internet, where operators were 84 permissive in sending routing information to allow all networks to 85 reach each other. As the Internet has become more densely 86 interconnected, the risk of a misbehaving BGP speaker poses 87 significant risks to Internet routing. 89 This specification intends to improve this situation by requiring the 90 explicit configuration of both BGP Import and Export Policies for any 91 External BGP (EBGP) session such as customers, peers, or 92 confederation boundaries for all enabled address families. Through 93 codification of the aforementioned requirement, operators will 94 benefit from consistent behaviour across different BGP 95 implementations. 97 BGP speakers following this specification do not use or send routes 98 on EBGP sessions, unless configured to do otherwise. 100 2. Terminology 102 [RFC4271] describes a Policy Information Base (PIB) which contains 103 local policies that can be applied to the information in the Routing 104 Information Base (RIB). This document distinguishes the type of 105 policy based on its application. 107 Import Policy: a local policy to be applied to the information 108 contained in the Adj-RIBs-In. As described in Section 3.2 [RFC4271], 109 the Adj-RIBs-In contain information learned from other BGP speakers, 110 and the application of the Import Policy results in the routes that 111 will be considered in the Decision Process by the local BGP speaker. 113 Export Policy: a local policy to be applied in selecting the 114 information contained in the Adj-RIBs-Out. As described in 115 Section 3.2 [RFC4271], the Adj-RIBs-Out contain information that has 116 been selected for advertisement to other BGP speakers. 118 3. Changes to RFC4271 120 This section describes the Updates to [RFC4271] that define the 121 default behavior of a BGP speaker when there are no Import or Export 122 Policies associated with a particular EBGP session. A BGP speaker 123 MAY provide a configuration option to deviate from the following 124 updated behaviors. 126 The following paragraph is added to Section 9.1 (Decision Process) 127 after the fifth paragraph ending in "route aggregation and route 128 information reduction": 130 Routes contained in an Adj-RIB-In associated with an EBGP peer 131 SHALL NOT be considered eligible in the Decision Process if no 132 explicit Import Policy has been applied. 134 The following paragraph is added to Section 9.1.3 (Phase 3: Route 135 Dissemination) after the third paragraph ending in "by means of an 136 UPDATE message (see 9.2).": 138 Routes SHALL NOT be added to an Adj-RIB-Out associated with an 139 EBGP peer if no explicit Export Policy has been applied. 141 4. Acknowledgments 143 The authors would like to thank the following people for their 144 comments, support and review: Shane Amante, Christopher Morrow, 145 Robert Raszuk, Greg Skinner, Adam Chappell, Sriram Kotikalapudi, 146 Brian Dickson, Jeffrey Haas, John Heasley, Ignas Bagdonas, Donald 147 Smith, Dale Worley, Alvaro Retana, and John Scudder. 149 5. Security Considerations 151 Permissive default routing policies can result in inadvertent effects 152 such as route leaks [RFC7908], in general resulting in rerouting of 153 traffic through an unexpected path. While it is possible for an 154 operator to use monitoring to detect unexpected flows, there is no 155 general framework that can be applied. These policies also have the 156 potential to expose software defects or misconfiguration that could 157 have unforeseen technical and business impacting effects. 159 The update to [RFC4271] specified in this document is intended to 160 eliminate those inadvertent effects. Operators must explicitly 161 configure Import and Export Policies to achieve their expected goals. 162 There is of course no protection against a malicious or incorrect 163 explicit configuration. 165 The security considerations described in [RFC4271] and the 166 vulnerability analysis discussed in [RFC4272] also apply to this 167 document. 169 6. IANA Considerations 171 This document has no actions for IANA. 173 7. Contributors 175 The following people contributed to successful deployment of solution 176 described in this document: 178 Jakob Heitz 179 Cisco 181 Email: jheitz@cisco.com 183 Ondrej Filip 184 CZ.NIC 186 Email: ondrej.filip@nic.cz 188 8. References 190 8.1. Normative References 192 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 193 Requirement Levels", BCP 14, RFC 2119, 194 DOI 10.17487/RFC2119, March 1997, 195 . 197 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 198 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 199 DOI 10.17487/RFC4271, January 2006, 200 . 202 8.2. Informative References 204 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 205 RFC 4272, DOI 10.17487/RFC4272, January 2006, 206 . 208 [RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., 209 and B. Dickson, "Problem Definition and Classification of 210 BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June 211 2016, . 213 Appendix A. Transition Considerations 215 This appendix is non-normative. 217 It is anticipated that transitioning to a compliant BGP 218 implementation will require a process thay may take several years. 220 It is understood and acknowledged that operators who are taking 221 advantage of an undefined behavior will always be surprised by 222 changes to said behavior. 224 A.1. N+1 N+2 Release Strategy 226 An implementer could leverage an approach described as "the N+1 and 227 N+2 release strategy". In release N+1, the implementer introduces a 228 new default configuration parameter to indicate that the BGP speaker 229 is operating in "ebgp insecure-mode". In addition to the 230 introduction of the new parameter, an implementer could begin to 231 display informational warnings to the operator that certain parts of 232 the configuration are incomplete. In release N+1, operators of the 233 BGP implementation become aware that a configurable default exists in 234 the implementation, and can prepare accordingly. In release N+2 or 235 later, the inverse of the previous default configuration parameter 236 that was introduced in release N+1 becomes the new default. 238 As a result, any new installation of release N+2 will adhere to this 239 document. Installations upgraded from version release N+1 will 240 adhere to the previous insecure behavior, if no modification was made 241 to the "ebgp insecure-mode" configuration parameter. 243 Authors' Addresses 245 Jared Mauch 246 Akamai Technologies 247 8285 Reese Lane 248 Ann Arbor Michigan 48103 249 US 251 Email: jared@akamai.com 253 Job Snijders 254 NTT Communications 255 Theodorus Majofskistraat 100 256 Amsterdam 1065 SZ 257 NL 259 Email: job@ntt.net 261 Greg Hankins 262 Nokia 263 777 E. Middlefield Road 264 Mountain View, CA 94043 265 USA 267 Email: greg.hankins@nokia.com