| draft-ietf-grow-bgp-reject-07.txt | | draft-ietf-grow-bgp-reject-08.txt | |
| | | | |
| Global Routing Operations J. Mauch | | Global Routing Operations J. Mauch | |
| Internet-Draft Akamai | | Internet-Draft Akamai | |
| Updates: 4271 (if approved) J. Snijders | | Updates: 4271 (if approved) J. Snijders | |
| Intended status: Standards Track NTT | | Intended status: Standards Track NTT | |
|
| Expires: November 9, 2017 G. Hankins | | Expires: November 23, 2017 G. Hankins | |
| Nokia | | Nokia | |
|
| May 8, 2017 | | May 22, 2017 | |
| | | | |
| Default EBGP Route Propagation Behavior Without Policies | | Default EBGP Route Propagation Behavior Without Policies | |
|
| draft-ietf-grow-bgp-reject-07 | | draft-ietf-grow-bgp-reject-08 | |
| | | | |
| Abstract | | Abstract | |
| | | | |
| This document updates RFC4271 by defining the default behavior of a | | This document updates RFC4271 by defining the default behavior of a | |
| BGP speaker when there is no Import or Export Policy associated with | | BGP speaker when there is no Import or Export Policy associated with | |
| an External BGP session. | | an External BGP 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 November 9, 2017. | | This Internet-Draft will expire on November 23, 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 | |
| | | | |
| skipping to change at page 2, line 25 | | skipping to change at page 2, line 25 | |
| 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 | | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |
| 3. Changes to RFC4271 . . . . . . . . . . . . . . . . . . . . . 3 | | 3. Changes to RFC4271 . . . . . . . . . . . . . . . . . . . . . 3 | |
| 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 | | 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 | |
| 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 | | 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 | |
| 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 | | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 | |
| 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 4 | | 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 4 | |
| 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 | | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |
| 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 | | 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 | |
| 8.2. Informative References . . . . . . . . . . . . . . . . . 5 | | 8.2. Informative References . . . . . . . . . . . . . . . . . 5 | |
| Appendix A. Transition Considerations . . . . . . . . . . . . . 5 | | Appendix A. Transition Considerations . . . . . . . . . . . . . 5 | |
|
| A.1. N+1 N+2 Release Strategy . . . . . . . . . . . . . . . . 5 | | A.1. "N+1 N+2" Release Strategy . . . . . . . . . . . . . . . 5 | |
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 | | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 | |
| | | | |
| 1. Introduction | | 1. Introduction | |
| | | | |
| BGP routing security issues need to be addressed in order to make the | | BGP routing security issues need to be addressed in order to make the | |
| Internet more stable. Route leaks [RFC7908] are part of the problem, | | Internet more stable. Route leaks [RFC7908] are part of the problem, | |
| but software defects or operator misconfiguration can contribute too. | | but software defects or operator misconfiguration can contribute too. | |
|
| This document updates [RFC4271] in order to improve the default level | | This document updates [RFC4271] so that routes are neither imported | |
| of Internet routing security. | | nor exported unless specifically enabled by configuration. The | |
| | | solution reduces the consequences of these problems, and improves the | |
| | | default level of Internet routing security. | |
| | | | |
| Many deployed BGP speakers send and accept any and all route | | Many deployed BGP speakers send and accept any and all route | |
| announcements between their BGP neighbors by default. This practice | | announcements between their BGP neighbors by default. This practice | |
| dates back to the early days of the Internet, where operators were | | dates back to the early days of the Internet, where operators were | |
| permissive in sending routing information to allow all networks to | | permissive in sending routing information to allow all networks to | |
| reach each other. As the Internet has become more densely | | reach each other. As the Internet has become more densely | |
| 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 both BGP Import and Export Policies for any | | explicit configuration of both BGP Import and Export Policies 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. Through | | confederation boundaries for all enabled address families. Through | |
| codification of the aforementioned requirement, operators will | | codification of the aforementioned requirement, operators will | |
| benefit from consistent behaviour across different BGP | | benefit from consistent behaviour across different BGP | |
| implementations. | | implementations. | |
| | | | |
| BGP speakers following this specification do not use or send routes | | BGP speakers following this specification do not use or send routes | |
|
| on EBGP sessions, unless configured to do otherwise. | | on EBGP sessions, unless specifically configured to do so. | |
| | | | |
| 2. Terminology | | 2. Terminology | |
| | | | |
| [RFC4271] describes a Policy Information Base (PIB) which contains | | [RFC4271] describes a Policy Information Base (PIB) which contains | |
| local policies that can be applied to the information in the Routing | | local policies that can be applied to the information in the Routing | |
|
| Information Base (RIB). This document distinguishes the type of | | Information Base (RIB). This document distinguishes the type of a | |
| policy based on its application. | | policy based on its application. | |
| | | | |
| Import Policy: a local policy to be applied to the information | | Import Policy: a local policy to be applied to the information | |
| contained in the Adj-RIBs-In. As described in Section 3.2 [RFC4271], | | contained in the Adj-RIBs-In. As described in Section 3.2 [RFC4271], | |
| the Adj-RIBs-In contain information learned from other BGP speakers, | | the Adj-RIBs-In contain information learned from other BGP speakers, | |
| and the application of the Import Policy results in the routes that | | and the application of the Import Policy results in the routes that | |
| will be considered in the Decision Process by the local BGP speaker. | | will be considered in the Decision Process by the local BGP speaker. | |
| | | | |
| Export Policy: a local policy to be applied in selecting the | | Export Policy: a local policy to be applied in selecting the | |
| information contained in the Adj-RIBs-Out. As described in | | information contained in the Adj-RIBs-Out. As described in | |
| Section 3.2 [RFC4271], the Adj-RIBs-Out contain information that has | | Section 3.2 [RFC4271], the Adj-RIBs-Out contain information that has | |
| been selected for advertisement to other BGP speakers. | | been selected for advertisement to other BGP speakers. | |
| | | | |
| 3. Changes to RFC4271 | | 3. Changes to RFC4271 | |
| | | | |
|
| This section describes the Updates to [RFC4271] that define the | | This section updates [RFC4271] to specify the default behavior of a | |
| default behavior of a BGP speaker when there are no Import or Export | | BGP speaker when there are no Import or Export Policies associated | |
| Policies associated with a particular EBGP session. A BGP speaker | | with a particular EBGP session. A BGP speaker MAY provide a | |
| MAY provide a configuration option to deviate from the following | | configuration option to deviate from the following updated behaviors. | |
| updated behaviors. | | | |
| | | | |
| The following paragraph is added to Section 9.1 (Decision Process) | | The following paragraph is added to Section 9.1 (Decision Process) | |
|
| after the fifth paragraph ending in "route aggregation and route | | after the fifth paragraph, which ends in "route aggregation and route | |
| information reduction": | | information reduction": | |
| | | | |
| Routes contained in an Adj-RIB-In associated with an EBGP peer | | Routes contained in an Adj-RIB-In associated with an EBGP peer | |
| SHALL NOT be considered eligible in the Decision Process if no | | SHALL NOT be considered eligible in the Decision Process if no | |
| explicit Import Policy has been applied. | | explicit Import Policy has been applied. | |
| | | | |
| The following paragraph is added to Section 9.1.3 (Phase 3: Route | | The following paragraph is added to Section 9.1.3 (Phase 3: Route | |
|
| Dissemination) after the third paragraph ending in "by means of an | | Dissemination) after the third paragraph, which ends in "by means of | |
| UPDATE message (see 9.2).": | | an UPDATE message (see 9.2).": | |
| | | | |
| Routes SHALL NOT be added to an Adj-RIB-Out associated with an | | Routes SHALL NOT be added to an Adj-RIB-Out associated with an | |
| EBGP peer if no explicit Export Policy has been applied. | | EBGP peer if no explicit Export Policy has been applied. | |
| | | | |
| 4. Acknowledgments | | 4. 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, Donald | | Brian Dickson, Jeffrey Haas, John Heasley, Ignas Bagdonas, Donald | |
|
| Smith, Dale Worley, Alvaro Retana, and John Scudder. | | Smith, Dale Worley, Alvaro Retana, John Scudder, and Dale Worley. | |
| | | | |
| 5. Security Considerations | | 5. Security Considerations | |
| | | | |
| Permissive default routing policies can result in inadvertent effects | | Permissive default routing policies can result in inadvertent effects | |
|
| such as route leaks [RFC7908], in general resulting in rerouting of | | such as route leaks [RFC7908], in general resulting in routing of | |
| traffic through an unexpected path. While it is possible for an | | traffic through an unexpected path. While it is possible for an | |
| operator to use monitoring to detect unexpected flows, there is no | | operator to use monitoring to detect unexpected flows, there is no | |
| general framework that can be applied. These policies also have the | | general framework that can be applied. These policies also have the | |
| potential to expose software defects or misconfiguration that could | | potential to expose software defects or misconfiguration that could | |
| have unforeseen technical and business impacting effects. | | have unforeseen technical and business impacting effects. | |
| | | | |
| The update to [RFC4271] specified in this document is intended to | | The update to [RFC4271] specified in this document is intended to | |
| eliminate those inadvertent effects. Operators must explicitly | | eliminate those inadvertent effects. Operators must explicitly | |
| configure Import and Export Policies to achieve their expected goals. | | configure Import and Export Policies to achieve their expected goals. | |
| There is of course no protection against a malicious or incorrect | | There is of course no protection against a malicious or incorrect | |
| | | | |
| skipping to change at page 5, line 34 | | skipping to change at page 5, line 34 | |
| | | | |
| [RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., | | [RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., | |
| and B. Dickson, "Problem Definition and Classification of | | and B. Dickson, "Problem Definition and Classification of | |
| BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June | | BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June | |
| 2016, <http://www.rfc-editor.org/info/rfc7908>. | | 2016, <http://www.rfc-editor.org/info/rfc7908>. | |
| | | | |
| Appendix A. Transition Considerations | | Appendix A. Transition Considerations | |
| | | | |
| This appendix is non-normative. | | This appendix is non-normative. | |
| | | | |
|
| It is anticipated that transitioning to a compliant BGP | | Transitioning to a compliant BGP implementation may require a | |
| implementation will require a process thay may take several years. | | software development and release process that can take implementers | |
| | | several years. | |
| | | | |
| It is understood and acknowledged that operators who are taking | | It is understood and acknowledged that operators who are taking | |
| advantage of an undefined behavior will always be surprised by | | advantage of an undefined behavior will always be surprised by | |
| changes to said behavior. | | changes to said behavior. | |
| | | | |
|
| A.1. N+1 N+2 Release Strategy | | A.1. "N+1 N+2" Release Strategy | |
| | | | |
|
| An implementer could leverage an approach described as "the N+1 and | | An implementer could leverage an approach described as the "N+1 and | |
| N+2 release strategy". In release N+1, the implementer introduces a | | N+2" release strategy. In release N+1, the implementer introduces a | |
| new default configuration parameter to indicate that the BGP speaker | | new default configuration parameter to indicate that the BGP speaker | |
| is operating in "ebgp insecure-mode". In addition to the | | is operating in "ebgp insecure-mode". In addition to the | |
| introduction of the new parameter, an implementer could begin to | | introduction of the new parameter, an implementer could begin to | |
| display informational warnings to the operator that certain parts of | | display informational warnings to the operator that certain parts of | |
| the configuration are incomplete. In release N+1, operators of the | | the configuration are incomplete. In release N+1, operators of the | |
| BGP implementation become aware that a configurable default exists in | | BGP implementation become aware that a configurable default exists in | |
| the implementation, and can prepare accordingly. In release N+2 or | | the implementation, and can prepare accordingly. In release N+2 or | |
| later, the inverse of the previous default configuration parameter | | later, the inverse of the previous default configuration parameter | |
| that was introduced in release N+1 becomes the new default. | | that was introduced in release N+1 becomes the new default. | |
| | | | |
| | | | |
End of changes. 16 change blocks. |
| 24 lines changed or deleted | | 26 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/ |