INTERNET-DRAFT 13 November 2001 Xiaoliang Zhao NC State University Allison Mankin Daniel Massey USC/ISI Dan Pei Lan Wang UCLA S. Felix Wu UC Davis Lixia Zhang UCLA Validation of Multiple Origin ASes Conflicts through BGP Community Attribute draft-zhao-idr-moas-validation-00.txt Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Distribution of this memo is unlimited. Abstract Recent measurements show that a single IP address prefix often appears to originate from multiple ASes (Multiple Origin AS, or MOAS). MOAS can be due to either legitimate Zhao/Mankin/Massey/Pei/Wang/Wu/Zhang Page 1 INTERNET-DRAFT 13 November 2001 operational need or faults. This document defines a new BGP Community to distinguish valid MOAS from faults. 1 Introduction A Multiple Origin Autonomous System (MOAS) conflict occurs if an IP address prefix appears to originate from more than one AS. RFC 1930 [BGP-AS] recommends that a prefix should be originated from a single AS with few exceptions. Our recent measurements [MOAS-IMW] show, however, that MOAS is a common phenomenon today, caused by either operational practices such as support for multi-homing, or by misconfiguration or software bugs. We believe that blind acceptance of MOAS conflicts, which is the default practice today, is potentially dangerous as it opens the door for traffic hijacking. In this document we define a new BGP Community, termed "MOAS List", to distinguish valid MOAS conflicts from invalid ones. 2 MOAS List The BGP Community Attribute, as defined in [BGP-COM], provides a mechanism for a BGP speaker to pass additional information to both peering neighbors and remote BGP routers. The MOAS List for an IP prefix, P, should be generated by an AS that either owns the prefix P, or is delegated to make BGP announcement for the prefix P. The MOAS List should be attached to the BGP announcement. It should list all the ASes that are entitled to announce P's reachability. For example, a MOAS List indicates that AS1, AS2, ..., ASn are valid origin ASes for the same prefix. The value of the MLVal will be assigned by ICANN. A MOAS List is encoded as follows: +----------------------------+ | AS number 1 (2 octets) | +----------------------------+ | MLVal (2 octets) | +----------------------------+ | AS number 2 (2 octets) | +----------------------------+ | MLVal (2 octets) | +----------------------------+ Zhao/Mankin/Massey/Pei/Wang/Wu/Zhang Page 2 INTERNET-DRAFT 13 November 2001 | ... | +----------------------------+ | AS number n (2 octets) | +----------------------------+ | MLVal (2 octets) | +----------------------------+ 3 Operations 3.1 Agreement on MOAS List When a prefix P needs to be announced by multiple ASes, all the ASes that are entitled to make announcement for P should first reach agreement on the common MOAS list. 3.2 Attaching MOAS List Each of the above mentioned ASes should attach the same MOAS List when making route announcement for prefix P to its neighbors. 3.3 Checking MOAS List When a BGP router receives route announcements for the same prefix P from multiple peers, it must check to see whether all the MOAS Lists for P are consistent. Here consistency is defined as the same set of ASes listed in the MOAS List, the order in the list may differ; if the number of ASes in the list from different peers differs, or if the AS set is different, we consider the MOAS List inconsistent. If the BGP router notices any inconsistency in the MOAS Lists received from multiple peering neighbors, it should generate an alarm signal to inform the network operator. The operator can then further investigate the cause of the inconsistency. Also, in this case, the local policy will decide to accept the corresponding routes or not. A MOAS MIB will be defined later to report traps as alarm signals and other detailed information about those existing MOAS conflicts. 3.4 Propagating MOAS List When a BGP router accepts a route with MOAS List and passes it along to its BGP peers, it must pass the MOAS List of that route together Zhao/Mankin/Massey/Pei/Wang/Wu/Zhang Page 3 INTERNET-DRAFT 13 November 2001 with the route. If the BGP router aggregates a prefix P that has a MOAS List, the MOAS List of P must not be attached to the aggregated prefix. 4 Example +---+ +---+ |---|AS1|---|AS3|\ | +---+ +---+ \+---+ P-| |AS5| | +---+ +---+ /+---+ |---|AS2|---|AS4|/ +---+ +---+ In the above example, both AS1 and AS2 serve as providers to a prefix P. AS1 and AS2 have agreed on a MOAS List, , and each attaches the MOAS List to its route announcement update for P. When AS3 receives the route updates, the MOAS List is ``consistent'' since AS3 only has one MOAS List for prefix P. AS5 will receive two MOAS Lists for prefix P, assuming both AS3 and AS4 propagate the route to P. If the two MOAS List are inconsistent, AS5 should generate an alarm signal to the network operator. 5 Practical Considerations 5.1 Impact of Dropped Community Attribute If the MOAS List for prefix P is dropped along some of the propagation paths due to local policy, aggregation, or improper configuration at some BGP routers, a router further down the road that receive route P announcement may see some of the announcements carrying a MOAS List, and some not. However, all of received MOAS Lists should be consistent. Otherwise, the router should generate an alarm signal. If the router received a route P advertisement that carried no MOAS List and could not find the origin AS on the MOAS List from route P advertisements the router received from other BGP neighbors, the router should generate an alarm signal. On the other hand if the router found origin AS was on the MOAS List from other peers, in this case, the router could consider the MOAS List as consistent, or, the router could generate an alarm signal. The former option is known being vulnerable to some attacks, while Zhao/Mankin/Massey/Pei/Wang/Wu/Zhang Page 4 INTERNET-DRAFT 13 November 2001 the latter option might generate false alarms. A tradeoff should be made according to the local security policy. It is possible that the route to P is a correct one and the MOAS List is incorrect (either due to errors or compromised routers), nevertheless an alarm is an appropriate action to call operator's attention. 5.2 Spoofing Resilience +---+ |---|AS1|\ | +---+ \+---+ P-| |AS3|-- The Internet | +---+ /+---+ |---|AS2|/ +---+ An attacker may try to inject BGP route to a prefix P with an invalid MOAS List. If the origin ASes has only one path to reach the rest of the Internet and the attacker blocked theirs correct route P announcements, shown as in the above example, then the invalid MOAS cannot be easily detected. In this case the attacker has compromised the only path to reach P and can cause other arbitrary damage to P as well. However in more general cases where multiple origin ASes are making route P announcements (as the example in Section 4 shows), or an origin AS announces routes to multiple AS peers, then it is difficult for an attacker to block the correct route P announcement carrying the MOAS List. In this case even though an attacker can still inject invalid route with false MOAS list, other routers can easily detect the MOAS List inconsistency and alarm the network operator. Similarly, an attacker may try to modify the MOAS list on a valid announcement. As long as the attacker can not modify all routes to the origin, the change may result in an alarm. 5.3 Quick Deployment Attaching MOAS List to route announcement requires only BGP configuration changes, but checking MOAS List consistency is more challenging. We propose that BGP implementation should be modified accordingly to incorporate the MOAS List checking as described in this document. However such implementation change may take time to develop. To quickly deploy the MOAS List checking in the operational Internet, Zhao/Mankin/Massey/Pei/Wang/Wu/Zhang Page 5 INTERNET-DRAFT 13 November 2001 one could run an off-line monitoring process which periodically downloads the BGP routing table and check the MOAS List consistency from multiple peers. If the router is equipped to support the new BGP MIB [BGP-MIB2], one could run a management application to access the BGP MIB to get all MOAS List, along with other information, through the MIB interface and check the MOAS List consistency. 5.4 Support four-octets AS number [ASN4] proposes to extend BGP to support four-octets AS number, which may not be easily supported by current BGP Community Attribute. However, [EXT-COM] proposes to extend BGP Community Attribute as well, which could be used by the approach proposed in this draft to support four-octets AS number. 6 Security Consideration Assuming an origin AS has been configured to attach the MOAS List with all its route announcements, when one of its prefixes is falsely originated by either a fault or a compromised AS, other ASes can easily detect an invalid MOAS conflict. The false route announcement either carries an origin AS that is not listed in the correct MOAS List, or carries a MOAS List which is different from the MOAS List generated by the valid origin AS. 7 ICANN Consideration A special value for MLVal should be assigned by ICANN. 8 Acknowledgments The authors would like to thank Randy Bush for discussions and review. 9 References [BGP-4] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP- 4)", RFC 1771, March 1995. Zhao/Mankin/Massey/Pei/Wang/Wu/Zhang Page 6 INTERNET-DRAFT 13 November 2001 [BGP-COM] R. Chandra, P. Traina and T. Li, "BGP Community Attribute", RFC 1997, August 1996. [BGP-AS] J. Hawkinson and T. Bates, "Guidelines for creation, selection, and registration of an Autonomous System (AS)", RFC 1930, March 1996. [MOAS-IMW] X. Zhao, D. Pei, L. Wang, D. Massey, A. Mankin, S. F. Wu, and L. Zhang, "An Analysis of BGP Multiple Origin AS (MOAS) Conflicts", ACM SIGCOMM Internet Measurement Workshop 2001. [ASN4] Q. Vohra and E. Chen, "BGP support for four-octet AS number space", draft-ietf-idr-as4bytes-04.txt [EXT-COM] S. R. Sangli, D. Tappan and Y. Rekhter, "BGP Extended Communities Attribute", draft-ietf-idr-bgp-ext-communities-02.txt [BGP-MIB2] J. Haas, S. Hares, S. Willis and J. Chu, ``Definitions of Managed Objects for the Fourth Version of Border Gateway Protocol (BGP-4)'', draft-ietf-idr-bgp4-mib-07.txt Zhao/Mankin/Massey/Pei/Wang/Wu/Zhang Page 7 INTERNET-DRAFT 13 November 2001 10 Author Information Xiaoliang Zhao NC State University Box 7550, NCSU Centennial Campus Raleigh, NC 27695 Phone: +1 919 513 1894 Allison Mankin USC/ISI Phone: Daniel Massey USC Information Sciences Institute 3811 North Fairfax Drive, Suite 200 Arlington, VA 22203 Dan Pei UCLA Phone: Lan Wang UCLA 4805 Boelter Hall Los Angeles, CA 90095 Phone: 310-825-4838 S. Felix Wu UC Davis Phone: Lixia Zhang UCLA Phone: Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any Zhao/Mankin/Massey/Pei/Wang/Wu/Zhang Page 8 INTERNET-DRAFT 13 November 2001 kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Zhao/Mankin/Massey/Pei/Wang/Wu/Zhang Page 9