Network Working Group M. Behringer Internet-Draft Cisco Systems Inc Intended status: Informational July 10, 2008 Expires: January 11, 2009 BGP Session Security Requirements draft-ietf-rpsec-bgp-session-sec-req-01.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 January 11, 2009. Abstract The document "BGP security requirements" (draft-ietf-rpsec-bgpsecrec) specifies general security requirements for BGP. However, specific security requirements for single BGP sessions, i.e., the connection between two BGP peers, are only touched on briefly in the section "transport layer protection". This document expands on this particular aspect of BGP security, defining the security requirements between two BGP peers. Behringer Expires January 11, 2009 [Page 1] Internet-Draft BGP Session Security Requirements July 2008 Table of Contents 1. Introduction and Problem Statement . . . . . . . . . . . . . . 3 2. The Threat Model . . . . . . . . . . . . . . . . . . . . . . . 4 3. BGP Session Security Requirements . . . . . . . . . . . . . . 5 3.1. BGP Speaker Identity . . . . . . . . . . . . . . . . . . . 5 3.2. Peer Authentication . . . . . . . . . . . . . . . . . . . 6 3.3. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 6 3.4. Confidentiality . . . . . . . . . . . . . . . . . . . . . 6 3.5. Anti-Replay . . . . . . . . . . . . . . . . . . . . . . . 7 3.6. Availability and Restricting IP Reachability . . . . . . . 7 3.7. Key Management and Operational Considerations . . . . . . 7 3.8. Logging and Alerting . . . . . . . . . . . . . . . . . . . 8 3.9. General Considerations . . . . . . . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Normative References . . . . . . . . . . . . . . . . . . . 9 6.2. Informative References . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Behringer Expires January 11, 2009 [Page 2] Internet-Draft BGP Session Security Requirements July 2008 1. Introduction and Problem Statement The document "BGP security requirements" [I-D.ietf-rpsec-bgpsecrec] specifies general security requirements for BGP. However, specific security requirements for single BGP sessions, i.e., the connection between two BGP peers, are only touched on briefly in the section "transport layer protection". This document expands on this particular aspect of BGP security, defining the security requirements between two BGP peers. It is important to note that security requirements between BGP peers are not limited to the BGP protocol itself or a particular layer of the OSI stack. Crafted ICMP messages for example may have an impact on an established BGP session: An ICMP port unreachable, referring to the BGP port on the peer router, would tear down the BGP session, if no additional security measures are taken to prevent this. A similar effect can be achieved with ICMP source quench messages. Some of the mechanims currently employed to secure a BGP session are on the TCP layer (e.g., MD5), some on the IP layer (e.g., GTSM). This document provides an overall, practical view on the security requirements for BGP sessions, not limited to the BGP protocol. Previous work in this area includes most notably the following documents: o "Protection of BGP Sessions via the TCP MD5 Signature Option" [RFC2385] o "Key Management Considerations for the TCP MD5 Signature Option" [RFC3562] o "Key Change Strategies for TCP-MD5" [RFC4808] o "The Generalized TTL Security Mechanism (GTSM)" [RFC5082] o "Problem Statement and Requirements for a TCP Authentication Option" [I-D.bellovin-tcpsec] o "The TCP Authentication Option" [I-D.ietf-tcpm-tcp-auth-opt]. o "BGP Security Requirements" [I-D.ietf-rpsec-bgpsecrec] o "Generic Security Requirements for Routing Protocols" [I-D.ietf-rpsec-generic-requirements] o "An Attack Tree for the Border Gateway Protocol" [I-D.ietf-rpsec-bgpattack] o "Automated key selection extension for the TCP Enhanced Authentication Option" [I-D.weis-tcp-auth-auto-ks] o "Backbone Infrastructure Attacks and Protections" [I-D.savola-rtgwg-backbone-attacks] Current implementations of BGP include a combination of some of these mechanisms. However, while the security level achieved with these is probably currently acceptable for most providers, they pose some operational challenges which limit the effectiveness of BGP point to point security. Current problems with BGP session security (between Behringer Expires January 11, 2009 [Page 3] Internet-Draft BGP Session Security Requirements July 2008 BGP peers) include: o The use of static keys, which tend to be changed infrequently, and often not at all. [RFC3562] states that keys SHOULD be changed at least every 90 days. However, the relative complexity of changing MD5 keys on all BGP peering sessions, specifically when securing sessions to routers maintained by two different organisations, means that keys are often not changed at all. This makes long term brute force attacks feasible. o The key change process needs to be coordinated between both sides of the BGP session, making this an operationally expensive exercise. o The keys are typically chosen by humans, and expressed in ASCII; therefore, the entropy is typically small, making the keys easier to guess. [RFC3562] outlines this problem. o Dependence on the MD5 algorithm, which brings two problems: MD5 is not considered strong enough for the future. ([RFC4278] states that "the IESG believes that [RFC2385], though adequate for BGP deployments at this moment, is not strong enough for general use".) And, security architectures should also allow a choice of algorithms, to have an alternative in case serious vulnerabilities are discobered in an algorithm. o Where confidentiality of BGP routing information is required, this can only be achieved today by securing the BGP session with IPsec. Other ways to provide confidentiality may be required in the future. This document lists the requirements for BGP session security, with the goal to provide a guideline for flexible, operationally manageable, and secure algorithms for BGP session protection. The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119]. 2. The Threat Model The threat model presented here is based on the document "Generic Threats to Routing Protocols" [RFC4593], which explains generic threats to routing protocols. That document provides a categorization and classification of threat sources, threat actions, threat consequences, threat consequence zones, and threat consequence periods. Security threats to point to point BGP sessions can be classified with the following parameters: Behringer Expires January 11, 2009 [Page 4] Internet-Draft BGP Session Security Requirements July 2008 o Threat source: Any host in the Internet that can reach one of the BGP peers. (By using The Generalized TTL Security Mechanism (GTSM) [RFC5082] the threat source must be within the configured IP hop count, in the ideal case directly connected.) A threat source can also be a wire tap agent, either passively listening to the BGP session, or actively modifying BGP data in transit. o Threat action: Sending of forged BGP packets, or sniffing BGP traffic. o Threat consequence: Break of confidentiality by wire tapping, break of integrity by faking BGP messages or hijacking a session, or denial of service, for example by sending fake RST packets, terminating a BGP session abnormally. o Threat consequence zones: The BGP peering session itself, the BGP tables on the affected peers, or potentially larger areas of the BGP routing system. o Threat consequence period: Depending on the attack and the implemented counter measures, a threat might be preliminarily mitigated by changing the MD5 key, unless it is a threat against MD5 itself, in which case the threat period is indefinite. Threats not considered in this document include: o Attacks from legitimate BGP speakers, in other words, attacks from other BGP speakers, which are trusted (implicitly or explicitly). The source of the attack in this case could be either a misconfiguration, or an attacker gaining illegitimate access to a router, for example through SSH brute force attacks. The document "Backbone Infrastructure Attacks and Protections" [I-D.savola-rtgwg-backbone-attacks] describes general attack forms against backbones, not limited to the BGP protocol. It provides useful background information to this threat model. 3. BGP Session Security Requirements 3.1. BGP Speaker Identity A BGP speaker MUST have a unique identity to present to its peer. This serves as a base for subsequent security mechanisms, such as peer authentication. At this moment this identity is tied to the IP address used for the BGP peering session. This address can be either the IP address of a loopback interface, or a physical interface. Any point to point security mechanism for BGP MUST refer to and use a specific BGP ID. This ID MUST be unique for the BGP peers, it SHOULD be unique within an autonomous system, and it MAY be globally unique. A BGP speaker SHOULD be capable of using different IDs to different Behringer Expires January 11, 2009 [Page 5] Internet-Draft BGP Session Security Requirements July 2008 peers, because a single router identity (the same ID for all peers) may not be sufficient from an operational point of view. For example internally a provider may want to use address space which should not be seen from or accessible to the outside of his network. Alternatively, a provider who uses private address space [RFC1918] inside his network for iBGP sessions, may want to use public address space for eBGP sessions on the same router. Although currently the IP address used for the BGP peering is used as an identifier, it is entirely possible to use an alternative BGP ID, for example based on public/private key pairs, or the HIP architecture [RFC4423]. The document "AS-wide Unique BGP Identifier for BGP-4" [I-D.ietf-idr-bgp-identifier] for example proposes a 4-byte unsigned, non-zero integer as an identity, which should be unique in the autonomous system. Note that this document does not mandate or recommend the use of a particular type of BGP ID, nor does it discuss the differences between the various approaches. It only specifies the generic requirements for BGP IDs. 3.2. Peer Authentication A BGP speaker MUST have a way to authenticate messages from its peer. Currently this is achieved by [RFC2385] derived mechanisms, however, several alternatives are conceivable and partly under discussion, for example [I-D.ietf-tcpm-tcp-auth-opt]. Also IPsec [RFC4301] provides peer authentication, as does TLS [RFC4346] or SSH [RFC4251]. (Note: Key management is discussed below.) 3.3. Integrity A BGP speaker MUST have methods to ensure integrity of messages in transit, to avoid insertion of fake messages in the transport layer. This requirement is currently addressed by RFC 2385-derived mechanisms. However, new methods should avoid the operational issues mentioned in the introduction of that RFC. It MUST be possible to use various algorithms, either statically by specifying the algorithms used for integrity services, or by dynamic negotiation. (Note: Key management is discussed below.) 3.4. Confidentiality A BGP speaker MAY have mechanisms to encrypt BGP messages in transit, thus providing confidentiality. This service is rarely used today, but since BGP is used increasingly for more applications, amongst which for example signaling security measures, it is conceivable that the need for confidentiality for BGP sessions will increase. If Behringer Expires January 11, 2009 [Page 6] Internet-Draft BGP Session Security Requirements July 2008 confidentiality services are provided, they MUST allow for different crypto algorithms, and negotiation of which algorithm to use. (Note: Key management is discussed below.) 3.5. Anti-Replay A BGP speaker MUST have methods to detect and prevent replay of messages, to avoid for example an attacker saving a session reset message, and replaying it later, to produce a denial of service attack. 3.6. Availability and Restricting IP Reachability A BGP speaker SHOULD have mechanisms to protect the BGP session against denial of service attacks, targeting the availability of the BGP session. More specifically, a BGP speaker SHOULD have mechanisms to drop non-session packets efficiently (with minimum CPU impact, specifically before any crypto operations). This includes access control lists (ACL) on layer 3/4 and possibly layer 2, providing easy protection against some forms of attack. It also includes TTL based mechanisms such as proposed in [RFC5082]. Any reachability restriction of these types MUST be carried out before more CPU intensive tasks such as crypto operations, to be effective against denial of service attacks. Fragmentation attacks can bypass layer 4 ACLs, by fragmenting packets in a way that no fragment is recognized by the ACL. (Note that layer 4 ACLs still provide operationally useful filtering, and should therefore be supported.) Fragmentation cannot occur on a single-hop BGP session, therefore a BGP speaker MUST have the capability to drop fragments on a single-hop BGP session. On multi-hop BGP sessions fragmentation should not occur, if the network has been correctly designed, therefore a BGP speaker SHOULD also be capable of dropping fragements on a multi-hop BGP session. Also on other, related, protocols fragmentation needs to be specially considered, since it can bypass some forms of ACLs. The document "Service Provider Infrastructure Security" [I-D.ietf-opsec-infrastructure-security] provides an overview of best practices regarding infrastructure protection, and is useful background material. 3.7. Key Management and Operational Considerations Some of the requirements above may, in turn, require mechanisms that employ shared keys between the BGP peers. Currently, statically- defined and manually configured keys are used for this purpose. [RFC3562] explains possible shortcomings of such keys, and gives Behringer Expires January 11, 2009 [Page 7] Internet-Draft BGP Session Security Requirements July 2008 recommendations to improve security. Key selection is also discussed in [I-D.weis-tcp-auth-auto-ks], as an extension to [I-D.ietf-tcpm-tcp-auth-opt]. For any new mechanism aimed at securing BGP sessions it is highly desirable to use automated key generation and negotiation mechanisms, based on the BGP speaker identity. Mechanisms based on key lists with defined life times for keys, for example as defined by the document "Authentication-Key Rollover mechanism for Routing and Management Protocols" [I-D.viswanathan-keyrollover] may be acceptable if there are good reasons to avoid automated key negotiation. 3.8. Logging and Alerting To be able to detect attempts of security breaks, BGP speakers MUST have be able to produce related alerts or logging messages. General considerations to logging apply here: There should be summarization of events, to avoid for example a message to be sent for each packet that is not authenticated. When available, secure syslog should be used to guarantee delivery of those messages to the management center. 3.9. General Considerations For many of the above mentioned security requirements there are a vast range of protocol and implementation options, with varying degrees of effective security. While strong security is desirable, there are several considerations to be taken into account for a BGP implementation: o Efficient use of system resources: Stronger security mechanisms may require more system resources (CPU, memory, bandwidth) than more light-weight versions, or the unprotected BGP protocol. A security mechanism may lead to an excessively higher exposure to denial of service attacks than the unprotected protocol, or another security mechanims.When considering security mechanisms, the "cost" in terms of system resources should be taken into account. o Ease of configuration: Complicated configurations increase the likelihood for misconfigurations, with potential security vulnerabilities. BGP security mechanisms should therefore be easy to configure, where "easy" referes to both the length of the configuration, as well as the complexity of it. Both efficient use of system resources and ease of configuration cannot be judged on their own, but rather represent additional variables to judge an overall BGP security implementation. In other Behringer Expires January 11, 2009 [Page 8] Internet-Draft BGP Session Security Requirements July 2008 words, a highly secure, but also highly complex and resource- consuming solution may be less preferrable over a somewhat less secure but simple and light-weight solution. This has to be decided case-by-case. 4. Security Considerations This document is entirely about security requirements for BGP point- to-point connections. No new security exposures are created by this document. 5. Acknowledgements The author would like to thank Russ White, Alvaro Retana, Brian Weis, Carlos Pignataro, Stephen Kent, and Joe Touch for their feedback and support. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 6.2. Informative References [I-D.bellovin-tcpsec] Bellovin, S., "Problem Statement and Requirements for a TCP Authentication Option", draft-bellovin-tcpsec-01 (work in progress), July 2007. [I-D.ietf-idr-bgp-identifier] Chen, E. and J. Yuan, "AS-wide Unique BGP Identifier for BGP-4", draft-ietf-idr-bgp-identifier-09 (work in progress), May 2008. [I-D.ietf-opsec-infrastructure-security] Lewis, D., "Service Provider Infrastructure Security", draft-ietf-opsec-infrastructure-security-01 (work in progress), April 2007. [I-D.ietf-rpsec-bgpattack] Convery, S., "An Attack Tree for the Border Gateway Protocol", draft-ietf-rpsec-bgpattack-00 (work in progress), April 2004. Behringer Expires January 11, 2009 [Page 9] Internet-Draft BGP Session Security Requirements July 2008 [I-D.ietf-rpsec-bgpsecrec] Christian, B. and T. Tauber, "BGP Security Requirements", draft-ietf-rpsec-bgpsecrec-09 (work in progress), November 2007. [I-D.ietf-rpsec-generic-requirements] McPherson, D., "Generic Security Requirements for Routing Protocols", draft-ietf-rpsec-generic-requirements-01 (work in progress), January 2005. [I-D.ietf-tcpm-tcp-auth-opt] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", draft-ietf-tcpm-tcp-auth-opt-00 (work in progress), November 2007. [I-D.savola-rtgwg-backbone-attacks] Savola, P., "Backbone Infrastructure Attacks and Protections", draft-savola-rtgwg-backbone-attacks-03 (work in progress), January 2007. [I-D.viswanathan-keyrollover] Viswanathan, S., "Authentication-Key Rollover mechanism for Routing and Management Protocols", draft-viswanathan-keyrollover-00 (work in progress), October 2006. [I-D.weis-tcp-auth-auto-ks] Weis, B., Appanna, C., McGrew, D., and A. Ramaiah, "Automated key selection extension for the TCP Enhanced Authentication Option", draft-weis-tcp-auth-auto-ks-03 (work in progress), October 2007. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998. [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 Signature Option", RFC 3562, July 2003. [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006. [RFC4278] Bellovin, S. and A. Zinin, "Standards Maturity Variance Regarding the TCP MD5 Signature Option (RFC 2385) and the BGP-4 Specification", RFC 4278, January 2006. Behringer Expires January 11, 2009 [Page 10] Internet-Draft BGP Session Security Requirements July 2008 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006. [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006. [RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", RFC 4593, October 2006. [RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5", RFC 4808, March 2007. [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, October 2007. Author's Address Michael H. Behringer Cisco Systems Inc Village d'Entreprises Green Side 400, Avenue Roumanille, Batiment T 3 Biot - Sophia Antipolis 06410 France Email: mbehring@cisco.com URI: http://www.cisco.com Behringer Expires January 11, 2009 [Page 11] Internet-Draft BGP Session Security Requirements July 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Behringer Expires January 11, 2009 [Page 12]