| draft-ietf-grow-bgp-reject-04.txt | | draft-ietf-grow-bgp-reject-05.txt | |
| | | | |
| Global Routing Operations J. Mauch | | Global Routing Operations J. Mauch | |
| Internet-Draft Akamai | | Internet-Draft Akamai | |
| Intended status: Standards Track J. Snijders | | Intended status: Standards Track J. Snijders | |
|
| Expires: September 28, 2017 NTT | | Expires: October 13, 2017 NTT | |
| G. Hankins | | G. Hankins | |
| Nokia | | Nokia | |
|
| March 27, 2017 | | April 11, 2017 | |
| | | | |
| Default EBGP Route Propagation Behavior Without Policies | | Default EBGP Route Propagation Behavior Without Policies | |
|
| draft-ietf-grow-bgp-reject-04 | | draft-ietf-grow-bgp-reject-05 | |
| | | | |
| Abstract | | Abstract | |
| | | | |
| This document defines the default behavior of a BGP speaker when | | This document defines the default behavior of a BGP speaker when | |
| there is no import or export policy associated with an External BGP | | there is no import or export policy associated with an External BGP | |
| session. | | session. | |
| | | | |
| Requirements Language | | Requirements Language | |
| | | | |
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |
| | | | |
| skipping to change at page 1, line 41 | | skipping to change at page 1, line 41 | |
| Internet-Drafts are working documents of the Internet Engineering | | Internet-Drafts are working documents of the Internet Engineering | |
| Task Force (IETF). Note that other groups may also distribute | | Task Force (IETF). Note that other groups may also distribute | |
| working documents as Internet-Drafts. The list of current Internet- | | working documents as Internet-Drafts. The list of current Internet- | |
| Drafts is at http://datatracker.ietf.org/drafts/current/. | | Drafts is at http://datatracker.ietf.org/drafts/current/. | |
| | | | |
| Internet-Drafts are draft documents valid for a maximum of six months | | Internet-Drafts are draft documents valid for a maximum of six months | |
| and may be updated, replaced, or obsoleted by other documents at any | | and may be updated, replaced, or obsoleted by other documents at any | |
| time. It is inappropriate to use Internet-Drafts as reference | | time. It is inappropriate to use Internet-Drafts as reference | |
| material or to cite them other than as "work in progress." | | material or to cite them other than as "work in progress." | |
| | | | |
|
| This Internet-Draft will expire on September 28, 2017. | | This Internet-Draft will expire on October 13, 2017. | |
| | | | |
| Copyright Notice | | Copyright Notice | |
| | | | |
| Copyright (c) 2017 IETF Trust and the persons identified as the | | Copyright (c) 2017 IETF Trust and the persons identified as the | |
| document authors. All rights reserved. | | document authors. All rights reserved. | |
| | | | |
| This document is subject to BCP 78 and the IETF Trust's Legal | | This document is subject to BCP 78 and the IETF Trust's Legal | |
| Provisions Relating to IETF Documents | | Provisions Relating to IETF Documents | |
| (http://trustee.ietf.org/license-info) in effect on the date of | | (http://trustee.ietf.org/license-info) in effect on the date of | |
| publication of this document. Please review these documents | | publication of this document. Please review these documents | |
| carefully, as they describe your rights and restrictions with respect | | carefully, as they describe your rights and restrictions with respect | |
| to this document. Code Components extracted from this document must | | to this document. Code Components extracted from this document must | |
| include Simplified BSD License text as described in Section 4.e of | | include Simplified BSD License text as described in Section 4.e of | |
| the Trust Legal Provisions and are provided without warranty as | | the Trust Legal Provisions and are provided without warranty as | |
| described in the Simplified BSD License. | | described in the Simplified BSD License. | |
| | | | |
| Table of Contents | | Table of Contents | |
| | | | |
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |
|
| 2. Solution Requirements . . . . . . . . . . . . . . . . . . . . 3 | | 2. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |
| 3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 3 | | 3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 3 | |
| 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 | | 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 | |
| 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 | | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 | |
| 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 3 | | 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 3 | |
| 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 | | 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |
| 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 | | 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 | |
| 7.2. Informative References . . . . . . . . . . . . . . . . . 4 | | 7.2. Informative References . . . . . . . . . . . . . . . . . 4 | |
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 | | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 | |
| | | | |
| 1. Introduction | | 1. Introduction | |
| | | | |
| skipping to change at page 3, line 5 | | skipping to change at page 3, line 5 | |
| interconnected, the risk of a misbehaving BGP speaker poses | | interconnected, the risk of a misbehaving BGP speaker poses | |
| significant risks to Internet routing. | | significant risks to Internet routing. | |
| | | | |
| This specification intends to improve this situation by requiring the | | This specification intends to improve this situation by requiring the | |
| explicit configuration of a BGP import and export policy for any | | explicit configuration of a BGP import and export policy for any | |
| External BGP (EBGP) session such as customers, peers, or | | External BGP (EBGP) session such as customers, peers, or | |
| confederation boundaries for all enabled address families. When this | | confederation boundaries for all enabled address families. When this | |
| solution is implemented, BGP speakers do not accept or send routes | | solution is implemented, BGP speakers do not accept or send routes | |
| without policies configured on EBGP sessions. | | without policies configured on EBGP sessions. | |
| | | | |
|
| 2. Solution Requirements | | 2. Solution | |
| | | | |
|
| The following requirements apply to the solution described in this | | The following requirements apply to all BGP speakers: | |
| document: | | | |
| | | | |
|
| o Software MUST consider any routes ineligible for route selection | | o A BGP speaker MUST consider any routes advertised by an EBGP peer | |
| (section 9.1.1 [RFC4271]), if no import policy was configured for | | (section 9.1.1 [RFC4271]), if no import policy was configured for | |
|
| the EBGP peer. | | the peer. | |
| | | | |
|
| o Software MUST NOT advertise any routes to an EBGP peer, if no | | o A BGP speaker MUST NOT advertise any routes to an EBGP peer, if no | |
| export policy was configured. | | export policy was configured. | |
| | | | |
|
| o Software SHOULD fall back to an "import nothing" and "export | | o A BGP speaker SHOULD fall back to an "import nothing" and "export | |
| nothing" mode following failure of internal components, such as a | | nothing" mode following failure of internal components, such as a | |
| policy engine. | | policy engine. | |
| | | | |
|
| o Software MUST operate in this mode by default. | | o A BGP speaker MAY provide a configuration option to disable the | |
| | | preceding behaviors, but it MUST implement them by default. | |
| o Software MAY provide a configuration option to disable this | | | |
| security capability. | | | |
| | | | |
| 3. Acknowledgments | | 3. Acknowledgments | |
| | | | |
| The authors would like to thank the following people for their | | The authors would like to thank the following people for their | |
| comments, support and review: Shane Amante, Christopher Morrow, | | comments, support and review: Shane Amante, Christopher Morrow, | |
| Robert Raszuk, Greg Skinner, Adam Chappell, Sriram Kotikalapudi, | | Robert Raszuk, Greg Skinner, Adam Chappell, Sriram Kotikalapudi, | |
|
| Brian Dickson, Jeffrey Haas, John Heasley, Ignas Bagdonas and Donald | | Brian Dickson, Jeffrey Haas, John Heasley, Ignas Bagdonas, Donald | |
| Smith. | | Smith, and Dale Worley. | |
| | | | |
| 4. Security Considerations | | 4. Security Considerations | |
| | | | |
| This document addresses a basic routing security issue caused by | | This document addresses a basic routing security issue caused by | |
| permissive default routing policy configurations. Operators need | | permissive default routing policy configurations. Operators need | |
| implementers to address this problem with more secure defaults to | | implementers to address this problem with more secure defaults to | |
| mitigate collateral damage on Internet routing. Inadvertent or | | mitigate collateral damage on Internet routing. Inadvertent or | |
| adversarial advertisements cause business impact that can be | | adversarial advertisements cause business impact that can be | |
| mitigated by a secure default behavior. | | mitigated by a secure default behavior. | |
| | | | |
| | | | |
End of changes. 13 change blocks. |
| 18 lines changed or deleted | | 15 lines changed or added | |
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |