idnits 2.17.1 draft-ietf-grow-bgp-reject-03.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 (February 21, 2017) is 2619 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 J. Snijders 4 Intended status: Standards Track NTT 5 Expires: August 25, 2017 G. Hankins 6 Nokia 7 February 21, 2017 9 Default EBGP Route Propagation Behavior Without Policies 10 draft-ietf-grow-bgp-reject-03 12 Abstract 14 This document defines the default behavior of a BGP speaker when 15 there is no import or export policy associated with an External BGP 16 session. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 22 document are to be interpreted as described in RFC 2119 [RFC2119]. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 25, 2017. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Solution Requirements . . . . . . . . . . . . . . . . . . . . 3 60 3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 3 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 63 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 3 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 66 7.2. Informative References . . . . . . . . . . . . . . . . . 4 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 69 1. Introduction 71 BGP [RFC4271] speakers have many default settings which need to be 72 revisited as part of improving the routing ecosystem. There is a 73 need to provide guidance to BGP implementers for the default 74 behaviors of a well functioning Internet ecosystem. Routing leaks 75 [RFC7908] are part of the problem, but software defects and operator 76 misconfigurations are just a few of the attacks on Internet stability 77 we aim to address. 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 in a base router or VPN instances. When 91 this solution is implemented, BGP speakers do not accept or send 92 routes 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, and John Heasley. 122 4. Security Considerations 124 This document addresses a basic routing security flaw caused by 125 permissive default routing policy configurations. Operators need 126 implementers to address this problem with more secure defaults to 127 mitigate collateral damage on Internet routing. Inadvertent or 128 adversarial advertisements cause business impact that can be 129 mitigated by a secure default behavior. 131 5. IANA Considerations 133 This document has no actions for IANA. 135 6. Contributors 137 The following people contributed to successful deployment of solution 138 described in this document: 140 Jakob Heitz 141 Cisco 143 Email: jheitz@cisco.com 145 Ondrej Filip 146 CZ.NIC 148 Email: ondrej.filip@nic.cz 150 7. References 152 7.1. Normative References 154 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 155 Requirement Levels", BCP 14, RFC 2119, 156 DOI 10.17487/RFC2119, March 1997, 157 . 159 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 160 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 161 DOI 10.17487/RFC4271, January 2006, 162 . 164 7.2. Informative References 166 [RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., 167 and B. Dickson, "Problem Definition and Classification of 168 BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June 169 2016, . 171 Authors' Addresses 173 Jared Mauch 174 NTT Communications 175 8285 Reese Lane 176 Ann Arbor Michigan 48103 177 US 179 Email: jmauch@us.ntt.net 180 Job Snijders 181 NTT Communications 182 Theodorus Majofskistraat 100 183 Amsterdam 1065 SZ 184 NL 186 Email: job@ntt.net 188 Greg Hankins 189 Nokia 190 777 E. Middlefield Road 191 Mountain View, CA 94043 192 USA 194 Email: greg.hankins@nokia.com