idnits 2.17.1 draft-mauch-bgp-reject-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 20, 2015) is 3203 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) -- Looks like a reference, but probably isn't: 'TBD' on line 120 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Mauch 3 Internet-Draft J. Snijders 4 Intended status: Standards Track NTT 5 Expires: January 21, 2016 July 20, 2015 7 Require BGP implementers to advertise no routes 8 draft-mauch-bgp-reject-00.txt 10 Abstract 12 This document describes a solution to a common routing security 13 problem inherent in vendors with their security practices. 15 Foreword 17 A placeholder to list general observations about this document. 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 [1]. 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 January 21, 2016. 42 Copyright Notice 44 Copyright (c) 2015 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. Definitions and Accronyms . . . . . . . . . . . . . . . . . . 3 61 3. Solution Requirements . . . . . . . . . . . . . . . . . . . . 3 62 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 3 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 3 64 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 6.1. Normative References . . . . . . . . . . . . . . . . . . 3 66 6.2. Informative References . . . . . . . . . . . . . . . . . 4 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 69 1. Introduction 71 BGP speaking devices have many default settings which need to be 72 revisited as part of improving the routing ecosystem. There is a 73 need to provide guidace to BGP implementors for the default behaviors 74 of a well functioning internet ecosystem. Routing leaks [3] are part 75 of the problem, but software defects and operator misconfigurations 76 are just a few of the attacks on internet stability we aim to 77 address. 79 Usually BGP speaking devices accept all routes from a configured peer 80 or neighbor. This practice dates back to the early days of internet 81 protocols in being very permissive in offering routing information to 82 allow all networks to reach each other. With the core of the 83 internet becoming more densely interconnected the risk of a 84 misbehaving edge device or BGP speaking customer poses signficiant 85 risks to the reachability of critical services. 87 This proposal intends to solve this situation with the requiring the 88 explicity configuration of BGP policy for any non-iBGP speaking 89 session such as customers, peers or confederation boundaries. When 90 this solution is implemented, devices will no longer pass routes 91 without explicit policy. 93 2. Definitions and Accronyms 95 o BGP: Border Gateway Protocol [2] 97 3. Solution Requirements 99 The following requirements apply to the solution described in this 100 document: 102 o Software MUST NOT accept routes from an eBGP peer without an 103 operator configuring a policy 105 o Software MUST NOT require a configuration directive to operate in 106 this mode. 108 o Software MUST NOT send routes to an eBGP peer without an operator 109 configuring a policy 111 o Software MUST provide protection from internal failures preventing 112 the advertisement and acceptance of routes 114 o Software MAY provide a configuration option to disable this 115 security capability. 117 4. Acknowledgements 119 The authors would like to thank the following people for their 120 comments and support: [TBD]. 122 5. Security Considerations 124 This document addresses the basic security posture of a BGP speaking 125 device within a network. Operators have a need for implementors to 126 address the problem through a behavior change to mitigate against 127 possible attacks from a permissive security posture. Attacks and 128 inadvertent advertisements cause business impact necessitating this 129 default behavior. 131 6. References 133 6.1. Normative References 135 [1] Bradner, S., "Key words for use in RFCs to Indicate 136 Requirement Levels", BCP 14, RFC 2119, March 1997. 138 [2] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 139 Protocol 4 (BGP-4)", RFC 4271, January 2006. 141 6.2. Informative References 143 [3] "Methods for Detection and Mitigation of BGP Route Leaks", 144 . 147 Authors' Addresses 149 Jared Mauch 150 NTT Communications, Inc. 151 8285 Reese Lane 152 Ann Arbor Michigan 48103 153 US 155 Email: jmauch@us.ntt.net 157 Job Snijders 158 NTT Communications, Inc. 159 Amsterdam 160 NL 162 Email: job@ntt.net