Internet Draft David Ward Document: draft-ward-bgp-ipsec-00.txt Cisco Systems Expires: 2002 January 2002 Securing BGPv4 using IPsec 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/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This document discusses how BGPv4 may utilize IPsec to provide authentication, integrity, confidentiality and replay protection. Table of Contents Status of this Memo.........................................1 Copyright Notice............................................1 Abstract....................................................1 Ward Internet Draft - Expires July 2002 1 Securing BGPv4 using IPsec February 2002 1. Introduction.............................................2 1.1 Terminology........................................3 1.2 Requirements language..............................3 2. BGPv4 security requirements..............................3 2.1 BGPv4 Security Proposal...........................4 2.2 Rekeying issues....................................5 2.3 IKE issues.........................................6 2.4 Transform issues...................................7 3. BGPv4/IPsec inter-operability guidelines.................8 3.1 BGPv4/IPsec binding................................9 3.2 Initiating a New BGPv4 Session....................10 3.3 Graceful BGPv4 Teardown...........................11 3.4 Non-graceful BGPv4 Teardown.......................12 3.5 Fragmentation Issues..............................12 3.6 Per-packet Security Checks........................14 3.7 IPsec Packet Integrity Assumptions................14 3.8 Transport mode versus tunnel mode.................14 3.9 IPsec tunnel mode addressing considerations.......16 3.10 NAT traversal for multihop peering sessions......18 4. Security considerations.................................18 4.1 IKE and BGPv4 authentication......................18 4.2 Certificate authentication........................19 4.3 Machine versus user certificates..................20 4.4 Pre-shared keys in IKE............................21 4.5 Use of AES in counter mode........................22 Acknowledgments............................................22 References.................................................22 Author's Addresses.........................................27 1. Introduction BGP v4, described in [1], is a connection-oriented dynamic routing protocol. A BGP session begins with an BGP OPEN message being sent to a configured BGP Peer over TCP, followed by a series of other steps to complete initialization. While the BGP session may include mutual authentication [52] and negotiation of session parameters [53], BGP does not define its own per- packet authentication, integrity, confidentiality or replay protection mechanisms. Ward Internet Draft - Expires July 2002 2 Securing BGPv4 using IPsec February 2002 IPsec is a protocol suite used to secure communications at the network layer between two peers. The IPsec protocol suite is specified within the IP Security Architecture [6], IKE [7], IPsec Authentication Header (AH) [3], and IPsec Encapsulating Security Payload (ESP) [4] documents. IKE is the key management protocol while AH and ESP are used to protect IP traffic. This draft proposes use of the IPsec protocol suite for protecting BGP v4 traffic over IP networks, and discusses how IPsec and BGP should be used together. 1.1 Terminology BGP BGP is a peer-peer protocol in which peers open TCP connections to other remote peers. Initiator The BGP peering Initiator connects to a remote peer on a well known TCP port <170> by sending an OPEN message. Remote Peer The BGP Remote Peer listens on the well-known TCP port for incoming connections, and replies over the same connection. 1.2 Requirements language In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [2]. 2. BGPv4 security requirements The BGPv4 protocol is used to transmit routing update packets over IP networks. Therefore, both the session and data packets of BGP are vulnerable to attack. Examples of attacks include: [1] An adversary may try to discover user identities by snooping data packets. [2] An adversary may try to modify packets (both session and data). [3] An adversary may try to hijack the BGPv4 connection. Ward Internet Draft - Expires July 2002 3 Securing BGPv4 using IPsec February 2002 [4] An adversary can launch denial of service attacks by terminating BGP connections, such as by sending a TCP reset. [5] An adversary may attempt to disrupt the BGP peering negotiation so as to weaken the BGP authentication process or gain access to peer passwords. To address these threats, the BGPv4 security implementation MUST provide authentication, integrity and replay protection for control and data packets. It MUST provide confidentiality for control and data packets. An BGPv4 security implementation MUST also provide a scalable approach to key management. The current BGP protocol, and drafted authentication mechanisms do not meet the security requirements as listed. BGPv4 md5 [52] authentication provides mutual authentication between the local and remote peer at connection origination, and secures session and data traffic on a per packet basis but, does not provide per-packet authentication, integrity, confidentiality or replay protection, therefore leaving the BGPv4 peering session vulnerable to attack. In addition, BGPv4 peering authentication, outlined in [1], does not provide for a protected ciphersuite negotiation. Therefore, BGP md5 authentication provides a weak security solution. 2.1 BGPv4 Security Proposal To provide authentication, integrity and replay protection of BGP Packets, BGPv4 security implementations MUST support transport mode ESP with NULL encryption and HMAC-SHA1 authentication. All the IPsec-mandated ciphersuites (described in RFC 2406 [4] and RFC 2402 [3]), including NULL encryption MUST be supported. Note that although an implementation MUST support all IPsec ciphersuites, it is an operator choice which ones will be used. The implementations MUST implement replay, authentication and integrity protection mechanisms of IPsec. All BGP security compliant implementations MUST implement IPsec ESP in transport mode for securing both BGPv4 session and data packets. If confidentiality is not used (e.g., BGPv4 data traffic), ESP with NULL encryption may be used. Note that AH mode is not suggested here as it may not be supported in future Ward Internet Draft - Expires July 2002 4 Securing BGPv4 using IPsec February 2002 versions of IPSec and ESP with NULL encryption has the same functionality. BGPv4 security MUST meet the key management requirements of the IPsec protocol suite. IKE SHOULD be supported for authentication, security association negotiation, and key management using the IPsec DOI [5]. 2.2 Rekeying issues It is expected that BGP sessions may need to last for very long intervals. It is unlikely but, possible that BGP may cycle through the 32-bit IPsec sequence number space due to this requirement. As a result, BGPv4 implementations operating may in the future be required to implement the IPsec sequence number extension, described in [49]. Sequence number extension is still not standardized and thus, NOT a requirement for the security implementation at the time of this publication Note that depending on the transform in use, it is possible that rekeying will be required prior to exhaustion of the sequence number space. Bellare et. al. have formalized this in [51], showing that the insecurity of CBC mode increases as O(s^2/2^n), where n is the block size in bits, and s is the total number of blocks encrypted. This formula sets a limit on the bytes that can be sent on a CBC SA before a rekey is required: B = s * n/8 = (n/8) * 2^(n/2) Where: B = maximum bytes sent on the SA n = block size in bits This means that cipher block size as well as key length needs to be considered in the rekey decision. 3DES uses a block size n = 64 bits (2^3 bytes); this implies that the SA must be rekeyed before B = (64/8) * (2^32) = 2^35 bytes are sent. In terms of the sequence number space, for a 3DES encrypted message of 512 = 2^9 bytes (2^6 blocks) this implies that the Ward Internet Draft - Expires July 2002 5 Securing BGPv4 using IPsec February 2002 key has become insecure after about 2^26 messages. This is s = 2^26 * 2^6 = 2^32 blocks and (2^32)^2/2^64 = 1. With the 3DES cipher in CBC mode, it would be prudent to rekey more often, such as every 2^20 messages or 2^29 bytes. These exceedingly short rekey times may make it difficult to utilize 3DES effectively to secure BGPv4. In comparison, AES-CBC uses a block size of 128 bits (2^4 bytes). This enables B = (128/8) * (2^64) = 2^68 bytes to be sent prior to requiring a rekey. This means that the required rekey times are 2^33 times longer than for 3DES. AES-CBC mode SHOULD be used in the BGPv4 security implementation. This alleviates the need for requiring the sequence number extension work [49]. In terms of the sequence number space, for an AES encrypted message of 512 = 2^9 bytes (2^5 blocks) this implies that the key has become insecure after about 2^59 messages (2^59 * 2^5)^2/2^128 = 1. This means that the entire current ESP sequence space of 2^32 messages could be consumed without compromising the key. AES would still permit a safe CBC mode construction if the ESP sequence space were expanded to 48 bits, since (2^48 * 2^5)^2/2^128 = 2^-22. 2.3 IKE issues As noted in [48], there are situations where it is necessary for IKE to be implemented in firmware. With the proliferation of IPsec host implementations, these issues are most likely to arise in future designs. In such situations, it is important to keep the size of the IKE implementation within strict limits. As noted in [48] an upper bound on the size of an IKE implementation might be considered to be 800 KB, with 80 KB enabling implementation in a wide range of situations. IKE implementations currently exist which meet the requirements. Therefore, while removal of seldom used IKE functionality (such as the nonce authentication methods) would reduce complexity, BGPv4 implementations typically will not require this in order to fit within the code size budget. Ward Internet Draft - Expires July 2002 6 Securing BGPv4 using IPsec February 2002 2.4 Transform issues Since BGPv4 implementations may operate in different deployment scenarios, the ability to offer IPsec security services with some flexibility is a goal. Since support for multiple algorithms multiplies the complexity and expense of system design, one of the goals of the transform selection effort is to find a minimal set of confidentiality and authentication algorithms that are implementable. In this specification, we primarily concern ourselves with IPsec transforms that have already been specified. Where existing algorithms do not gracefully scale for easy implementation, we further consider algorithms for which transform specifications are not yet complete, but for which parts are expected to be available for inclusion in products shipping within the next 12 months. As the state of the art advances, the range of feasible algorithms will broaden and additional mandatory-to-implement algorithms may be considered. This draft proposes that BGPv4 security implementations utilize IPsec transport mode ESP. Section 5 of RFC 2406 [4] states: "A compliant ESP implementation MUST support the following mandatory-to-implement algorithms: - DES in CBC mode - HMAC with MD5 - HMAC with SHA-1 - NULL Authentication algorithm - NULL Encryption algorithm " The DES algorithm is specified in [29]; implementation guidelines are found in [30], and security issues are discussed in [31],[43], [17]. The DES IPsec transform is defined in [32] and the 3DES in CBC mode IPsec transform is specified in [33]. The MD5 algorithm is specified in [8]; HMAC is defined in [19] and security issues with MD5 are discussed in [19]. The HMAC-MD5 IPsec transform is specified in [24]. The HMAC-SHA1 IPsec transform is specified in [25]. In addition to these existing algorithms, NIST is currently evaluating the following modes [37] of AES, defined in [34], [35]: Ward Internet Draft - Expires July 2002 7 Securing BGPv4 using IPsec February 2002 AES in Electronic Codebook (ECB) confidentiality mode AES in Cipher Block Chaining (CBC) confidentiality mode AES in Cipher Feedback (CFB) confidentiality mode AES in Output Feedback (OFB) confidentiality mode AES in Counter (CTR) confidentiality mode AES CBC-MAC authentication mode The Modes [36] effort is also considering a number of additional algorithms, including the following: PMAC HMAC-SHA1 [25] is to be preferred to HMAC-MD5, due to concerns that have been raised about the security of MD5 [9]. HMAC-SHA1 parts are currently available and an IPsec transform specification [25] exists. As a result, it is most practical to utilize HMAC-SHA1 as the authentication algorithm for products shipping in the near future. As a result, BGPv4 security implementations MUST implement HMAC with SHA1. The HMAC-SHA2 algorithm [28] is also under development, including an IPsec transform [45], so that this may merit consideration in the future. Authentication transforms also exist that are considerably more efficient to implement than either HMAC-SHA1 or HMAC-SHA2. UMAC [27],[44] is more efficient to implement in software and PMAC [26] is more efficient to implement in hardware. PMAC is currently being evaluated as part of the NIST modes effort [36] but an IPsec transform does not yet exist; neither does a UMAC transform. For confidentiality, the ESP mandatory-to-implement algorithm (DES) is unacceptable for use with BGPv4 security. As noted in [17], DES is crackable with modest computation resources, and so is inappropriate for use in situations requiring high levels of security. As a result, DES SHOULD NOT be used for encrypting BGP. 3. BGPv4/IPsec inter-operability guidelines The following guidelines are established to meet BGPv4 security requirements using IPsec in practical situations. Ward Internet Draft - Expires July 2002 8 Securing BGPv4 using IPsec February 2002 3.1 BGPv4/IPsec binding An BGPv4 session [1], composed of one (or more) TCP connections, is identified by the 2-tuple of the Initiator-defined identifier and the Remote Peer-defined identifier, . Each connection within a given session is assigned a unique Connection Identification, CID. The TCP connection is identified by the 5-tuple . An IPsec Phase 2 SA is identified by the 3-tuple . The BGPv4 session and connection information is carried within the BGPv4 Open Message, transported over TCP. Since an BGPv4 initiator may have multiple logical and interfaces, BGPv4 sessions may be initiated from different IP addresses. Similarly, multiple BGPv4 Remote Peers may exist behind a single IP address (firewall, NAT gateway), so that there may be multiple BGPv4 sessions between a given pair. The relationship between BGPv4 sessions, TCP connections and IKE Phase 1 and Phase 2 SAs is as follows: [1] An BGPv4 initiator or Remote Peer may have more than one interface, and therefore may have multiple IP addresses. Also, multiple BGPv4 initiators and Remote Peers may exist behind a single IP address. As a result, an BGPv4 Session may correspond to multiple IKE Phase 1 Security Associations, though typically a single IKE Phase 1 security association will exist for an tuple. [2] The TCP connection corresponding to the BGPv4 Session is protected by a separate IKE Phase 2 SA, with descriptors specific to that TCP connection. Each IKE Phase 2 SA protects only a single TCP connection, and each TCP connection is transported under only one IKE Phase 2 SA. BGPv4 security implementations need not verify that the IP addresses and TCP port values in the packet match the socket information which was used to setup the connection. This check will be performed by IPsec, preventing malicious peers from sending commands on inappropriate Quick Mode SAs. Given this, all the information needed for the BGPv4/IPsec binding is contained within the configuration for the BGPv4 Ward Internet Draft - Expires July 2002 9 Securing BGPv4 using IPsec February 2002 Initiator and Remote Peer. This includes the binding between an IKE Phase 1 SA and the corresponding BGPv4 sessions, as well as the binding between an IPsec Phase 2 SA and the TCP connection and BGPv4 connection ID. 3.2 Initiating a New BGPv4 Session In order to create a new BGPv4 Session, an Initiator implementing BGPv4 security first establishes IKE Phase 1 and Phase 2 SAs, then exchanges BGPv4 control messages over an IPsec-secured TCP connection. The BGPv4 Initiator contacts the Remote Peer on well-known TCP port <170>. The Initiator and Remote Peer MUST successfully complete the IKE phase 1 and Phase 2 negotiations before the initial TCP connection setup messages are exchanged so that these messages can be IPsec protected. From this point forward, subsequent BGPv4 connections established within the BGPv4 session will be protected by IKE Phase 2 SAs derived from the IKE Phase 1 SA. Note that this requirement also for the use of both the BGPv4 IPSec security implemenation and md5 authentication [52] but, it is not a practial deployment scenario. The dual deployment would be wasteful of CPU resources and would not provide an improved security implementation or deployment. In the Phase 2 Quick Mode exchanges used to protected individual BGPv4 connections, the Identity Payload fields MUST be present. These fields carry the source and destination addresses and source and destination ports of the BGPv4 Initiator and Remote Peers, thus binding the Phase 2 security association to specific TCP and BGPv4 connections. The IKE Quick Mode ID payloads MUST carry individual addresses, and MUST NOT use the IP Subnet or IP Address Range formats. Once the IKE Phase 2 negotiations are complete and the TCP connection is established over IPsec, the BGPv4 Initiator MUST send the BGPv4 OPEN command over the TCP connection secured by the recently negotiated Quick Mode SA. The Initiator fills in the ISID field, and leaves the TSID field set to zero, to indicate that it is the first message of a new session establishment exchange. The Initiator also fills in a CID value, which is associated with the BGPv4 connection corresponding to the TCP connection secured by the Quick Mode SA. When the BGPv4 Remote Peer replies with its OPEN Command, both BGPv4 devices will know the TSID, and therefore the BGPv4 session identifier . Ward Internet Draft - Expires July 2002 10 Securing BGPv4 using IPsec February 2002 At this point, a binding is established between the BGPv4 session identifier and the IKE Phase 1 SAs. A single BGPv4 session identifier may have multiple associated IKE Phase 1 SAs, and each IKE Phase 1 SA may have multiple associated BGPv4 session identifiers. In addition, a binding is established between the BGPv4 connection identifier CID, the TCP connection 5-tuple, and the IPsec SA, as identified by the combination. Each BGPv4 connection corresponds to a single TCP connection and IPsec SA. Within IKE, each key refresh requires that a new security association be established. In practice there is a time interval during which an old, about-to-expire SA and newly established SA will both be valid. The IPsec implementation will choose which security association to use based on local policy, and BGPv4 concerns play no role in this selection process. 3.3 Graceful BGPv4 Teardown Mechanisms within BGPv4 provide for both graceful and non- graceful teardown of BGPv4 Sessions or individual TCP connections within a given session. The BGPv4 close or graceful restart message is used to effect graceful teardown. This command allows the BGPv4 Initiator to request that the session be closed. When the BGPv4 implementation wishes to close a session, it MUST use the appropriate BGPv4 commands to accomplish this. After exchanging the appropriate BGPv4 control messages for session closure, the BGPv4 security implementation SHOULD initiate a half-close of each TCP connection within the BGPv4 session. Since a given IKE Phase 1 SA may be bound to multiple BGPv4 sessions (although very unlikely) and the SA can also possibly be shared by non-BGP traffic (for the same source and destination IP addresses) the BGPv4 implementation will only signal the deletion the IKE Phase 1 SAs bound to the BGPv4 session if there are no remaining BGPv4 sessions bound to those SAs. For those Phase 1 SAs that are deleted, the BGPv4 security implementation will also signal the IKE Phase 2 SAs bound to them. The actual responsibility of deleting the SA will be given to the IKE implementation. When the BGPv4 security implementation wishes to close an individual TCP connection while leaving the parent BGPv4 session Ward Internet Draft - Expires July 2002 11 Securing BGPv4 using IPsec February 2002 active, it SHOULD half-close the TCP connection. This results in a FIN being sent, putting the TCP connection into the FIN WAIT-1 state, as described in [10]. After the other side responds, the TIME WAIT state is entered. After the expiration of the TIME WAIT timeout, the IKE Phase 2 security association bound to the TCP connection MUST be deleted. Closing the TCP connection prior to deleting the IKE Phase 2 SA ensures that all the TCP packets sent on the connection are IPsec-protected. 3.4 Non-graceful BGPv4 Teardown If the BGPv4 security implementation becomes aware that a given TCP connection has unexpectedly failed, it SHOULD delete the associated IKE Phase 2 security association. If the IKE implementation receives a Phase 2 Delete message for a security association bound to a TCP connection, it SHOULD notify the BGPv4 security implementation. If the TCP connection whose SA was deleted is one which a CLOSE sequence marked for removal from the BGPv4 session, then the IKE Phase 2 Delete message serves as confirmation that the BGPv4 peer has executed an BGPv4 teardown process for the connection. The BGPv4 connection state and any associated filters can now be safely removed. BGPv4 keep-alive messages, notification and update messages provide the capability to detect or signal when a non-graceful restart has occurred. Whenever teardown events occur, causing the peer session to close, the control connection teardown mechanism defined in [1] must be used. Once the BGPv4 peering session is deleted by either peer, any phase 1 and phase 2 SA's which still exist as a result of the session between the peers SHOULD be deleted. Phase 1 and phase 2 delete messages SHOULD be sent when this occurs. This should in no way interfere with BGPv4 Graceful Restart mechanisms [graceful restart]. 3.5 Fragmentation Issues Fragmentation can become a concern when prepending IPsec headers to a BGP PDU. One mechanism which can be used to reduce this problem is to utilize path MTU discovery within the TCP transport protocol. For example, when TCP is used as the BGPv4 transport, then path MTU discovery [11]-[13], SHOULD be used to enable the TCP endpoints to discover the correct MTU, including effects due to IPsec encapsulation. Ward Internet Draft - Expires July 2002 12 Securing BGPv4 using IPsec February 2002 However, Path MTU discovery fails when appropriate ICMP messages are not received by the host. This occurs in IPsec implementations which drop unauthenticated ICMP packets. This can result in blackholing in nave TCP implementations, as described in [RFC2923]. Appropriate TCP behavior is described in section 2.1 of [RFC2923]: "TCP should notice that the connection is timing out. After several timeouts, TCP should attempt to send smaller packets, perhaps turning off the DF flag for each packet. If this succeeds, it should continue to turn off PMTUD for the connection for some reasonable period of time, after which it should probe again to try to determine if the path has changed." If an ICMP PMTU is received by an IPsec implementation that processes unauthenticated ICMP packets, this value should be stored in the SA as proposed in [RFC2401], and IPsec should also provide notification of this event to TCP so that the new MTU value can be correctly reflected. When certificate authentication is used, IKE fragmentation can be encountered. This can occur when certificate chains are used, or even when exchanging a single certificate if the key size, or size of other certificate fields (such as the distinguished name and other OIDs) is arge enough. Many Network Address Translators (NATs) and firewalls do not handle fragments properly, dropping them on inbound and/or outbound. Routers in the path will also frequently discard fragments after the initial one, since they typically will not contain full IP headers that can be compared against an Access List. As a result, where IKE fragmentation occurs, the endpoints will often be unable to establish an IPsec security association. The solution to this problem is to install NAT, firewall or router code load that can properly support fragments. If this cannot be done, then the following alternatives can be considered: [1] Obtaining certificates by other means. [2] Reducing the size of the certificate chain. [3] Reducing the size of fields within the certificates. This includes reduction in the key size, Ward Internet Draft - Expires July 2002 13 Securing BGPv4 using IPsec February 2002 the distinguished name or other fields. This should be considered only as a last resort. 3.6 Per-packet Security Checks When a packet arrives from a connection which requires security, BGP MUST check to ensure that the packet was decrypted and/or authenticated by IPsec. Since IPsec already verifies that the packet arrived in the correct SA, BGPv4 can be assured that the packet was indeed sent by a trusted peer. When used with BGP, IPsec will negotiate a separate Phase 2 SA for each TCP connection, with IPsec filters specific to the TCP connection. As a result, only traffic for a single TCP connection will flow within each IPsec Phase 2 SA. BGPv4 security implementations need not verify that the IP addresses and TCP port values in the packet match the socket information which was used to setup the BGPv4 connection. This check will be performed by IPsec, preventing malicious peers from sending BGPv4 session packets on inappropriate Quick Mode SAs. 3.7 IPsec Packet Integrity Assumptions BGP's error detection and recovery assumes that the TCP and IP checksums provides adequate integrity protection. IPsec per-packet authentication and integrity protection offers strong protection against an attacker attempting to modify packets In transit, as well as unintentional packet modifications caused by router malfunctions. This protection is considerably stronger than the 16-bit TCP checksum [11]. Since IPsec integrity protection occurs below TCP, if an error is discovered, then the packet will be discarded and TCP retransmission will occur, so that no recovery action need be taken at the BGP layer. 3.8 Transport mode versus tunnel mode With respect to the BGPv4 security implemenation, the major differences between the IPsec tunnel mode and transport mode are as follows: [1] MTU considerations. Tunnel mode introduces an additional IP header into the datagram that reflects itself in a corresponding decrease in the path MTU seen Ward Internet Draft - Expires July 2002 14 Securing BGPv4 using IPsec February 2002 by packets traversing the tunnel. This may result in a decrease in the maximum segment size of TCP connections running over the tunnel. [2] Address assignment and configuration. Within IPsec tunnel mode, it is necessary for inner and outer source addresses to be configured, and for inner and outer destination addresses to be discovered. Within transport mode it is only necessary to discover a single destination address and configure a single source address. [3] NAT traversal. As noted in [20], IPsec tunnel mode ESP can traverse NAT in limited circumstances, whereas transport mode ESP cannot traverse NAT. To enable NAT traversal in the general case, the IPsec NAT traversal functionality described in [21], [22], [23] can be implemented. More details are provided in the next section. [4] Connection-specific selectors. For both transport and tunnel mode, it is possible to negotiate connection- specific selectors, so that only a single BGPv4 connection will be protected by an IKE Phase 2 SA. However, while negotiation of connection-specific selectors is common within IPsec transport mode implementations, IPsec security gateway implementations typically negotiate "ANY to ANY" selectors by default. [5] Firewall traversal. Where a BGPv4 connection is to traverse administrative domains, the firewall administrator may desire to verify the integrity and authenticity of each transiting packet, rather than opening a hole in the firewall for BGPv4. IPsec tunnel mode lends itself to such verification, since the firewall can terminate the tunnel mode connection while still allowing the endpoints to communicate end-to-end. If desired, the endpoints can in addition utilize IPsec transport mode for end-to-end security, so that they can also verify authenticity and integrity of each packet for themselves. In contrast, carrying out this verification with IPsec transport mode is more complex, since the firewall will need to terminate the IPsec transport mode connection and will need to act as a TCP proxy, originating a new Ipsec transmport mode connection from the firewall to the internal endpoint. Ward Internet Draft - Expires July 2002 15 Securing BGPv4 using IPsec February 2002 Such an implementation cannot provide end-to-end authenticity or integrity protection. [6] IPsec-application integration. Where IPsec and the application layer protocol are implemented on the same device or host, it is possible to enable tight integration between them. For example, the application layer can request and verify that connections are protected by IPsec, and can obtain attributes of the IPsec security association. While in transport mode implementations the IPsec and application protocol implementations typically reside on the same host, with IPsec tunnel mode, they may reside on different hosts. Where IPsec is implemented on an external gateway, integration between the application and IPsec is typically not possible. This limits the ability of the application to control and verify IPsec behavior. 3.9 IPsec tunnel mode addressing considerations IPsec tunnels include both inner and outer source as well as destination addresses. When used with BGPv4, the inner destination address represents the address of the BGPv4 peer (e.g. the ultimate destination for the packet). The inner destination address can be discovered using SLP or can be resolved from an FQDN via DNS, so that obtaining this address is typically not an issue. The outer destination address represents the address of the IPsec security gateway used to reach the peer. Several mechanisms have been proposed for discovering the IPsec security gateway used to reach a particular peer. [55] discusses the use of KX Resource Records (RRs) for IPsec gateway discovery. However, while KX RRs are supported by many DNS server implementations, they have not yet been widely deployed. Alternatively, DNS SRV [54] can also be used for this purpose, as can protocols such as Tunnel Endpoint Discovery [58]. When used with BGPv4, the outer source address is configured either statically or dynamically, using mechanisms such as DHCPv4 [56], DHCPV6 [57], or Stateless address autoconfiguration [57]. Ward Internet Draft - Expires July 2002 16 Securing BGPv4 using IPsec February 2002 The inner source address SHOULD be included in the quick mode ID when the peer establishes a tunnel mode SA with the IPsec security gateway. This enables the IPsec security gateway to properly route packets back to the remote peer. The inner source address can be configured via a variety of mechanisms, depending on the scenario. Where the BGPv4 peers are located within the same administrative domain, it is typically possible for the inner and outer source addresses to be the same. This will work because the outer source address is presumably assigned from within a prefix assigned to the administrative domain, and which is therefore routable within the domain. Assuming that the IPsec security gateway is aware of the inner source address used by the connecting peer and plumbs a host route for it, then packets arriving at the IPsec security gateway destined for the address can be correctly encapsulated and sent down the correct tunnel. Where BGPv4 peers are located within different administrative domains, it may be necessary for the inner source address to be assigned by the IPsec security gateway, effectively "joining" the remote host to the LAN attached to the IPsec security gateway. For example, if the remote peer were to use its assigned (outer) source address as the inner source address, then a number of problems might result: [1] Intrusion detection systems sniffing the LAN behind the IPsec security gateway would notice source addresses originating outside the administative domain. [2] Reply packets might not reach their destination, since the IPsec security gateway typically does not advertise default, but rather only the prefix that it allocates addresses from. Since the remote peer's address does not originate from with a prefix native to the administrative domain, it is likely that routers within the domain would not have a route for it, and would send the packet off to the border router, instead of to the IPsec security gateway. For these reasons, for inter-domain use, assignment of inner source addresses may be needed. The use of DHCP within IPsec tunnel mode has been proposed for this, as described in [55]. However, this mechanism is not yet widely deployed within IPsec security gateways. Existing IPsec tunnel mode servers typically implement the desired functionality via proprietary extensions to IKE. Ward Internet Draft - Expires July 2002 17 Securing BGPv4 using IPsec February 2002 3.10 NAT traversal for multihop peering sessions BGP security utilizes transport mode ESP. As noted in [20], transport mode ESP cannot traverse NAT, even though ESP itself does not include IP header fields within its message integrity check. This is because the 16-bit TCP checksum is calculated based on a "pseudo-header" that includes IP header fields, and the checksum is protected by the IPsec message integrity check. As a result, the TCP checksum will be invalidated by a NAT located between the BGPv4 Initiator and Remote Peer. Since TCP checksum calculation and verification is mandatory in both IPv4 and IPv6, it is not possible to omit checksum verification while remaining standards compliant. In order to enable traversal of NAT existing between BGPv4 Initiators and Remote Peers, while remaining in compliance, BGPv4/IPsec implementations MAY implement IPsec/IKE NAT traversal, as described in [20]-[23]. The IPsec/IKE NAT traversal specification [23] enables UDP encapsulation of IPsec to be negotiated if a NAT is detected in the path. By determining the IP address of the NAT, the TCP checksum can be calculated based on a pseudo-header including the NAT-adjusted address and ports. If this is done prior to calculating the IPsec message integrity check, TCP checksum verification will not fail. 4. Security considerations IPsec IKE negotiation MUST negotiate an authentication method specified in the IKE RFC 2409 [7]. In this section, we discuss authentication issues. 4.1 IKE and BGPv4 authentication While BGPv4 provides initial authentication [52], it does not provide per-packet authentication, integrity or replay protection. This implies that the identity verified in the BGPv4 OPEN is not subsequently verified on reception of each packet. With IPsec, when the identity asserted in IKE is authenticated, the resulting derived keys are used to provide per-packet authentication, integrity and replay protection. As a result, Ward Internet Draft - Expires July 2002 18 Securing BGPv4 using IPsec February 2002 the identity verified in the IKE conversation is subsequently verified on reception of each packet. Let us assume that the identity claimed in BGPv4 OPEN is a user identity, while the identity claimed within IKE is a machine identity. Since only the machine identity is verified on a per- packet basis, there is no way for the recipient to verify that only the user authenticated via BGPv4 OPEN is using the IPsec SA. In fact, IPsec implementations that only support machine authentication typically have no way to distinguish between user traffic within the kernel. As a result, where machine authentication is used, once a BGPv4/IPsec SA is opened, another user on a multi-user machine may be able to send traffic down the IPsec SA. If a network is operated by different administrative groups with different security privileges for configuration or operational duties then per user authentication may be applicable. To limit the potential vulnerability, BGP security implementations MUST negotiate a separate IPsec Phase 2 SA for each BGP peering session, with descriptors specific to that connection. This will prevent traffic for other BGP peers from travel within the IPsec SA negotiated for another BGPv4 connection. As a result, if access to the TCP socket used for the BGPv4 connection is exclusive to a single user, then access to the corresponding IPsec SA will also be exclusive, even if the IPsec implementation only supports machine authentication. If the IPsec implementation supports user authentication, the user identity asserted within IKE will be verified on a per- packet basis, and stronger assurances can be provided. In this case, the user identity asserted within IKE will be verified on a per-packet basis. In order to provide segregation of traffic between peers When user authentication is used, the sender MUST ensure that only traffic from that particular user is sent down the BGPv4 SA. Enforcement of this restriction is the responsibility of the operating system. 4.2 Certificate authentication When X.509 certificate authentication is chosen within IKE, the BGPv4 Remote Peer is expected to use an IKE Certificate Request Payload (CRP) to request from the Initiator a certificate issued Ward Internet Draft - Expires July 2002 19 Securing BGPv4 using IPsec February 2002 by a particular certificate authority or may use several CRPs if several certificate authorities are trusted and configured in its IPsec IKE authentication policy. The BGPv4 remote peer SHOULD be able to trust several certificate authorities in order to allow BGP session Initiators to connect to it using their own certificate credential from their chosen PKI. Client and server side certificate revocation list checking MAY be enabled on a per-CA basis, since differences in revocation list checking exist between different PKI providers. 4.3 Machine versus user certificates The certificate credentials provided by the BGPv4 Initiator during the IKE negotiation MAY be those of the machine or of the BGPv4 user (router administrator or perhaps the operator performing BGP configuration). When machine authentication is used, the machine certificate is typically stored on the BGPv4 Initiator and Remote Peer during an enrollment process. When user certificates are used, the user certificate can be stored either on the machine or on a smartcard. Since the value of a machine certificate is inversely proportional to the ease with which an attacker can obtain one under false pretenses, it is advisable that the machine certificate enrollment process be strictly controlled. For example, only administrators may have the ability to enroll a machine with a machine certificate. While smartcard certificate storage lessens the probability of compromise of the private key, smartcards are not necessarily desirable in all situations. For example, some organizations deploying machine certificates use them so as to restrict use of non-approved hardware. Since user authentication can be provided within BGPv4 (keeping in mind the weaknesses described earlier), support for machine authentication in IPsec makes it is possible to authenticate both the machine as well as the user. In circumstances in which this dual assurance is considered valuable, enabling movement of the machine certificate from one machine to another, as would be possible if the machine certificate were stored on a smart card, may be undesirable. Similarly, if user certificates are deployed, it is advisable for the user enrollment process to be strictly controlled. If Ward Internet Draft - Expires July 2002 20 Securing BGPv4 using IPsec February 2002 for example, a user password can be readily used to obtain a certificate (either a temporary or a longer term one), then that certificate has no more security value than the password. To limit the ability of an attacker to obtain a user certificate from a stolen password, the enrollment period can be limited, after which password access will be turned off. Such a policy will prevent an attacker obtaining the password of an unused account from obtaining a user certificate once the enrollment period has expired. 4.4 Pre-shared keys in IKE Use of pre-shared keys in IKE main mode is vulnerable to man-in- the-middle attacks when used with dynamically addressed Initiators. In main mode it is necessary for SKEYID_e to be used prior to the receipt of the identification payload. Therefore the selection of the pre-shared key may only be based on information contained in the IP header. However, where dynamic IP address assignment is used, it is often not possible to identify the required pre-shared key based on the IP address. The main concern here is in the case of auto-configuration of routers by a central administrative unit introducing the new equipment into the network. Thus when main mode pre-shared keys are used with BGPv4, the same pre-shared key is shared by a group of Initiators and is no longer able to function as an effective shared secret. In this situation, neither the client nor the server identifies itself during IKE phase 1; it is only known that both parties are a member of the group with knowledge of the pre-shared key. This permits anyone with access to the group pre-shared key to act as a man-in-the-middle. This vulnerability does not occur in aggressive mode since the identity payload is sent earlier in the exchange, and therefore the pre-shared key can be selected based on the identity. However, when aggressive mode is used the user identity is exposed and this is often considered undesirable. As a result, where main mode is used with pre-shared keys, unless BGPv4 performs mutual authentication, the Remote Peer is not authenticated. This enables a rogue Remote Peer in possession of the group pre-shared key to successfully masquerade as the actual Remote Peer and mount a dictionary attack on legacy authentication methods such as CHAP [47]. Such an attack could potentially compromise many passwords at a time. Ward Internet Draft - Expires July 2002 21 Securing BGPv4 using IPsec February 2002 This vulnerability is widely present in existing IPsec implementations. To avoid this problem, BGPv4/IPsec implementations SHOULD NOT use a group pre-shared key for IKE authentication with main mode. If pre-shared keys are required, then aggressive mode SHOULD be used. IKE pre-shared authentication key values SHOULD be protected in a manner similar to the user's account password. 4.5 Use of AES in counter mode When AES in counter mode is used, it is important to avoid reuse of the counter with the same key, even across all time. Counter mode creates ciphertext by XORing generated key stream with plaintext. It is fairly easy to recover the plaintext from two messages counter mode encrypted under the same counter value, simply by XORing together the two packets. The implication of this is that it is almost always an error to use IPsec manual keying with counter mode, except when the implementation takes heroic measures to maintain state across sessions. Another counter mode issue is it makes forgery of correct packets trivial. Counter mode should therefore never be used without also using data authentication. Acknowledgments Thanks to Bernard Aboba of Microsoft, Steven Chiang, Mark Knopper, and Russ White of Cisco Systems and Susan Hares of Nexthop for reviewing this draft. Also great thanks goes to all the authors of draft-ietf-ips-security-09.txt and RFC 3193 as this draft is directly reusing their work and words. References [1] Rekhter, Y. and T. Li (editors), "A Border Gateway Protocol 4 (BGP-4)", Internet Draft draft-ietf-idr-bgp4-17.txt, January 2002. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Kent,S., Atkinson, R., "IP Authentication Header", RFC 2402, November 1998. Ward Internet Draft - Expires July 2002 22 Securing BGPv4 using IPsec February 2002 [4] Kent,S., Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [5] Piper, D., "The Internet IP Security Domain of Interpretation of ISAKMP", RFC 2407, November 1998. [6] Atkinson, R., Kent, S., "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [7] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [8] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [9] Dobbertin, H., "The Status of MD5 After a Recent Attack", CryptoBytes Vol.2 No.2, Summer 1996. [10] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [11] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191, November 1990. [12] Knowles, S., "IESG Advice from Experience with Path MTU Discovery", RFC 1435, March 1993. [13] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996. [14] Lahey, K., TCP Problems with Path MTU Discovery", RFC 2923, September 2000. [15] Paxon, V., "End-to-end internet packet dynamics", IEEE Transactions on Networking 7,3 (June 1999) pg 277-292. [16] Stone J., Partridge, C., "When the CRC and TCP checksum disagree", ACM Sigcomm, Sept. 2000. [17] Cracking DES, O'Reilly & Associates, Sebastapol, CA 2000. [18] Krueger, M., et.al., "BGPv4 Requirements and Design Considerations", draft-ietf-ips-BGPv4-reqmts-05.txt, Work in Progress, July 2001. Ward Internet Draft - Expires July 2002 23 Securing BGPv4 using IPsec February 2002 [19] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997. [20] Aboba, B., "IPsec-NAT Compatibility Requirements", draft- ietf-IPsec-nat-reqts-00.txt, Work in Progress, June 2001. [21] Huttunen, A. et. al., "UDP Encapsulation of IPsec Packets", draft-ietf-IPsec-udp-encaps-00.txt, June 2001 [22] Dixon, W. et. al., "IPsec over NAT Justification for UDP Encapsulation", draft-ietf-IPsec-udp-encaps-justification- 00.txt, June 2001 [23] Kivinen, T., et al., "Negotiation of NAT-Traversal in the IKE",Internet draft (work in progress), draft-ietf-IPsec-nat-t- ike-00.txt, June 2001. [24] Madson, C., Glenn, R., "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, November 1998. [25] Madson, C., Glenn, R., "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998. [26] Rogaway, P., Black, J., "PMAC: Proposal to NIST for a parallelizable message authentication code", http://csrc.nist.gov/encryption/modes/proposedmodes/pmac/pmac- spec.pdf [27] Black, J., Halevi, S., Krawczyk, H., Krovetz, T., Rogaway, P., "UMAC: Fast and provably secure message authentication", Advancesin Cryptology - CRYPTO '99, LNCS vol. 1666, pp. 216-233. Full version available from http://www.cs.ucdavis.edu/~rogaway/umac [28] "Descriptions of SHA-256, SHA-384, and SHA-512," http://csrc.nist.gov/cryptval/shs/sha256-384-512.pdf. [29] U.S. DoC/NIST, "Data encryption standard (DES)", FIPS 46-3, October 25, 1999. [30] U.S. DoC/NIST, "Guidelines for implementing and using the nbs data encryption standard", FIPS 74, Apr 1981. [31] Biham, E., Shamir, A., "Differential Cryptanalysis of DES- like cryptosystems", Journal of Cryptology Vol 4, Jan 1991. Ward Internet Draft - Expires July 2002 24 Securing BGPv4 using IPsec February 2002 [32] Madson, C., Doraswamy, N., "The ESP DES-CBC Cipher Algorithm With Explicit IV", RFC 2405, November 1998. [33] Pereira, R., Adams, R., "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998. [34] Daemen, J., Rijman, V., "AES Proposal: Rijndael," NIST AES Proposal, June 1998. http://csrc.nist.gov/encryption/aes/round2/AESAlgs/Rijndael/Rijn dael.pdf [35] Draft FIPS Publication ZZZZ, "Advanced Encryption Standard (AES)", U.S. DoC/NIST, summer 2001. [36] "Symmetric Key Block Cipher Modes of Operation," http://www.nist.gov/modes. [37] "Recommendation for Block Cipher Modes of Operation", National Institute of Standards and Technology (NIST) Special Publication 800-XX, CODEN: NSPUE2, U.S. Government Printing Office Washington, DC, July 2001. [38] Frankel, S., Kelly, S., Glenn, R., "The AES Cipher Algorithm and Its Use with IPsec", Internet draft (work in progress), draft-ietf-IPsec-ciph-aes-cbc-01.txt, May 2001. [39] Etienne, J., "The counter-mode and its use with ESP", Internet draft (work in progress), draft-etienne-IPsec-esp-ctr- mode-00.txt, May 2001. [40] Lipmaa, H., Rogaway, P., Wagner, D., "CTR-MODE encryption", Comment on mode of operations NIST, Jan 2001. [41] Schneier, B., J. Kelsey, D. Whiting, D. Wagner, C. Hall, and N. Ferguson, "Performance Comparison of the AES Submissions", http://www.counterpane.com/AES-performance.html [42] A. Bosselaers, "Performance of Pentium implementations", http://www.esat.kuleuven.ac.be/~bosselae/ [43] Bellovin, S., "An Issue With DES-CBC When Used Without Strong Integrity", Proceedings of the 32nd IETF, Danvers, MA, April 1995. [44] Krovetz, T., Black, J., Halevi, S., Hevia, A., Krawczyk, H., Rogaway, P., "UMAC: Message Authentication Code using Ward Internet Draft - Expires July 2002 25 Securing BGPv4 using IPsec February 2002 Universal Hashing", Internet draft (work in progress), draft- krovetz-umac-01.txt, October 2000. [45] Frankel, S., Kelly, S., "The Use of SHA-256, SHA-384, and SHA-512 within ESP, AH and IKE," Work in progress. [46] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, November 1998. [47] Simpson, W.,"PPP Challenge Handshake Authentication Protocol (CHAP)," RFC 1994, August 1996. [48] Black, D., "iSCSI Security Requirements and SRP-based ESP keys", Internet draft (work in progress), draft-black-ips-iscsi- security-00.txt, July 2001. [49] Steve Kent, IPsec sequence number extension proposal, IETF 50. [50] American National Standard for Financial Services X9.52- 1998, "Triple Data Encryption Algorithm Modes of Operation", American Bankers Association, Washington, D.C., July 29, 1998. [51] Bellare, Desai, Jokippi, Rogaway, "A Concrete Treatment of Symmetric Encryption: Analysis of the DES Modes of Operation", 1997, http://www-cse.ucsd.edu/users/mihir/ [52] Heffernan, Andy. Protection of BGP Sessions via the TCP MD5 Signature Option, Internet draft, draft-ietf-idr- rfc2385bis-00.txt, January 2002. [53] Chandra, Scudder. Capabilities Advertisement with BGP-4, Internet draft, draft-ietf-idr-rfc2842bis-00.txt, August 2002. [54] Gulbrandsen , A., . Vixie, P., Esibov, L. "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [55] Gulbrandsen , A., . Vixie, P., Esibov, L. "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [56] Patel, B., Aboba, B., Kelly, S., Gupta, V., "DHCPv4 Configuration of IPsec Tunnel Mode", Internet draft (work in progress), draft-ietf-ipsec-dhcp-13.txt, June 2001 Ward Internet Draft - Expires July 2002 26 Securing BGPv4 using IPsec February 2002 [57] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. [58] Fluhrer, S., "Tunnel Endpoint Discovery", Internet draft (work in progress), draft-fluhrer-ted-00.txt, November 2001. Author's Addresses David Ward Cisco 408 St Peter Street Suit 600 St Paul MN 55102 Phone: 1 612 865 8972 Email: dward@cisco.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. Ward Internet Draft - Expires July 2002 27 Securing BGPv4 using IPsec February 2002 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 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." Ward Internet Draft - Expires July 2002 28 Securing BGPv4 using IPsec February 2002 Expiration Date This memo is filed as , and expires MM DD, 2002. Ward Internet Draft - Expires July 2002 29