Network Working Group M. Behringer Internet-Draft Cisco Intended status: Informational February 23, 2007 Expires: August 27, 2007 BGP Session Security Requirements draft-behringer-bgp-session-sec-req-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 August 27, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract The document "BGP security requirements" (draft-ietf-rpsec-bgpsecrec-07) 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 August 27, 2007 [Page 1] Internet-Draft BGP Session Security Requirements February 2007 Context of this document: RPSEC WG; Charter item: "Document security requirements for routing systems". 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 . . . . . . . . . . . . . . . . . . . . 5 3.3. Confidentiality . . . . . . . . . . . . . . . . . . . . . . 5 3.4. Integrity . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.5. Anti-Replay . . . . . . . . . . . . . . . . . . . . . . . . 6 3.6. Availability and Restricting IP Reachability . . . . . . . 6 3.7. Key Management and Operational Considerations . . . . . . . 6 3.8. Logging and Alerting . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Normative References . . . . . . . . . . . . . . . . . . . 7 6.2. Informative References . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . . . 8 Behringer Expires August 27, 2007 [Page 2] Internet-Draft BGP Session Security Requirements February 2007 1. Introduction and Problem Statement The document "BGP security requirements" (draft-ietf-rpsec-bgpsecrec-07) 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. Note that security requirements between BGP peers are not limited to a particular layer of the OSI stack. To achieve a good level of security, implementations are likely to include mechanisms based on several layers of the OSI stack. Previous work in this area includes most notably the following documents: o RFC 2385 - Protection of BGP Sessions via the TCP MD5 Signature Option o RFC 3682 - The Generalized TTL Security Mechanism (GTSM) o RFC 3562 - Key Management Considerations for the TCP MD5 Signature Option o "Key Change Strategies for TCP-MD5" (draft-bellovin-keyroll2385-04) o "Authentication for TCP-based Routing and Management Protocols" (draft-bonica-tcp-auth-06) Current implementations of BGP include a combination 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 BGP peers) include: o The use of static keys, which tend to be changed infrequently, and often not at all. RFC 3562 [insert ref] states that keys SHOULD be changed at least every 90 days. However, the relative complexity of chaining MD5 keys on all BGP peerings, specifically where third parties are involved, 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 peering, making this an operationally expensive exercise. o The keys are typically chosen by humans, and in ASCII code; therefore, the entropy is typically small, making the keys easier to guess. [ref: RFC 3562] Behringer Expires August 27, 2007 [Page 3] Internet-Draft BGP Session Security Requirements February 2007 o Dependence on the MD5 algorithm, which brings two problems: MD5 is not considered strong enough for the future [insert ref]. And, security architectures should also allow a choice of algorithms [insert ref]. 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 desirable. 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. 2. The Threat Model The threat model presented here is based on RFC4593 [insert ref], which explains generic threats to routing protocols. This 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: o Threat source: Any host in the Internet which can reach one of the BGP peers. By using RFC3682 [insert ref] the threat source must be within the configured IP hop count, in the ideal case directly connected. o Threat action: Sending of forged BGP packets. o Threat consequence: Denial of service, for example by sending fake RST packets, intrusion by sending fake BGP update messages, or session hijacking. 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. o Other forms of attack against routers, such as denial of service attacks against other services of the router, or against the ingress interface. Behringer Expires August 27, 2007 [Page 4] Internet-Draft BGP Session Security Requirements February 2007 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, presenting a globally unique ID. 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. Note that a router based identity may not be sufficient for this purpose, since different identities may be used, for example an internal ID for iBGP sessions, and an external one for eBGP sessions. Therefore, it might be necessary to assign different identities to different BGP sessions. (Is this true? - need to think more about this) 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 (RFC 4423). draft-ietf-idr-bgp-identifier-08 [insert ref] for example proposes a 4-byte unsigned, non-zero integer as an identity, which should be unique in the autonomous system. 3.2. Peer Authentication A BGP speaker MUST have a way to authenticate messages from its peer. Currently this is achieved by RFC 2385 derived mechanisms, however, several alternatives are conceivable and partly under discussion, for example draft-bonica-tcp-auth-06. Also IPsec [insert ref] provides peer authentication, as does TLS [insert ref] or SSH [insert ref]. To avoid overloading system resources, the method used SHOULD be light weight. 3.3. 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 signalling security measures, it is conceivable that the need for confidentiality for BGP sessions will increase. If confidentiality services are provided, they SHOULD allow for different crypto algorithms, and negotiation of which algorithm to use. Behringer Expires August 27, 2007 [Page 5] Internet-Draft BGP Session Security Requirements February 2007 3.4. 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. It SHOULD be possible to use various algorithms, either statically by specifying the algorithms used for integrity services, or by dynamic negotiation. 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 that 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 packets efficiently (with minimum CPU impact) which are not originating from the legitimate peer. This includes packet filters 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 RFC 3682 [insert ref]. 3.7. Key Management and Operational Considerations Some of the requirements above may in turn require shared keys between the BGP peers. Currently statically defined and manually configured keys are used for this purpose. RFC 3562 explains possible shortcomings of such keys, and gives recommendations to improve security. For any new mechanism aimed at securing BGP sessions it is highly desirable to use automated key negotiation mechanisms, based on the BGP speaker identity. Mechanisms based on key lists with defined life times for keys, for example as defined by draft-viswanathan-keyrollover-00.txt may be acceptable if there are good reasons to avoid automated key negotiation. Any security mechanism proposed to secure point to point BGP sessions should be easy to configure, and not require regular changes. 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 Behringer Expires August 27, 2007 [Page 6] Internet-Draft BGP Session Security Requirements February 2007 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. 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 and Brian Weis 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 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998. [RFC3682] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL Security Mechanism (GTSM)", RFC 3682, February 2004. [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. Author's Address Michael H. Behringer Cisco Behringer Expires August 27, 2007 [Page 7] Internet-Draft BGP Session Security Requirements February 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Behringer Expires August 27, 2007 [Page 8]