idnits 2.17.1 draft-ietf-grow-bgp-reject-04.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 (March 27, 2017) is 2559 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 Intended status: Standards Track J. Snijders 5 Expires: September 28, 2017 NTT 6 G. Hankins 7 Nokia 8 March 27, 2017 10 Default EBGP Route Propagation Behavior Without Policies 11 draft-ietf-grow-bgp-reject-04 13 Abstract 15 This document defines the default behavior of a BGP speaker when 16 there is no import or export policy associated with an External BGP 17 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 September 28, 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. Solution Requirements . . . . . . . . . . . . . . . . . . . . 3 61 3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 3 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 64 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 3 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 67 7.2. Informative References . . . . . . . . . . . . . . . . . 4 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 70 1. Introduction 72 There are BGP routing security issues that need to be addressed to 73 make the Internet more stable. Route leaks [RFC7908] are part of the 74 problem, but software defects or operator misconfigurations can 75 contribute too. This document provides guidance to BGP [RFC4271] 76 implementers to improve the default level of Internet routing 77 security. 79 Many deployed BGP speakers send and accept any and all route 80 announcements between their BGP neighbors by default. This practice 81 dates back to the early days of the Internet, where operators were 82 permissive in sending routing information to allow all networks to 83 reach each other. As the Internet has become more densely 84 interconnected, the risk of a misbehaving BGP speaker poses 85 significant risks to Internet routing. 87 This specification intends to improve this situation by requiring the 88 explicit configuration of a BGP import and export policy for any 89 External BGP (EBGP) session such as customers, peers, or 90 confederation boundaries for all enabled address families. When this 91 solution is implemented, BGP speakers do not accept or send routes 92 without policies configured on EBGP sessions. 94 2. Solution Requirements 96 The following requirements apply to the solution described in this 97 document: 99 o Software MUST consider any routes ineligible for route selection 100 (section 9.1.1 [RFC4271]), if no import policy was configured for 101 the EBGP peer. 103 o Software MUST NOT advertise any routes to an EBGP peer, if no 104 export policy was configured. 106 o Software SHOULD fall back to an "import nothing" and "export 107 nothing" mode following failure of internal components, such as a 108 policy engine. 110 o Software MUST operate in this mode by default. 112 o Software MAY provide a configuration option to disable this 113 security capability. 115 3. Acknowledgments 117 The authors would like to thank the following people for their 118 comments, support and review: Shane Amante, Christopher Morrow, 119 Robert Raszuk, Greg Skinner, Adam Chappell, Sriram Kotikalapudi, 120 Brian Dickson, Jeffrey Haas, John Heasley, Ignas Bagdonas and Donald 121 Smith. 123 4. Security Considerations 125 This document addresses a basic routing security issue caused by 126 permissive default routing policy configurations. Operators need 127 implementers to address this problem with more secure defaults to 128 mitigate collateral damage on Internet routing. Inadvertent or 129 adversarial advertisements cause business impact that can be 130 mitigated by a secure default behavior. 132 5. IANA Considerations 134 This document has no actions for IANA. 136 6. Contributors 138 The following people contributed to successful deployment of solution 139 described in this document: 141 Jakob Heitz 142 Cisco 144 Email: jheitz@cisco.com 146 Ondrej Filip 147 CZ.NIC 149 Email: ondrej.filip@nic.cz 151 7. References 153 7.1. Normative References 155 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 156 Requirement Levels", BCP 14, RFC 2119, 157 DOI 10.17487/RFC2119, March 1997, 158 . 160 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 161 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 162 DOI 10.17487/RFC4271, January 2006, 163 . 165 7.2. Informative References 167 [RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., 168 and B. Dickson, "Problem Definition and Classification of 169 BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June 170 2016, . 172 Authors' Addresses 174 Jared Mauch 175 Akamai Technologies 176 8285 Reese Lane 177 Ann Arbor Michigan 48103 178 US 180 Email: jared@akamai.com 181 Job Snijders 182 NTT Communications 183 Theodorus Majofskistraat 100 184 Amsterdam 1065 SZ 185 NL 187 Email: job@ntt.net 189 Greg Hankins 190 Nokia 191 777 E. Middlefield Road 192 Mountain View, CA 94043 193 USA 195 Email: greg.hankins@nokia.com