SIDR Z. Ye Internet Draft Huawei Technologies Expires: December 1 2007 July 20, 2006 Architecture to Secure Inter-Domain Routing draft-zhao-sidr-architecture-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. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. This document may only be posted in an Internet-Draft. 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 January 20, 2005. Copyright Notice Copyright (C) The Internet Society (2006). All Rights Reserved. Zhao Expires January 20, 2007 [Page 1] Internet-Draft Architecture to Secure Inter-Domain Routing July 2006 Abstract This draft describes an architecture for secure inter-domain routing (BGP [RFC4271]). The architecture consists of components (i.e. functional modules) which address the requirements mentioned in [REQUIREMENT]. The draft describes interfaces (i.e. security services) that the architecture provides to routing engine as well. 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................................................3 1.1. Overview...............................................3 1.2. Traditional Inter-Autonomous Routing System.............3 1.3. Goals of the architecture...............................3 2. Overview of the architecture.................................4 2.1. BGP Routing engine......................................5 2.2. BGP Security Architecture...............................6 2.3. Interface provided to BGP Routing engine................6 3. BGP Security Architecture....................................7 3.1. Payload Security........................................7 3.2. Semantics Security......................................8 3.2.1. Semantics Security of SIDR entities................8 3.2.1.1. AS (autonomous system)........................8 3.2.1.1.1. Entities inside an AS....................8 3.2.1.2. Address Holder................................9 3.2.1.3. Route Object..................................9 3.2.1.3.1. Authenticity of a Prefix.................9 3.2.1.3.2. Authenticity of Attributes...............9 3.2.2. Semantics Security of Entities Relationship........10 3.2.2.1. Relationship about Prefix Authorization.......10 3.2.2.2. Relationship during Transitive of Route Objects11 3.2.2.3. Other Relationship...........................11 3.3. Security Mechanism.....................................11 3.3.1. Certificate Mechanism.............................11 3.3.2. Signed Digital Data Object........................12 3.3.3. Protection Mechanisms of BGP Session..............12 3.3.4. Others...........................................12 3.4. Other Mechanism........................................12 3.4.1. Trust Mechanism...................................12 3.4.2. Transportation and Storage of Security Data........13 Zhao Expires January 20, 2007 [Page 2] Internet-Draft Architecture to Secure Inter-Domain Routing July 2006 4. Security Considerations.....................................13 5. Acknowledgments............................................13 6. References.................................................14 6.1. Normative References...................................14 6.2. Informative References.................................14 Author's Addresses............................................15 Intellectual Property Statement................................15 Disclaimer of Validity........................................15 Copyright Statement...........................................16 Acknowledgment................................................16 1. Introduction 1.1. Overview This document describes an architecture for secure inter-domain routing (BGP [RFC4271]). The architecture consists of components (i.e. functional modules) which address the requirements mentioned in [REQUIREMENT]. The draft describes interfaces (i.e. security services) that the architecture provides to routing engine as well. EDITORS NOTE: This is an early draft. Additional work will be needed. Functional models should be refined and interfaces should be defined as well. 1.2. Traditional Inter-Autonomous Routing System An inter-autonomous routing system can be modeled simply as follow: o ASes (autonomous systems). Each has a single interior routing plan and uses inter-domain routing protocol (BGP) to determine how to route packets to others. o BGP sessions. ASes are interconnected to each other by EBGP session and form a network of ASes. o Route objects. A route object consisting of network reachability information and relevant attributes is transmitted between ASes. In general it is contained in the BGP UPDATE. ASes originate and re-generate route objects and exchange them through established BGP sessions. 1.3. Goals of the architecture 1. The architecture should use existing SIDR (Secure Inter-Domain Routing) solutions as a reference and should be consistent to them mostly. BGP security has been studies during the past decade and a Zhao Expires January 20, 2007 [Page 3] Internet-Draft Architecture to Secure Inter-Domain Routing July 2006 number of solutions have been proposed. Each solution addresses some aspects of the issues, so one important goal of this architecture is consistency to these ideas and different deployment scenarios. 2. Potential requirements must be taken into account. For example, when a new attributes type is introduced in the future, the architecture still can be kept stable. 3. Incremental deployment is a MUST requirement listed in section 3.2 of [REQUIREMENT] and is an architecture requirement as well. A proposed security system MUST be able to coexist with traditional systems (compatible with prior BGP system) and support incremental additions of functional module. 2. Overview of the architecture +-------------------------------------------------------------------+ | BGP Routing engine | | +----------------+ +----------------+ +----------------+ | | | Input | | Route | | Output | | | | Policy | | Selection | | Policy | | | +----------------+ +----------------+ +----------------+ | +---------|----------------------|----------------------|-----------+ | | | V V V +-------------------------------------------------------------------+ | BGP Security Architecture | | +--------------+ +--------------------+ | | | | | Semantics Security | | | | Security | | +----------------+ | | | | Mechanism | | | Entities | | | Zhao Expires January 20, 2007 [Page 4] Internet-Draft Architecture to Secure Inter-Domain Routing July 2006 | | | | | Relationship | | | | +--------------+ | +----------------+ | | | | +----------------+ | | | | | Entities | | | | +--------------+ | | | | | | | | | +----------------+ | | | | Other | +--------------------+ | | | Mechanisms | +--------------------+ | | | | | Payload Security | | | | | | | | | +--------------+ +--------------------+ | +-------------------------------------------------------------------+ Figure 1: Architecture of SIDR The figure above depicts the architecture of BGP security and its relationship with the BGP routing engine. The routing engine invokes the interfaces to obtain security services. 2.1. BGP Routing engine From an implementation point of view, a BGP routing engine consists of three functional modules. Each functional module may be affected by BGP security requirements. o Input Policy. Input policy contains rules to filter route information received from peers. In a SIDR system, input policy may be affected through introducing security rules. o Route Selection. Route selection is a complex procedure to determine a best path to a specific destination. In a SIDR system, security should be considered in this procedure. Zhao Expires January 20, 2007 [Page 5] Internet-Draft Architecture to Secure Inter-Domain Routing July 2006 o Output Policy. Output policy contains rules to determine which routes could be advertised to peers. The output policy may be affected by introduced security rules as well. 2.2. BGP Security Architecture This BGP security architecture includes several components: o Payload Security As mentioned in section 1.3 of [REQUIREMENT], the data payload of the protocol is one primary point where BGP may be secured. "Payload security" functional module serves for this purpose. o Semantics Security This module is used to verify authenticity of entities of BGP system and relationships among them. o Security Mechanism These mechanisms are basic security components which will be invoked by payload and semantics security components. Some standard security protocols such as IPSec, TLS and so on are all included. o Other mechanisms This section describes the mechanisms which will not be invoked directly by the routing engine, but is necessary to SIDR system. Generally, they are not directly correlative with security requirements. These mechanisms may include key management, trust module, transportation and storage of security data. 2.3. Interface provided to BGP Routing engine The architecture provides interfaces through which the routing engine obtains security services. These services include verifying the validation of an entity in BGP system, verifying the relationship between entities, inserting security information into PDUs (Protocol Data Unit), processing security information in received PDUs and so on. Zhao Expires January 20, 2007 [Page 6] Internet-Draft Architecture to Secure Inter-Domain Routing July 2006 NOTE: Such interfaces are not necessarily implemented in one device. For example, [IRV] proposes a solution in which a router consults a dedicated server to verify an UPDATE. 3. BGP Security Architecture The architecture focuses on functional partitioning, which concerns more about what to do. Each component in it is a functional module. [REQUIREMENT] is a guideline and restriction document to implement these functional modules. Section 1.3 of [REQUIREMENT] mentions two primary points in BGP security, the data payload and the data semantics security of the protocol which are all basic components of the architecture. Section 3 of [REQUIREMENT] lists some operational restrictions which could be referenced during designing specific functions. 3.1. Payload Security o Payload Security of a BGP session This module mainly offers services to secure a BGP session between ASes including protecting establishment and closure of a BGP session and transportation of BGP protocol data. These services may include data integrity, anti-replay, data origin authentication, peer entity authentication and so on. Generally, the security services will affect the efficiency of a routing system, which is one restriction when designing this functional module. Requirements in section 3.1 and 3.5 of [REQUIREMENT] should be referenced. A feasible solution may be implemented in different layers, such as the network layer, the transport layer and the application layer. IPSec, TCP MD5 option, TLS are all candidates. [TCPAUTH] proposes a new option to secure a TCP session, which can be regarded as an enhance version of the TCP MD5 option and can provide a integrality service to a BGP session. o Payload Security during the Propagation of an UPDATE Message This module provides security services to protect propagation of a UPDATE Message. For example, an origin AS may sign specific attributes in a UPDATE in order to make other ASes in the AS_PATH to verify whether information has been modified during the transportation. Zhao Expires January 20, 2007 [Page 7] Internet-Draft Architecture to Secure Inter-Domain Routing July 2006 Since this is a BGP problem, relevant services should be provided in the application layer. 3.2. Semantics Security Semantics Security is a central component of the architecture. It focuses on the authenticity of SIDR entities and relationships between them. Whether an AS number is valid is an example of the former. Whether an AS is authorized to originate an address prefix by its address holder is an example of the latter. Current deployment mechanisms, such as route filters, are used to deal with some semantics problems. One example is to filter bogon address prefixes. Another example is to determine whether an origin AS is listed in AS_PATH attribute. Generally, semantics security protects two aspects: authenticity of entities and authenticity of relationships. 3.2.1. Semantics Security of SIDR entities Authenticity of entities is the precondition to validate relationship. There are several top level entities in a SIDR system: ASes, address holders, route objects. NOTE: In current BGP system, ASes trust each other and address holders need not participate. However, in a SIDR system, an address holder needs to authorize ASes to originate its prefix so it is a necessary entity. 3.2.1.1. AS (autonomous system) o the authenticity of an AS An AS number is an identity of an AS. This functional module is used to determine if a specific AS number is valid and to verify related identity claimed by an AS. 3.2.1.1.1. Entities inside an AS An AS is a complicated system and consists of various components, such as ASBR (AS border router), RR (route reflector), PE (provider edge) and so on. Not all BGP entities need to participate in a SIDR system or at least different entities may play different roles. On the one hand route information is originated from inside of an AS such as static route and IGP route, on the other hand Zhao Expires January 20, 2007 [Page 8] Internet-Draft Architecture to Secure Inter-Domain Routing July 2006 misconfigurations and deliberate attacks toward AS are root of problems we faces. Therefore, a complete SIDR system may include components to ensure security inside an AS and should protect AS from advertising invalid UPDATEs. o the authenticity of an ASBR An ASBR (AS border router) is a BGP speaker router which is responsible for advertising route information representing the AS. This functional module is to validate if a speaker has the identity claimed by it. o the authenticity of other entities TBD. 3.2.1.2. Address Holder o the authenticity of an address holder An address holder, such as IANA, RIR, did not appear in the traditional BGP system. Since validation of a prefix and whether an AS is authorized to advertise a prefix are all concerned by SIDR. An address holder is supposed to participate in the SIDR system. This module is to validating if an address holder is a valid holder. 3.2.1.3. Route Object The term "route object" mainly refers to prefixes and related path attributes conveyed in a BGP UPDATE message. 3.2.1.3.1. Authenticity of a Prefix A valid prefix should be an allocated global unicast address. Allocation of IPv4 address space can be consulted from [IANA]. 3.2.1.3.2. Authenticity of Attributes EDITORS NOTE: attributes should be classified in order to be compatible with new attributes. This may be potential work items. o Authenticity of an AS_PATH attribute Validation of AS_PATH is mentioned in section 1.3 of [REQUIREMENT]. The first category summarized in it is whether the AS_PATH actually exists. Since BGP is a path vector protocol and does not maintain a Zhao Expires January 20, 2007 [Page 9] Internet-Draft Architecture to Secure Inter-Domain Routing July 2006 topology, there is not a protocol mechanism to resolve this problem. This functional module focuses on the problem. It is used to check if an AS_PATH is a valid path in the network. NOTE [SoBGP] proposes a topology map to resolve this problem. Existence of an AS path may not mean its validation. A further demand may be a valley-free path, but it is difficult to validate such semantics. o Authenticity of Other path attributes TBD. 3.2.2. Semantics Security of Entities Relationship This section describes relationships between the entities mentioned above. In particular this includes relationships about prefixes authorization and relationship occurring during propagation of route information. 3.2.2.1. Relationship about Prefix Authorization Following table depict potential relationships about prefixes authorization. +--------------+----------------+----------------+------------------+ | | Address Holder | AS | ASBR | +--------------+----------------+----------------+------------------+ | | Authorize to |Authorize to | | |Address Holder| own |originate | N/A | | | | | | +--------------+----------------+----------------+------------------+ | | |Authorize to |Authorize to | | AS | N/A |originate |advertise | | | | | | +--------------+----------------+----------------+------------------+ Zhao Expires January 20, 2007 [Page 10] Internet-Draft Architecture to Secure Inter-Domain Routing July 2006 o Ownership of an Address The ownership of an address is the anchor of subsequent authorization. This functional module is used to verify whether an address holder own specific prefixes. o Prefix Authorization This function module involves several types of authorization as follows: - Is a subordinate address holder authorized to own specific prefixes by an upper address holder? - Is an AS authorized to originate specific prefixes by an address holder or another AS? - Is a router authorized to advertise specific prefixes representing a specific AS? 3.2.2.2. Relationship during Transitive of Route Objects Since route processing is a per-hop based behavior, except for immediate ASes, a receiver could not tell which AS an UPDATE has arrived at. o Authenticity of AS_PATH Travel. This function is used to verify whether the UPDATE has actually traveled the ASes listed in AS_PATH. 3.2.2.3. Other Relationship o Relationship between ASes Do two ASes really interconnect each other? 3.3. Security Mechanism 3.3.1. Certificate Mechanism In this document, a certificate means a public-key certificate which binds a public/private key pair to a specific subject. It may also include extensions about the subject. Zhao Expires January 20, 2007 [Page 11] Internet-Draft Architecture to Secure Inter-Domain Routing July 2006 In SIDR system, a certificate mechanism serves for identity authentication, data integrality validation and prefix authorization. NOTE: Generally lifetime of a subject is longer than validity period of authorization, so it may be not adequate to convey a short-term authorization in a public-key certificate. 3.3.2. Signed Digital Data Object A signed digital data object is used to convey authorizations and policies to specific subjects and is protected by a digital signature. For example, it can be used to verify whether an AS is authorized to advertise a block of address space. 3.3.3. Protection Mechanisms of BGP Session Mechanisms to protecting BGP sessions serve for payload security, which may include data integrity, anti-replay, peer authentication, etc. Some standardized security protocols provide these mechanisms, such as IPSec, TLS. [TCPAUTH] proposes a lightweight solution to provide an integrality service to a TCP session. 3.3.4. Others TBD. 3.4. Other Mechanism 3.4.1. Trust Mechanism +-------------------------------------+ | trust mechanism | | +-------------+ +-------------+ | | | underlying | | underlying | | | | trust model | | trust model | | | +-------------+ +-------------+ | +-------------------------------------+ Zhao Expires January 20, 2007 [Page 12] Internet-Draft Architecture to Secure Inter-Domain Routing July 2006 With regard to trust models in SIDR systems, there are two issues involved. One is which type of underlying trust model to choose. The other is how to cooperate with a SIDR system which has a different trust model. The former is a business issue which depends on practical requirements. The latter is an unsolved technical issue. Section 5 of [REQUIREMENT] mentions some requirements about the trust model. From the point of view of this architecture, an underlying trust model should be transparent to the routing engineer. 3.4.2. Transportation and Storage of Security Data TBD. 4. Security Considerations Security is the subject matter of this entire document. 5. Acknowledgments The authors gratefully acknowledge the contributions of: o tbd, xxx, yyy, ... o We would like to thank Miao Fuyou and Hui Liu for their helpful comments and suggestions. o This listing is intended to acknowledge contributions, not to imply that the individual or organizations approve the content of this document. o Apologies to those who commented on/contributed to the document and were not listed. Zhao Expires January 20, 2007 [Page 13] Internet-Draft Architecture to Secure Inter-Domain Routing July 2006 6. References 6.1. Normative References [RFC4271] Y. Rekhter, T. Li, S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [IPSec] S. Kent, K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. 6.2. Informative References [REQUIREMENT] B. Christian, T. Tauber, "BGP Security Requirements", draft-ietf-rpsec-bgpsecrec-05, April 2006. [RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, May 2000. [IRV] Geoffrey Goodell, William Aiello, Timothy Griffin, John Ioannidis, Patrick McDaniel, Aviel Rubin, "Working Around BGP: An Incremental Approach to Improving Security and Accuracy of Interdomain Routing". [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. [TCPAUTH] R. Bonica, B. Weis, S. Viswanathan, A. Lange, O. Wheeler, "Authentication for TCP-based Routing and Management Protocols", draft-bonica-tcp-auth-04.txt, February 2006. Zhao Expires January 20, 2007 [Page 14] Internet-Draft Architecture to Secure Inter-Domain Routing July 2006 Author's Addresses Zhao Ye Huawei Technologies No.3, Xinxi Road, Shangdi Information Industry Base Haidian District, Beijing City P.R. China 100085 Phone: 86-10-5849 1057 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 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Zhao Expires January 20, 2007 [Page 15] Internet-Draft Architecture to Secure Inter-Domain Routing July 2006 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. Zhao Expires January 20, 2007 [Page 16]