--- 1/draft-ietf-idr-bgp-open-policy-09.txt 2020-05-15 14:13:21.853198548 -0700 +++ 2/draft-ietf-idr-bgp-open-policy-10.txt 2020-05-15 14:13:21.881199256 -0700 @@ -1,24 +1,24 @@ Network Working Group A. Azimov Internet-Draft E. Bogomazov Intended status: Standards Track Qrator Labs -Expires: October 21, 2020 R. Bush - Internet Initiative Japan & Arrcus +Expires: November 16, 2020 R. Bush + Internet Initiative Japan & Arrcus, Inc. K. Patel - Arrcus, Inc. + Arrcus K. Sriram - US NIST - April 19, 2020 + USA NIST + May 15, 2020 Route Leak Prevention using Roles in Update and Open messages - draft-ietf-idr-bgp-open-policy-09 + draft-ietf-idr-bgp-open-policy-10 Abstract Route leaks are the propagation of BGP prefixes which violate assumptions of BGP topology relationships; e.g. passing a route learned from one peer to another peer or to a transit provider, passing a route learned from one transit provider to another transit provider or to a peer. Today, approaches to leak prevention rely on marking routes by operator configuration, with no check that the configuration corresponds to that of the BGP neighbor, or enforcement @@ -46,21 +46,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on October 21, 2020. + This Internet-Draft will expire on November 16, 2020. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -76,24 +76,25 @@ 2. Peering Relationships . . . . . . . . . . . . . . . . . . . . 3 3. BGP Role . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. BGP Role Capability . . . . . . . . . . . . . . . . . . . . . 4 5. Role correctness . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Strict mode . . . . . . . . . . . . . . . . . . . . . . . 6 6. BGP Only to Customer (OTC) Attribute . . . . . . . . . . . . 6 7. Enforcement . . . . . . . . . . . . . . . . . . . . . . . . . 7 8. Additional Considerations . . . . . . . . . . . . . . . . . . 7 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 10. Security Considerations . . . . . . . . . . . . . . . . . . . 8 - 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 12.1. Normative References . . . . . . . . . . . . . . . . . . 8 - 12.2. Informative References . . . . . . . . . . . . . . . . . 9 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 8 + 11.2. Informative References . . . . . . . . . . . . . . . . . 9 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10 + Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction A BGP route leak occurs when a route is learned from a transit provider or peer and then announced to another provider or peer. See [RFC7908]. These are usually the result of misconfigured or absent BGP route filtering or lack of coordination between two BGP speakers. The mechanism proposed in @@ -344,29 +345,23 @@ 10. Security Considerations This document proposes a mechanism for prevention of route leaks that are the result of BGP policy misconfiguration. A misconfiguration in OTC setup may affect prefix propagation. But the automation that is provided by BGP roles should make such misconfiguration unlikely. -11. Acknowledgments - - The authors wish to thank Douglas Montgomery, Brian Dickson, Andrei - Robachevsky, and Daniel Ginsburg for their contributions to a variant - of this work. - -12. References +11. References -12.1. Normative References +11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, . @@ -376,21 +371,21 @@ April 2006, . [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 2009, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . -12.2. Informative References +11.2. Informative References [Gao] Gao, L. and J. Rexford, "Stable Internet routing without global coordination", IEEE/ACM Transactions on Networking, Volume 9, Issue 6, pp 689-692, DOI 10.1109/90.974523, December 2001, . [I-D.ietf-grow-route-leak-detection-mitigation] Sriram, K. and A. Azimov, "Methods for Detection and Mitigation of BGP Route Leaks", draft-ietf-grow-route- @@ -412,36 +407,66 @@ RFC 8212, DOI 10.17487/RFC8212, July 2017, . [Streibelt] Streibelt, F., Lichtblau, F., Beverly, R., Feldmann, A., Cristel, C., Smaragdakis, G., and R. Bush, "BGP Communities: Even more Worms in the Routing Can", . +Acknowledgements + + The authors wish to thank Andrei Robachevsky, Daniel Ginsburg, Jeff + Haas, Ruediger Volk, Sue Hares, and John Scudder for comments, + suggestions, and critique. + +Contributors + + Brian Dickson + Independent + Email: brian.peter.dickson@gmail.com + + Doug Montgomery + USA National Institute of Standards and Technology + Email: dougm@nist.gov + Authors' Addresses Alexander Azimov Qrator Labs + 1-y Magistralnyy tupik 5A + Moscow 123290 + Russian Federation Email: a.e.azimov@gmail.com Eugene Bogomazov Qrator Labs + 1-y Magistralnyy tupik 5A + Moscow 123290 + Russian Federation Email: eb@qrator.net Randy Bush - Internet Initiative Japan & Arrcus + Internet Initiative Japan & Arrcus, Inc. + 5147 Crystal Springs + Bainbridge Island, Washington 98110 + United States of America Email: randy@psg.com - Keyur Patel - Arrcus, Inc. + Arrcus + 2077 Gateway Place, Suite #400 + San Jose, CA 95119 + US Email: keyur@arrcus.com Kotikalapudi Sriram - US NIST + USA National Institute of Standards and Technology + 100 Bureau Drive + Gaithersburg, MD 20899 + United States of America Email: ksriram@nist.gov