Working Group U. Chunduri Internet-Draft A. Tian Intended status: Informational Ericsson Inc. Expires: August 29, 2013 J. Touch USC/ISI February 25, 2013 A framework for RPs to use IKEv2 KMP draft-chunduri-karp-using-ikev2-with-tcp-ao-04 Abstract This document describes a mechanism to secure pairwise Routing Protocol associations using the IKEv2 Key Management Protocol (KMP). Most of the pairwise Routing Protocols (RPs) are TCP-based but the framework described here is applicable to other pairwise RPs, which not necessarily use the TCP at transport layer. A Gatekeeper mechanism is introduced to allow all pairwise RPs to coordinate with IKEv2 Protocol to pass the policy, get the keying material and to maintain the security associations. The Gatekeeper also allows pairwise RPs which use TCP-AO to coordinate with IKEv2 without fundamental modification to either. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on August 29, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Chunduri, et al. Expires August 29, 2013 [Page 1] Internet-Draft A framework for RPs to use IKEv2 KMP February 2013 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Motivation and Overview . . . . . . . . . . . . . . . . . . . 4 2.1. Manual Keying with the Gatekeeper . . . . . . . . . . . . 6 3. The Gatekeeper . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. TCP-based RP interface to the Gatekeeper . . . . . . . . . 8 3.1.1. TCP-AO interface to Gatekeeper . . . . . . . . . . . . 9 3.2. Other pairwise RPs interface to the Gatekeeper . . . . . . 9 3.3. KMP interaction with the Gatekeeper . . . . . . . . . . . 10 3.3.1. Interaction with KARP Crypto Key Table . . . . . . . . 10 3.3.2. Interface to the PAD . . . . . . . . . . . . . . . . . 12 3.4. Impact of Policy changes . . . . . . . . . . . . . . . . . 13 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 7. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.1. BGP Multi Session and transport level differentiation . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Chunduri, et al. Expires August 29, 2013 [Page 2] Internet-Draft A framework for RPs to use IKEv2 KMP February 2013 1. Introduction This document analyzes the pairwise Routing Protocol requirements needed to integrate the IKEv2[RFC5996] KMP and provides a framework to achieve this. The KARP design guide [RFC6518] suggests various requirements and options for obtaining keys to protect the routing protocols and recommends using a Key Management Protocol (KMP) to automate key establishment, as well as rekeying to continuously protect the routing protocols. A security threat analysis for all TCP-based routing protocols (BGP [RFC4271], PCEP [RFC5440], MSDP [RFC3618] and LDP [RFC5036]) is detailed in [ietf-karp-routing-tcp-analysis] and also recommends the KMP usage for automating the key establishment to protect the RP messages. There are few gaps in the way how IKEv2 KMP and TCP-AO expects the Security Associations (SAs) to be maintained and how pairwise RPs can further offload SA management. This memo addresses these gaps by providing a common framework to interact pairwise RPs and IKEv2 KMP. The choice of IKEv2 KMP is based on the WG consensus. A major portion of pairwise RPs analyzed in this document use TCP at transport layer and may use TCP-AO[RFC5925] to protect the RP messages. There are other RPs, which use pairwise unicast signaling between the routing peers (for e.g., BFD [RFC5880]) and don't use TCP at transport layer. This memo also describes the interface for these RPs to integrate with IKEv2 KMP. This document introduces a new Gatekeeper (GK) module, which provides a common interface and minimizes the changes for all pairwise routing protocols to be integrated with KMP. The Gatekeeper module does the SA management and interaction with KMP as well as TCP-AO protocol or the RP itself (for the RPs which don't use TCP-AO). The purpose of the Gatekeeper is to act as a shim between IKEv2 and RP/TCP-AO, so that RP/TCP-AO and the Gatekeeper together act like IPsec to IKEv2 (since IKEv2 is designed to tightly interact with IPsec). This document defines this common interface between all pairwise RPs with Gatekeeper and IKEv2 [RFC5996]. The common interface defined here also serves the pairwise RPs with manual keying and this is further described in Section 2.1. Currently IKEv2 can establish only Security Association (SA) for IPsec. A few extensions are needed for IKEv2 to establish SA for pairwise RPs which either protect protocol packets by themselves or use TCP-AO for protection. [mahesh-karp-rkmp] discusses the summary of extensions required for IKEv2 protocol for key establishment, traffic selectors negotiation and SA establishment to support the keying and parameters needed by RP or TCP-AO. Chunduri, et al. Expires August 29, 2013 [Page 3] Internet-Draft A framework for RPs to use IKEv2 KMP February 2013 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 1.2. Acronyms BGP - Border Gateway Protocol EAP - Extensible Authentication Protocol GKR - Gatekeeper Record IKEv2 - Internet Key Exchange Protocol Version 2 IPsec - Security Architecture for the Internet Protocol KDF - Key Derivation Function as defined in TCP-AO KMP - Key Management Protocol (auto key management) LDP - Label Distribution Protocol MKM - Manual Key management Protocols MKT - Master Key Tuples as defined in TCP-AO MSDP - Multicast Source Discovery Protocol PAD - Peer Authorization Database PCEP - Path Computation Element Communication Protocol RP - Routing Protocol SA - Security Association TCP-AO - TCP Authentication Option 2. Motivation and Overview The motivation of this document is to offload Security Association (SA) management and to provide a generic and common interface for all pairwise RPs to integrate with KMPs in general and specifically with IKEv2 KMP. Chunduri, et al. Expires August 29, 2013 [Page 4] Internet-Draft A framework for RPs to use IKEv2 KMP February 2013 IKEv2 assumes IPsec triggers new SA requests, manages SA timers and rekeys SAs as needed. For e.g., for TCP-based RPs, TCP-AO assumes an external key manager, which could support functions like Master key triggering, SA timers, and rekey triggering to get all the parameters required including Master key to protect the TCP session. To bridge the gap between IKEv2 and TCP-AO or to simplify pairwise RPs which don't use TCP-AO, this document defines a Gatekeeper module as described in Section 3. The following diagram depicts how, the Gatekeeper module interfaces with all protocols involved i.e., Pairwise RPs which do security by themselves, TCP-based RPs which use TCP-AO, IKEv2 KMP, and TCP-AO itself. This also shows the interaction with various databases viz., Peer Authorization Database (PAD) and Crypto Key Tables interaction with the Gatekeeper. +-------------+ |Pairwise RPs | +-------------+ |(BFD and |-----+ | PAD | |other non-TCP| | +-->--| |----+ |based RPS) | | | +-------------+ | +-------------+ | | v | | | | +-------------+ +------------+ | | | | | +-------------+ +---->| | Trigger | | |TCP based |RP Config | |----------->| | | RPs |---------->| | | | |(BGP/LDP/PCEP| | Gatekeeper | | IKEv2 KMP | | /MSDP | +-----| | Negotiated | | +-------------+ | | | Parameters | | | | |------------| | | | | | | | +------+------+ +------------+ V |MKTs or +-------------+ | |Negotiated Parameters | | | +------v------+ | TCP-AO |-----+ | Crypto Key | | |MKTs | Tables | | | +-------------+ +-------------+ Figure 1: KARP KMP: Using IKEv2 with Pairwise RPs In Figure 1, before initiating the RP messaging to the peer, non-TCP- Chunduri, et al. Expires August 29, 2013 [Page 5] Internet-Draft A framework for RPs to use IKEv2 KMP February 2013 based RPs communicate the provisioned configuration to Gatekeeper module. Similarly, before initiating the TCP connection, all TCP- based RPs communicate the provisioned configuration to Gatekeeper module. A entry in the KMP peer authentication/authorization is provisioned in PAD as defined in Section 4.4.3 of [RFC4301] and pointer to this entry SHOULD be part of the RP configuration. This facilitates Gatekeeper to issue a corresponding request, with all the proposed alternatives at the RP to the IKEv2 KMP. This enables the IKEv2 to negotiate the needed security policy parameters and derive Keying material to be used by RPs. When the local peer is acting as a responder, security policy information populated at the Gatekeeper can be referenced through PAD by IKEv2 KMP to create the CHILD_SAs ([RFC5996]). Either way, the negotiated parameters are kept in the crypto key table database as specified in [ietf-karp-crypto-key- table] and this information is basis for provisioning MKTs in the TCP-AO or applying security by non-TCP-based RPs themselves. The Gatekeeper maintains the KMP SAs as per the provisioning information at RPs and initiates rekey triggers as needed to provision new MKTs for the long-lived TCP sessions protected by TCP-AO. The Gatekeeper also installs these new keys in TCP-AO consistent with TCP-AO's support for key changes or returns the new keys back to non-TCP-based RPs. Section 3 describes in detail the role of Gatekeeper and it's interfaces to all the protocols and the databases it interacts with. Section 3.3.2, Section 3.3.1 describes the static databases used and the interaction with the Gatekeeper in detail. 2.1. Manual Keying with the Gatekeeper Though the Gatekeeper defined offloads the SA management KMP databases interaction, the framework defined in this memo is consistent and can also be used purely for manual keying at pairwise RPs. The following diagram depicts the Gatekeeper module interfaces with all protocols involved i.e., Pairwise RPs which do security by themselves, TCP-based RPs which use TCP-AO, TCP-AO itself and the Crypto Key Tables database. Chunduri, et al. Expires August 29, 2013 [Page 6] Internet-Draft A framework for RPs to use IKEv2 KMP February 2013 +-------------+ |Pairwise RPs | |(BFD and |-----+ |other non-TCP| | |based RPS) | | +-------------+ | | | +-------------+ | | | +-------------+ +---->| | |TCP based |RP Config | | | RPs |---------->| | |(BGP/LDP/PCEP| | Gatekeeper | | /MSDP | +-----| | +-------------+ | | | | | | | | | | +------+------+ V |MKTs or +-------------+ | |Negotiated Parameters | | | +------v------+ | TCP-AO |-----+ | Crypto Key | | |MKTs | Tables | | | +-------------+ +-------------+ Figure 2: KARP: Using Manual Keying with Pairwise RPs As represented in Figure 2 above; here the Gatekeeper creates the static entries as per provisioned credentials including the Keys to protect RP messages either in the crypto key table database as specified in [ietf-karp-crypto-key-table]; or provisioning MKTs in the TCP-AO for TCP-based RPs. 3. The Gatekeeper The Gatekeeper primarily enables IKEv2 to support key and parameter negotiation, which are eventually used either by TCP-AO or by other pairwise RPs directly to protect the protocol messages. TCP-AO has a different model of security associations and key management than IPsec. IKEv2 is designed to support IPsec's model. The Gatekeeper maintains a Gatekeeper record (GKR) to keep track of either TCP-AO MKTs or negotiated parameters used by other pairwise RPs. For long-lived TCP connections MKTs can be rolled over by rekeying, hence creating new MKTs and installing them in TCP-AO. The Chunduri, et al. Expires August 29, 2013 [Page 7] Internet-Draft A framework for RPs to use IKEv2 KMP February 2013 GKR for TCP-based RPs, can be viewed as a superset of MKT i.e., it maintains and tracks the lifetime of the provisioned MKT, and includes other per-connection parameters needed by TCP-AO, such as algorithm, key length, etc. [RFC5926]. It also maintains the reference to PAD and Crypto Key Table entries to facilitate RP security parameters negotiation with IKEv2 KMP. The following sections define the Gatekeeper module interface between TCP-based RPs, TCP-AO, other pairwise RPs seeking to use IKEv2 KMP, interface to IKEv2 KMP itself and other key databases. 3.1. TCP-based RP interface to the Gatekeeper When a TCP-based routing protocol is configured to use TCP-AO with KMP (by not specifying the keys or through some other means), TCP connection identifiers, all configured Message Authentication Code (MAC) algorithms, all configured Key Derivation Function (KDF) parameters, rekey lifetime and the TCP option flag (i.e., all additional parameters specified in [RFC5926]) are populated in the Gatekeeper record. This information includes the reference to PAD, which has all the information to authorize and authenticate IKEv2 peer. Having this information at a central place is essential and enables the node to respond to the requests received from other IKEv2 peers in the network. In the case of manual keying, as there is no policy negotiation with the peer, the Gatekeeper record is populated with all the provisioned information at RP including the master keys. If the same routing protocol needs to differentiate transport sessions by securing separate TCP connections between the same endpoints then the TCP connection identifiers need to be provisioned appropriately in the Gatekeeper. The TCP connection identifiers could be either full socket pair i.e., local IP address, remote IP address, local TCP port, and remote TCP port or partial socket pair, indicated with wildcards as required. GKRs SHOULD thus support full or partial socket pair specification and this forms the basis for traffic selector negotiation with IKEv2 KMP [RFC5926]. In general, a full socket pair is not needed for negotiating the TCP-AO MKT with KMP. As specified in Section 3.1 of TCP-AO [RFC5925], socket pair values can be partially specified using ranges, masks, wildcards, or any other suitable indication. These provisioned socket pair parameters are supplied to KMP as context in which to negotiate traffic selectors for which the MKT or Master key should be used in TCP-AO. For more details on cases where a full socket pair is needed before opening the connection, please refer Section 7.1. Provisioning of the Gatekeeper record SHOULD be done before opening the TCP Chunduri, et al. Expires August 29, 2013 [Page 8] Internet-Draft A framework for RPs to use IKEv2 KMP February 2013 connection. From the RP interface, the record created in Gatekeeper contains only the RP's connection information, and this information is given to KMP (IKEv2) to obtain the negotiated parameters to protect the underlying TCP session by [RFC5925]. 3.1.1. TCP-AO interface to Gatekeeper TCP-AO expects an external entity to provision its MKTs in order to protect TCP sessions. The Gatekeeper module provides this function so that all TCP-based RPs can benefit from this common interface. The following are the details of the interface between TCP-AO and the GK: 1. After getting the negotiated parameters and mutually authenticated Master key from the KMP, the Gatekeeper inserts a corresponding MKT and parameters into TCP-AO. The session- specific parameters include negotiated Connection identifiers, MAC algorithms, KDFs, KeyIDs, the TCP option flag and the Master Key given by the KMP. 2. MKT IDs (as specified in Section 3.1 of TCP-AO [RFC5925]) require a SendID and a RecvID for each MKT, which are mutually agreed by the connection endpoints. These 1-byte quantities need to be part of the MKT when the KMP key(s) are populated in MKT. 3. For long-lived TCP sessions, the Gatekeeper removes the old MKTs from TCP-AO after rekeying the corresponding new MKTs, to continuously protect the underlying TCP sessions. 4. In general, restarted TCP sessions can use existing MKT in TCP-AO i.e., IKEv2 need not be retriggered, since new key and parameter negotiation is not needed due to the protection already provided by TCP-AO (refer Section 5.3.1 of TCP-AO [RFC5925]). However, if GKR and hence TCP-AO MKT is created with full socket pair (in other words without using ranges, masks, wildcards for socket pair values, for the cases as specified in Section 7.1), then IKEv2 needs to be retriggered to get the new master key for the corresponding restarted TCP session. 3.2. Other pairwise RPs interface to the Gatekeeper When a non-TCP-based RP is configured to use the KMP, before initiating connection with peer; connection identifiers, all configured Message Authentication Code (MAC) algorithms, all configured Key Derivation Function (KDF) parameters, rekey lifetime and reference to the PAD are populated in the Gatekeeper record. The RP connection identifiers at the Gatekeeper could be either full Chunduri, et al. Expires August 29, 2013 [Page 9] Internet-Draft A framework for RPs to use IKEv2 KMP February 2013 socket pair i.e., local IP address, remote IP address, local, remote transport ports and protocol or partial socket pair, indicated with wildcards as required. For non-TCP-cased RPs all negotiated parameters from KMP are populated in Crypto Key table database [ietf-karp-crypto-key-table]. The entries in this database as specified in [ietf-karp-crypto-key- table] are directly used by non-TCP-based RPs for securing the protocol messages. 3.3. KMP interaction with the Gatekeeper As an initiator, IKEv2 expects an external trigger that contains the information required to negotiate security associations. There needs to be a way to trigger the KMP to initiate negotiation with all the provisioned parameters of a Gatekeeper record by any pairwise RP. A similar trigger is also required to rekey, to maintain the negotiated SAs for long-lived connections. As a responder to the peer IKEv2 requests and CHILD_SA creation; Gatekeeper record is consulted through the reference in PAD as described in Section 3.3.2 . The purpose of this section is to define a common interface between the Gatekeeper and the IKEv2 KMP and also to list all the negotiated parameters to form an entry in the Crypto Key Tables as described in Section 3.3.1 . The two essential databases being interacted by the Gatekeeper are explained below. 3.3.1. Interaction with KARP Crypto Key Table KMP negotiated parameters are kept in the crypto key table database as specified in [ietf-karp-crypto-key-table]. In case of Manual keying, all the provisioned information including master key at RP is populated in the crypto key table database through the Gatekeeper to keep a common interface. The database is characterized as a table, where each row represents a single long-lived symmetric cryptographic key or Master key. The Gatekeeper record SHOULD have a reference to the Crypto Key Table Entry. One of the reasons to separate the negotiated parameters in a different table is to alleviate the population manually or through a some external source. Non-TCP-based RPs can eventually use crypto key table entries to secure the protocol messages as specified in [ietf-karp-crypto-key-table]. The following are the details: 1. At the time of a new connection, a trigger to the KMP occurs to negotiate the session-specific parameters with the needed Chunduri, et al. Expires August 29, 2013 [Page 10] Internet-Draft A framework for RPs to use IKEv2 KMP February 2013 information on MAC algorithm, Traffic Selectors, and additionally for the TCP-based RPs KDF parameter, the TCP option flag from the Gatekeeper record are given as input parameters. The Gatekeeper at the peer is expected to have similar provisioning in place for responding to the received KMP request. 2. A KMP session identifier, provided by a successful key negotiation by the KMP, needs to be stored and should be used when the Gatekeeper make decision based on the lifetime to rekey the existing session. 3. For TCP-based RPs, MKT IDs (as specified in Section 3.1 of TCP-AO [RFC5925]) require a SendID and a RecvID for each MKT, mutually agreed by the connection endpoints. These 1-byte quantities need to be negotiated by the KMP with the peer to populate in the MKT. These fields are populated as "LocalKeyName" and "PeerKeyName" in the Crypto Key Table entry. 4. Crypto Key Table "Peers" field SHOULD be populated with the peer IP address. 5. For TCP-based RPs, KMP-negotiated KDF parameters for each session used to generate traffic keys from master keys to be populated in MKT. The same is referred as "KDF" in a corresponding Crypto Key Table entry. 6. A KMP-negotiated MAC algorithm, MKT connection identifiers (negotiated traffic selectors) and optionally life time for traffic keys for each session, need to be populated in MKT. The same is referred as "AlgID" in corresponding Crypto Key Table entry. 7. The "Key" field defined in Crypto Key Table contains a long-lived symmetric cryptographic key or Master Key in the format of a lower-case hexadecimal string. The size of the Key depends on the KDF and the AlgID. 8. IKEv2 does not negotiate rekey lifetime and rekeying is based on local operator policy. The Gatekeeper adds this capability, tracking the key lifetime provisioned at RPs and explicitly triggering the KMP to rekey when indicated. This rekey trigger then creates a new MKT for the underlying TCP connection. Implementations can proactively negotiate a new MKT Master Key before the lifetime of the current Master key expires. Chunduri, et al. Expires August 29, 2013 [Page 11] Internet-Draft A framework for RPs to use IKEv2 KMP February 2013 3.3.2. Interface to the PAD The Peer Authorization Database (PAD) for IPsec is described in Section 4.4.3 of [RFC4301]. This section describes the embodiments of the same in the context of RP security associations and security policies provisioned at the routing protocols. This is still the link between policies provisioned at the routing protocol and the SAs created by IKEv2 KMP. Instead of the Security Policy Database (SPD), Gatekeeper record holds the data for traffic selectors for child SA creation. Gatekeeper Record PAD Entry +------------+ +------------+ | RP1 |------------------------>| Peer X | | | | | | | +--------------->| | +------------+ / +------------+ / +------------+ / | | / | RP2 |---+ | | +------------+ +------------+ +------------+ | | | | | RP1/RP3 |------------------------>| Peer Y | | | | | +------------+ +------------+ Figure 3: KARP KMP: Gatekeeper interface to the PAD As shown in Figure 3, multiple RPs can point to the same peer and in this case, a PAD entry holds the reference to both the corresponding Gatekeeper records. The PAD entry for the IKEv2 peer is used to constrain the creation of child SAs; specifically, the PAD entry specifies how the Gatekeeper record is searched using a traffic selector proposal from a peer. For CHILD_SA creation, peer IP addresses asserted in traffic selector payloads SHOULD be used for Gatekeeper record lookups based on the remote IP address field portion of a Gatekeeper Record entry. Chunduri, et al. Expires August 29, 2013 [Page 12] Internet-Draft A framework for RPs to use IKEv2 KMP February 2013 3.4. Impact of Policy changes Once the routing session is secured either by TCP-AO or non-TCP-based RP itself, any security policy changes initiated by the operator at RP MUST cause a tear down of the existing session and MUST be replaced with a new CHILD_SA at IKEV2 KMP and corresponding new MKT at TCP-AO. Similarly, any changes in the peer Authentication data at PAD MUST cause re-authentication of the peer at IKEv2 KMP with changed credentials and also due to this change, all CHILD_SAs/MKTs need to re-negotiated. 4. IANA Considerations This document defines no new namespaces. 5. Security Considerations This document does not introduce any new security threats for IKEv2 [RFC5996] or TCP-AO [RFC5925]. For more detailed security considerations please refer the Security Considerations section of the KARP Design Guide [RFC6518] document as well as KARP threat document [I-D.ietf-karp-threats-reqs]. 6. Acknowledgements The authors would like to thank Joel Halpern for his initial discussions and providing feedback on the document. The authors also thank Tero Kivinin and Dan Harkins for reviewing the document and Ron Bonica for his initial requirement discussions. Thanks to Sam Hartman for his KARP working group discussions on this topic. The Gatekeeper module is originally proposed by Joe Touch. 7. Appendix A 7.1. BGP Multi Session and transport level differentiation [ietf-idr-bgp-multisession] describes MP-BGP, which uses multiple TCP sessions between a pair of BGP speakers. Each TCP session is used to exchange routes related by some session-based attribute, such as AFI/ SAFI. The reason transport level distinction is required could be because of operator policy. Though it is less likely to see different MAC/KDF parameters for each of these sessions, it is possible rekey lifetimes or TCP option flags for TCP-AO can be different for each of these AFI/SAFI based sessions. Chunduri, et al. Expires August 29, 2013 [Page 13] Internet-Draft A framework for RPs to use IKEv2 KMP February 2013 If transport level separation is required for all sessions between a pair of BGP speakers, a unique and full socket pair (i.e., a local IP address, a remote IP address, a local TCP port, and a remote TCP port) MUST be known before establishing a TCP connection. The full socket pair is required for both unique MKT creation in TCP-AO, as well as for the KMP to negotiate unique Master keys for each connection. The use of different IP addresses to differentiate connections in multi session BGP is discouraged in [ietf-idr-bgp-multisession] and the destination port is always BGP. As a result, the only option for transport level differentiation is by knowing the source port of the connection being initiated. This is required to negotiate unique KMP SAs by the Gatekeeper, as well as to configure unique TCP-AO MKTs for each TCP connection. How source port lock-down is done is beyond the scope of this document (this is an implementation issue) and this can be achieved in many different ways before making the TCP connection. The Gatekeeper interface, defined in Section 3, is oblivious to this issue and can well accommodate this requirement. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010. [RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms for the TCP Authentication Option (TCP-AO)", RFC 5926, June 2010. [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010. [RFC5998] Eronen, P., Tschofenig, H., and Y. Sheffer, "An Extension for EAP-Only Authentication in IKEv2", RFC 5998, September 2010. 8.2. Informative References [I-D.ietf-idr-bgp-multisession] Scudder, J., Appanna, C., and I. Varlashkin, "Multisession Chunduri, et al. Expires August 29, 2013 [Page 14] Internet-Draft A framework for RPs to use IKEv2 KMP February 2013 BGP", draft-ietf-idr-bgp-multisession-07 (work in progress), September 2012. [I-D.ietf-karp-crypto-key-table] Housley, R., Polk, T., Hartman, S., and D. Zhang, "Database of Long-Lived Symmetric Cryptographic Keys", draft-ietf-karp-crypto-key-table-04 (work in progress), October 2012. [I-D.ietf-karp-routing-tcp-analysis] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of BGP, LDP, PCEP and MSDP Issues According to KARP Design Guide", draft-ietf-karp-routing-tcp-analysis-06 (work in progress), December 2012. [I-D.ietf-karp-threats-reqs] Lebovitz, G., Bhatia, M., and B. Weis, "Keying and Authentication for Routing Protocols (KARP) Overview, Threats, and Requirements", draft-ietf-karp-threats-reqs-07 (work in progress), December 2012. [I-D.mahesh-karp-rkmp] Jethanandani, M., Weis, B., Patel, K., Zhang, D., Hartman, S., Chunduri, U., Tian, A., and J. Touch, "Negotiation for Keying Pairwise Routing Protocols in IKEv2", draft-mahesh-karp-rkmp-04 (work in progress), February 2013. [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005. [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC4746] Clancy, T. and W. Arbaugh, "Extensible Authentication Protocol (EAP) Password Authenticated Exchange", RFC 4746, November 2006. Chunduri, et al. Expires August 29, 2013 [Page 15] Internet-Draft A framework for RPs to use IKEv2 KMP February 2013 [RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA)", RFC 4754, January 2007. [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007. [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009. [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010. [RFC5931] Harkins, D. and G. Zorn, "Extensible Authentication Protocol (EAP) Authentication Using Only a Password", RFC 5931, August 2010. [RFC6124] Sheffer, Y., Zorn, G., Tschofenig, H., and S. Fluhrer, "An EAP Authentication Method Based on the Encrypted Key Exchange (EKE) Protocol", RFC 6124, February 2011. [RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines", RFC 6518, February 2012. Authors' Addresses Uma Chunduri Ericsson Inc. 300 Holger Way San Jose, California 95134 USA Phone: +1 (408) 750-5678 Email: uma.chunduri@ericsson.com Albert Tian Ericsson Inc. 300 Holger Way San Jose, California 95134 USA Phone: +1 (408) 750-5210 Email: albert.tian@ericsson.com Chunduri, et al. Expires August 29, 2013 [Page 16] Internet-Draft A framework for RPs to use IKEv2 KMP February 2013 Joe Touch USC/ISI 4676 Admiralty Way, Marina del Rey, California 90292-6695 USA Phone: +1 (310) 448-9151 Email: touch@isi.edu Chunduri, et al. Expires August 29, 2013 [Page 17]