SIDR Working Group Dai GuangMing Internet Draft Z. Ye Expires: March 2007 Huawei Technologies FEKI Ines France Telecom September 25, 2006 BGP UPDATE Advertisement Restriction draft-dai-sidr-bgp-advertisement-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 25, 2007. Copyright Notice Copyright (C) The Internet Society (2006). All Rights Reserved. Abstract SIDR working group is working on an extended architecture for interdomain routing security framework. One of the functions that this architecture should provide is origin authentication of prefixes for BGP, i.e. a BGP speaker must be able to determine whether an AS (autonomous system) is authorized to originate certain prefixes. This draft documents some ideas from the perspective of internal control in order to alleviate this problem. Dai Expires March 25, 2007 [Page 1] Internet-Draft BGP UPDATE Advertisement Restriction September 2006 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119] Table of Contents 1. Introduction................................................2 1.1. Problem Description.....................................2 1.2. Existing solutions......................................3 1.3. Internal control ideas..................................3 1.4. Proposed solution.......................................3 2. Threat Model................................................3 3. Solution....................................................4 3.1. Framework..............................................5 3.2. Operation..............................................5 3.2.1. Policy maintaining.................................5 3.2.2. Policy deployment..................................5 3.2.3. Violation Response.................................6 4. Future Work...................................................7 5. Security Considerations......................................7 6. Acknowledgements............................................7 7. References..................................................7 7.1. Normative References....................................7 7.2. Informative References..................................8 Author's Addresses.............................................9 Intellectual Property Statement.................................9 Disclaimer of Validity.........................................9 Copyright Statement...........................................10 Acknowledgment................................................10 1. Introduction 1.1. Problem Description It has been observed that BGP is vulnerable to several types of attacks (refer to [VULN]). Because of lacking inherent security mechanisms, a UPDATE message receiver can not tell whether the origin AS listed in AS_PATH is authorized to originate the prefixes. Because of misconfiguration or deliberate attacks, wrong prefixes may be propagated through UPDATE messages which may cause traffic redirection, black hole and some other problems. Dai Expires March 25, 2007 [Page 2] Internet-Draft BGP UPDATE Advertisement Restriction September 2006 1.2. Existing solutions [SBGP] proposes an autonomous system numbers and prefix allocation based PKI to provide an authentication infrastructure to solve this problem. [SoBGP] solves it in a similar ways except that it uses web-of-trust model for AS identity authentication. [IRR] is a global distributed database where routing information is stored . The purpose is to ensure stability and consistency of the Internet-wide routing. One can consult the database to obtain the origin AS of a prefix. 1.3. Internal control ideas Some research projects have focused on internal control of an AS. [RCC] is a configuration analysis tool. Network operators can use it to verify whether network configurations satisfy a prior anticipation. [RCP] offers a proposal which introduces a routing control plane and mainly focuses on internal problems within an AS, such as protocol oscillation, forwarding loops, blackholes and so on. 1.4. Proposed solution This draft proposes a solution to alleviate the problem. Since the root cause of the problem is mistake on advertisements, it is necessary to check the outbound advertisements besides of validating received UPDATE. This draft proposes methods to make sure that origin of routes is consistent with the anticipated configuration. This solution is not brand-new, but it is low cost and incrementally deployable. The solution can be applied alone or be part of a future total solution about BGP security. When an AS has too limited resource to support an expensive security mechanism, this proposal may also be beneficial. 2. Threat Model Basically, the threat will occur in following two situations. 1 In a deliberate attack situation An attacker may intercept BGP protocol traffic and modify the information of the traffic. Authentication mechanism can counter the Dai Expires March 25, 2007 [Page 3] Internet-Draft BGP UPDATE Advertisement Restriction September 2006 attack of this type, and [IPsec], [TLS] or [TCPMD5] can be applied to provide such authentication. An attacker may also compromise a BGP border router and advertises vicious prefixes through it. 2 In a misconfiguration situation BGP provides no inherent measure to control or monitor route advertisements. Misconfigurations will not be checked or trigger any alarm either. With the size of the AS growing, manual configuration may increase the probability of configuration error. In many known problems, the wrong prefixes have been advertised were mainly caused by misconfiguration. Deliberate attacks are similar to misconfiguration and attacks were reported relatively rarely. A number of reasons (for example, the complexity of network and its configuration, manual configuration and absence of unified bound to apply AS-level strategy) leads to the fact that the actual network operation is not consistent with the anticipation. 3. Solution The proposal suggests mechanisms to avoid advertising a wrong message from the inside of an AS and to avoid the mistake in the first place. The main obstacles [IRR] faces are how to keep the database up-to- date and complete, which limit its use. Conversely, for an AS the range of prefixes that originate from it is a prior knowledge. Therefore, it is possible to validate and restrict the advertisement behavior of the AS. Technically, attacks caused by compromised device are similar to those by misconfiguration, so the solution is also effective to mitigate such attacks. This solution can be incrementally deployed. Prefixes originating from AS are filtered inside of the AS and EBGP sessions between ASes will not be affected. Besides, received advertisements are also filtered on the basis of a legitimacy level associated with an AS. It is considered as its legitimacy to originate prefixes. This level is inferred from IRR and received advertisements. This solution is compatible with [SBGP] and [SoBGP]. Introduced infrastructure in these proposals, such as PKI, can be used to provide trust, when restricting advertised prefixes. Dai Expires March 25, 2007 [Page 4] Internet-Draft BGP UPDATE Advertisement Restriction September 2006 3.1. Framework +-------+ ------> +-------+ | | (policy) | | | PS |---------- | RA | | | <------ | | +-------+ (alarm) +-------+ Figure 1: System Architecture Figure 1 is the framework of the system. RA is a border router in a single AS and PS is a policy station in that AS. One task of PS is to maintain a uniform advertising policy and to deploy the policy inside the whole AS. Another task is to collect alarms of inconsistent behavior from border routers inside the AS. As a border router, such as RA in figure 1, before prefixes being advertised out of the AS, they should check them against the policy to determine whether the prefixes are consistent with the policy. 3.2. Operation 3.2.1. Policy maintaining A policy station in an AS is responsible for maintaining a prefixes advertisement policy. A policy station could be a dedicated host or a router who has implemented additional functions of policy maintaining. Conceptually a policy defines the range of prefixes which originate from the AS. The policy may be established by manual configuration or introduced into an AS through some external mechanism. For example, for the address PKI proposed by [SBGP], the policy may be introduced by utilizing Address Attestation (AA). In any case, the most important thing is to ensure the accuracy of the range of prefixes, i.e. to ensure the advertised prefixes originating from some AS is properly authorized. 3.2.2. Policy deployment There are two types of deployment model according to participation of a router. Dai Expires March 25, 2007 [Page 5] Internet-Draft BGP UPDATE Advertisement Restriction September 2006 o Distributed deployment model In this scenario, the advertisement policy should be deployed in every BGP speaker in an AS. A policy station could use a BGP-based mechanism to distribute the policy, such as a new type of BGP message or some technology similar to [ORF]. The policy could also be distributed in an "out-of-band" channel. In this model, border routers are responsible for the policy execution. The policy may be implemented with some filtering mechanisms. Before distributing static or IGP routes into RIB of BGP, the routes should be checked. Since the policy is deployed inside an AS, transport security of the policy may not be a serious problem. It is important to keep policy deployment reliable and on time. o Centralized deployment model In this model, border routers need not execute security policies. A policy station can make use of IBGP, as mentioned in [RCP], to obtain advertised routes and check them against the deployed policy. In this way, the policy station is able to determine whether a route is consistent with the policy. If not, it triggers an alarm to a management system. Because a policy check occurs at a single host, a policy station is supposed to keep online and analyze the alteration of routes in time. 3.2.3. Violation Response When local routes violate the deployed policy, there are two kind of possible measures to be taken: o A loose measure If a router uses a loose measure, violating routes will still be advertised. However, an event should be reported to a management system immediately, so an administrator could perform a proper counter measure in time. o A strict measure If a router uses a strict measure, violating routes will be filtered and will not be spread out of the AS. This is an active measure and can prevent false route from being advertised, which may be caused by misconfiguration. Dai Expires March 25, 2007 [Page 6] Internet-Draft BGP UPDATE Advertisement Restriction September 2006 If this security measure is implemented as a mandatory option, attacks made by a compromised router may also be detected. 4. Future Work This application framework is more fit for BGP stub ASes which do not provide transitive services and for the ASes whose devices are with limited resource. As to upper ASes, frequent changes of internet route must be considered. In such situation, a policy station is supposed to know these changes, so it should be [s|so|ps]BGP-aware and could get credible routing and authorization information from outside security systems. Furthermore, the policy station could be enhanced to process more complicated semantic validation, such as AS_PATH validation. To sum up, in this framework only a few devices in an AS are required to participate in security validation. In this way most BGP router could meet security requirements without update hardware. 5. Security Considerations This draft focuses on preventing sending and receiving BGP false advertisements incurred by misconfiguration. Since attack may also be a potential cause of the problem, the proposal is a security mechanism for BGP in the same time. A policy station is the key element of the solution. Since it is located in the domain of an AS, launching an attack toward it may be difficult. If strict security requirements are needed, operators may take more strict access control to the policy station. 6. Acknowledgements 7. References 7.1. Normative References [RFC1208] Jacobsen, O. and D. Lynch, "Glossary of networking terms", RFC 1208, March 1991. [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995. Dai Expires March 25, 2007 [Page 7] Internet-Draft BGP UPDATE Advertisement Restriction September 2006 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate equirement Levels", BCP 14, RFC 2119, March 1997. [BGP] Y. Rekhter, T. Li, S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [IPsec] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [TLS] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [TCPMD5] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998. 7.2. Informative References [VULN] S. Murphy, "BGP Security Vulnerabilities Analysis", RFC 4272, January 2006. [SBGP] Charles Lynn, Joanne Mikkelson, Karen Seo, "Secure BGP (S- BGP)", draft-clynn-s-bgp-protocol-01.txt, June 2003. [SoBGP] R. White, "Architecture and Deployment Considerations for Secure Origin BGP (soBGP)", draft-white-sobgp-architecture-01.txt, May 24, 2005. [IRR] "Internet Routing Registry", http://www.irr.net. [RCC] MIT, "Routing Configuration Checker", http://nms.lcs.mit.edu/bgp/rcc/#status. [RCP] Matthew Caesar, Donald Caldwell, Nick Feamster, Jennifer Rexford, Aman Shaikh, Jacobus van der Merwe, "Design and Implementation of a Routing Control Platform". [ORF] Enke Chen, Yakov Rekhter, "Cooperative Route Filtering Capability for BGP-4", draft-ietf-idr-route-filter-13.txt. Dai Expires March 25, 2007 [Page 8] Internet-Draft BGP UPDATE Advertisement Restriction September 2006 Author's Addresses Dai Guangming Huawei Technologies No.3, Xinxi Road, Shangdi Information Industry Base Haidian District, Beijing City 100085 Email: daigm@huawei.com Zhao Ye Huawei Technologies No.3, Xinxi Road, Shangdi Information Industry Base Haidian District, Beijing City 100085 Email: yezhao@huawei.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE Dai Expires March 25, 2007 [Page 9] Internet-Draft BGP UPDATE Advertisement Restriction September 2006 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Dai Expires March 25, 2007 [Page 10]