idnits 2.17.1 draft-ietf-grow-bgp-reject-01.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 10, 2016) is 2906 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) == Outdated reference: A later version (-11) exists of draft-ietf-idr-route-leak-detection-mitigation-02 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 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: November 11, 2016 May 10, 2016 7 By default reject propagation when no policy is associated with a BGP 8 peering session. 9 draft-ietf-grow-bgp-reject-01 11 Abstract 13 This document defines the default behaviour of a BGP speaker when no 14 explicit policy is associated with a BGP peering session. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on November 11, 2016. 33 Copyright Notice 35 Copyright (c) 2016 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 52 3. Solution Requirements . . . . . . . . . . . . . . . . . . . . 2 53 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 3 54 5. Security Considerations . . . . . . . . . . . . . . . . . . . 3 55 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 56 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 7.1. Normative References . . . . . . . . . . . . . . . . . . 3 58 7.2. Informative References . . . . . . . . . . . . . . . . . 4 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 61 1. Introduction 63 BGP [RFC4271] speakers have many default settings which need to be 64 revisited as part of improving the routing ecosystem. There is a 65 need to provide guidance to BGP implementors for the default 66 behaviors of a well functioning internet ecosystem. Routing leaks 67 [I-D.ietf-idr-route-leak-detection-mitigation] are part of the 68 problem, but software defects and operator misconfigurations are just 69 a few of the attacks on internet stability we aim to address. 71 Usually BGP speakers accept all routes from a configured peer or 72 neighbor. This practice dates back to the early days of internet 73 protocols in being very permissive in offering routing information to 74 allow all networks to reach each other. With the core of the 75 internet becoming more densely interconnected the risk of a 76 misbehaving edge device or BGP speaking customer poses signficiant 77 risks to the reachability of critical services. 79 This proposal intends to solve this situation by requiring the 80 explicit configuration of BGP policy for any non-iBGP speaking 81 session such as customers, peers or confederation boundaries. When 82 this solution is implemented, devices will no longer pass routes 83 without explicit policy. 85 2. Requirements Language 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in RFC 2119 [RFC2119]. 91 3. Solution Requirements 93 The following requirements apply to the solution described in this 94 document: 96 o Software MUST mark any routes from an eBGP peer as 'invalid' in 97 the Adj-RIB-In, if no explicit policy was configured. 99 o Software MUST NOT advertise any routes to an eBGP peer without an 100 operator configuring a policy. 102 o Software MUST NOT require a configuration directive to operate in 103 this mode. 105 o Software MUST provide protection from internal failures preventing 106 the advertisement and acceptance of routes. 108 o Software MAY provide a configuration option to disable this 109 security capability. 111 4. Acknowledgements 113 The authors would like to thank the following people for their 114 comments and support: Shane Amante, Christopher Morrow, Robert 115 Raszuk, Greg Skinner. 117 5. Security Considerations 119 This document addresses the basic security posture of a BGP speaking 120 device within a network. Operators have a need for implementors to 121 address the problem through a behavior change to mitigate against 122 possible attacks from a permissive security posture. Attacks and 123 inadvertent advertisements cause business impact necessitating this 124 default behavior. 126 6. IANA Considerations 128 This document has no actions for IANA. 130 7. References 132 7.1. Normative References 134 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 135 Requirement Levels", BCP 14, RFC 2119, 136 DOI 10.17487/RFC2119, March 1997, 137 . 139 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 140 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 141 DOI 10.17487/RFC4271, January 2006, 142 . 144 7.2. Informative References 146 [I-D.ietf-idr-route-leak-detection-mitigation] 147 Sriram, K., Montgomery, D., Dickson, B., Patel, K., and A. 148 Robachevsky, "Methods for Detection and Mitigation of BGP 149 Route Leaks", draft-ietf-idr-route-leak-detection- 150 mitigation-02 (work in progress), March 2016. 152 Authors' Addresses 154 Jared Mauch 155 NTT Communications, Inc. 156 8285 Reese Lane 157 Ann Arbor Michigan 48103 158 US 160 Email: jmauch@us.ntt.net 162 Job Snijders 163 NTT Communications, Inc. 164 Theodorus Majofskistraat 100 165 Amsterdam 1065 SZ 166 NL 168 Email: job@ntt.net