idnits 2.17.1 draft-chunduri-karp-using-ikev2-with-tcp-ao-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 5, 2014) is 3733 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5998' is defined on line 618, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-idr-bgp-multisession' is defined on line 624, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-karp-crypto-key-table' is defined on line 629, but no explicit reference was found in the text == Unused Reference: 'I-D.mahesh-karp-rkmp' is defined on line 641, but no explicit reference was found in the text == Unused Reference: 'RFC3618' is defined on line 647, but no explicit reference was found in the text == Unused Reference: 'RFC3748' is defined on line 650, but no explicit reference was found in the text == Unused Reference: 'RFC4107' is defined on line 654, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 657, but no explicit reference was found in the text == Unused Reference: 'RFC4746' is defined on line 663, but no explicit reference was found in the text == Unused Reference: 'RFC4754' is defined on line 667, but no explicit reference was found in the text == Unused Reference: 'RFC5036' is defined on line 671, but no explicit reference was found in the text == Unused Reference: 'RFC5440' is defined on line 674, but no explicit reference was found in the text == Unused Reference: 'RFC5931' is defined on line 681, but no explicit reference was found in the text == Unused Reference: 'RFC6124' is defined on line 685, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) == Outdated reference: A later version (-06) exists of draft-mahesh-karp-rkmp-05 Summary: 1 error (**), 0 flaws (~~), 16 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Working Group U. Chunduri 3 Internet-Draft A. Tian 4 Intended status: Informational Ericsson Inc. 5 Expires: August 9, 2014 J. Touch 6 USC/ISI 7 February 5, 2014 9 A framework for RPs to use IKEv2 KMP 10 draft-chunduri-karp-using-ikev2-with-tcp-ao-06 12 Abstract 14 This document describes a mechanism to enable using IKEv2 with TCP- 15 AO, which may also be of more general use to other pairwise Routing 16 Protocols. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on August 9, 2014. 35 Copyright Notice 37 Copyright (c) 2014 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 54 1.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Motivation and Overview . . . . . . . . . . . . . . . . . . . 4 56 2.1. Manual Keying with the Gatekeeper . . . . . . . . . . . . 6 57 3. The Gatekeeper . . . . . . . . . . . . . . . . . . . . . . . 7 58 3.1. TCP-based RP interface to the Gatekeeper . . . . . . . . 8 59 3.1.1. TCP-AO interface to Gatekeeper . . . . . . . . . . . 9 60 3.2. Other pairwise RPs interface to the Gatekeeper . . . . . 9 61 3.3. KMP interaction with the Gatekeeper . . . . . . . . . . . 10 62 3.3.1. Interaction with KARP Crypto Key Table . . . . . . . 11 63 3.3.2. Interface to the PAD . . . . . . . . . . . . . . . . 12 64 3.4. Impact of Policy changes . . . . . . . . . . . . . . . . 13 65 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 67 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 68 7. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . 13 69 7.1. BGP Multi Session and transport level differentiation . . 13 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 71 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 72 8.2. Informative References . . . . . . . . . . . . . . . . . 14 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 75 1. Introduction 77 This document analyzes the pairwise Routing Protocol (RP) 78 requirements needed to integrate the IKEv2[RFC5996] KMP and provides 79 a framework to achieve this. 81 The KARP design guide [RFC6518] suggests various requirements and 82 options for obtaining keys to protect the routing protocols and 83 recommends using a Key Management Protocol (KMP) to automate key 84 establishment, as well as rekeying to continuously protect the 85 routing protocols. However, there are few gaps which need to be 86 addressed for serene integration of IKEv2 KMP and any pairwise 87 routing protocol either securing messages by RP itself or through a 88 security protocol like TCP-AO [RFC5925]. For example, there are 89 differences in both established protocols like IKEv2 and TCP-AO on 90 how the Security Associations (SAs) to be maintained or there is a 91 need for common framework in general on how the pairwise RPs can 92 further offload SA management. This memo addresses these gaps by 93 providing a common framework to interact pairwise RPs and IKEv2 KMP. 94 The choice of IKEv2 KMP is based on the WG consensus. 96 A major portion of pairwise RPs analyzed in this document use TCP at 97 transport layer and may use TCP-AO[RFC5925] to protect the RP 98 messages. There are other RPs, which use pairwise unicast signaling 99 between the routing peers (for e.g., BFD [RFC5880]) and don't use TCP 100 at transport layer. This memo also describes the interface for these 101 RPs to integrate with IKEv2 KMP. 103 This document introduces a new Gatekeeper (GK) module, which provides 104 a common interface and minimizes the changes for all pairwise routing 105 protocols to be integrated with KMP. The Gatekeeper module does the 106 SA management and interaction with KMP as well as TCP-AO protocol or 107 the RP itself (for the RPs which don't use TCP-AO). The purpose of 108 the Gatekeeper is to act as a shim between IKEv2 and RP/TCP-AO, so 109 that RP/TCP-AO and the Gatekeeper together act like IPsec to IKEv2 110 (since IKEv2 is designed to tightly interact with IPsec). This 111 document defines this common interface between pairwise RPs with 112 Gatekeeper and IKEv2 [RFC5996]. The common interface defined here 113 also serves the pairwise RPs with manual keying and this is further 114 described in Section 2.1. 116 Currently IKEv2 can establish only Security Association (SA) for 117 IPsec. A few extensions are needed for IKEv2 to establish SA for 118 pairwise RPs which either protect protocol packets by themselves or 119 use TCP-AO for protection. [mahesh-karp-rkmp] discusses the summary 120 of extensions required for IKEv2 protocol for key establishment, 121 traffic selectors negotiation and SA establishment to support the 122 keying and parameters needed by RP or TCP-AO. 124 1.1. Requirements Language 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in RFC 2119 [RFC2119]. 130 1.2. Acronyms 132 BGP - Border Gateway Protocol 134 GKR - Gatekeeper Record 136 IKEv2 - Internet Key Exchange Protocol Version 2 138 IPsec - Security Architecture for the Internet Protocol 140 KDF - Key Derivation Function as defined in TCP-AO 142 KMP - Key Management Protocol (auto key management) 144 LDP - Label Distribution Protocol 145 MKM - Manual Key management Protocols 147 MKT - Master Key Tuples as defined in TCP-AO 149 MSDP - Multicast Source Discovery Protocol 151 PAD - Peer Authorization Database 153 PCEP - Path Computation Element Communication Protocol 155 RP - Routing Protocol 157 SA - Security Association 159 TCP-AO - TCP Authentication Option 161 2. Motivation and Overview 163 The motivation of this document is to offload Security Association 164 (SA) management and to provide a generic and common interface for all 165 pairwise RPs to integrate with KMPs in general and specifically with 166 IKEv2 KMP. 168 IKEv2 assumes IPsec triggers new SA requests, manages SA timers and 169 rekeys SAs as needed to protect the actual traffic. For e.g., for 170 TCP-based RPs, TCP-AO assumes an external key manager, which could 171 support functions like Master key triggering, SA timers, and rekey 172 triggering to get the parameters required including Master key to 173 protect the TCP session. To bridge the gap between IKEv2 and TCP-AO 174 or to simplify pairwise RPs which don't use TCP-AO, this document 175 defines a Gatekeeper module as described in Section 3. 177 The following diagram depicts how, the Gatekeeper module interfaces 178 with all protocols involved i.e., Pairwise RPs which do security by 179 themselves, TCP-based RPs which use TCP-AO for providing security, 180 IKEv2 KMP, and TCP-AO itself. This also shows the interaction with 181 various databases viz., Peer Authorization Database (PAD) and Crypto 182 Key Tables with the Gatekeeper. 184 +-------------+ 185 |Pairwise RPs | +-------------+ 186 |(BFD and |-----+ | PAD | 187 |other non-TCP| | +-->--| |----+ 188 |based RPS) | | | +-------------+ | 189 +-------------+ | | v 190 | | | 191 | +-------------+ +------------+ 192 | | | | | 193 +-------------+ +---->| | Trigger | | 194 |TCP based |RP Config | |----------->| | 195 | RPs |---------->| | | | 196 |(BGP/LDP/PCEP| | Gatekeeper | | IKEv2 KMP | 197 | /MSDP | +-----| | Negotiated | | 198 +-------------+ | | | Parameters | | 199 | | |------------| | 200 | | | | | 201 | +------+------+ +------------+ 202 v | MKTs or 203 +-------------+ | | Negotiated Parameters 204 | | | +------v------+ 205 | TCP-AO |-----+ | Crypto Key | 206 | |MKTs | Tables | 207 | | +-------------+ 208 +-------------+ 210 Figure 1: KARP KMP: Using IKEv2 with Pairwise RPs 212 In Figure 1, before initiating the RP messaging to the peer, non-TCP- 213 based RPs communicate the provisioned configuration to Gatekeeper 214 module. Similarly, before initiating the TCP connection, all TCP- 215 based RPs communicate the provisioned configuration to Gatekeeper 216 module. A entry in the KMP peer authentication/authorization is 217 provisioned in PAD as defined in Section 4.4.3 of [RFC4301] and 218 pointer to this entry SHOULD be part of the RP configuration. This 219 facilitates Gatekeeper to issue a corresponding request, with all the 220 proposed alternatives at the RP to the IKEv2 KMP. This enables the 221 IKEv2 to negotiate the needed security policy parameters and derive 222 Keying material to be used by RPs. When the local peer is acting as 223 a responder, security policy information populated at the Gatekeeper 224 can be referenced through PAD by IKEv2 KMP to create the CHILD_SAs 225 ([RFC5996]). Either way, the negotiated SA's are kept in the crypto 226 key table database as specified in [ietf-karp-crypto-key-table] and 227 this information is the basis for provisioning MKTs in case of TCP-AO 228 or applying security by BFD [RFC5880] and other non-TCP based RPs 229 themselves. 231 The Gatekeeper can be viewed as a module, which maintains the KMP 232 negotiated SAs as per the provisioning information at RPs and 233 initiates rekey triggers as needed. For TCP-AO, the rekey triggers 234 helps provision new MKTs for the long-lived TCP sessions protected by 235 TCP-AO. The Gatekeeper also installs these new keys in TCP-AO 236 consistent with TCP-AO's support for key changes. For non-TCP-based 237 RPs as shown in the above diagram, the Gatekeeper populates the new 238 keys in crypto key tables to be referenced for securing the protocol 239 messages. 241 Section 3 describes in detail the role of Gatekeeper and it's 242 interfaces to all the protocols and the databases it interacts with. 243 Section 3.3.2, Section 3.3.1 describes the static databases used and 244 the interaction with the Gatekeeper in detail. 246 2.1. Manual Keying with the Gatekeeper 248 Though the Gatekeeper defined offloads the SA management KMP 249 databases interaction, the framework defined in this memo is 250 consistent and can also be used purely for manual keying at pairwise 251 RPs. The following diagram depicts the Gatekeeper module interfaces 252 with all protocols involved i.e., Pairwise RPs which do security by 253 themselves, TCP-based RPs which use TCP-AO, TCP-AO itself and the 254 Crypto Key Tables database. 256 +-------------+ 257 |Pairwise RPs | 258 |(BFD and |-----+ 259 |other non-TCP| | 260 |based RPS) | | 261 +-------------+ | 262 | 263 | +-------------+ 264 | | | 265 +-------------+ +---->| | 266 |TCP based |RP Config | | 267 | RPs |---------->| | 268 |(BGP/LDP/PCEP| | Gatekeeper | 269 | /MSDP | +-----| | 270 +-------------+ | | | 271 | | | 272 | | | 273 | +------+------+ 274 v | MKTs or 275 +-------------+ | | Configured Parameters 276 | | | +------v------+ 277 | TCP-AO |-----+ | Crypto Key | 278 | |MKTs | Tables | 279 | | +-------------+ 280 +-------------+ 282 Figure 2: KARP: Using Manual Keying with Pairwise RPs 284 As represented in Figure 2 above; here the Gatekeeper creates the 285 static entries as per provisioned credentials including the Keys to 286 protect RP messages either in the crypto key table database as 287 specified in [ietf-karp-crypto-key-table]; or provisioning MKTs in 288 the TCP-AO for TCP-based RPs. 290 3. The Gatekeeper 292 The Gatekeeper primarily enables IKEv2 to support key and parameter 293 negotiation, which are eventually used either by TCP-AO or by other 294 pairwise RPs directly to protect the protocol messages. TCP-AO has a 295 different model of security associations and key management than 296 IPsec. IKEv2 is designed to support IPsec's model. 298 The Gatekeeper maintains a Gatekeeper record (GKR) to keep track of 299 either TCP-AO MKTs or negotiated parameters used by other pairwise 300 RPs. For long-lived TCP connections MKTs can be rolled over by 301 rekeying, hence creating new MKTs and installing them in TCP-AO. The 302 GKR for TCP-based RPs, can be viewed as a superset of MKT i.e., it 303 maintains and tracks the lifetime of the provisioned MKT, and 304 includes other per-connection parameters needed by TCP-AO, such as 305 algorithm, key length, etc. [RFC5926]. It also maintains the 306 reference to PAD and Crypto Key Table entries to facilitate RP 307 security parameters negotiation with IKEv2 KMP. 309 The following sections define the Gatekeeper module interface between 310 TCP-based RPs, TCP-AO, other pairwise RPs seeking to use IKEv2 KMP, 311 interface to IKEv2 KMP itself and other key databases. 313 3.1. TCP-based RP interface to the Gatekeeper 315 When a TCP-based routing protocol is configured to use TCP-AO with 316 KMP (by not specifying the keys or through some other means), TCP 317 connection identifiers, all configured Message Authentication Code 318 (MAC) algorithms, all configured Key Derivation Function (KDF) 319 parameters, rekey lifetime and the TCP option flag (i.e., all 320 additional parameters specified in [RFC5926]) are populated in the 321 Gatekeeper record. This information includes the reference to PAD, 322 which has all the information to authorize and authenticate IKEv2 323 peer. Having this information at a central place is essential and 324 enables the node to respond to the requests received from other IKEv2 325 peers in the network. In the case of manual keying, as there is no 326 policy negotiation with the peer, the Gatekeeper record is populated 327 with all the provisioned information at RP including the master keys. 329 If the same routing protocol needs to differentiate transport 330 sessions by securing separate TCP connections between the same 331 endpoints then the TCP connection identifiers need to be provisioned 332 appropriately in the Gatekeeper. The TCP connection identifiers 333 could be either full socket pair i.e., local IP address, remote IP 334 address, local TCP port, and remote TCP port or partial socket pair, 335 indicated with wildcards as required. GKRs SHOULD thus support full 336 or partial socket pair specification and this forms the basis for 337 traffic selector negotiation with IKEv2 KMP [RFC5926]. 339 In general, a full socket pair is not needed for negotiating the TCP- 340 AO MKT with KMP. As specified in Section 3.1 of TCP-AO [RFC5925], 341 socket pair values can be partially specified using ranges, masks, 342 wildcards, or any other suitable indication. These provisioned 343 socket pair parameters are supplied to KMP as context in which to 344 negotiate traffic selectors for which the MKT or Master key should be 345 used in TCP-AO. 347 For more details on cases where a full socket pair is needed before 348 opening the connection, please refer Section 7.1. Provisioning of 349 the Gatekeeper record SHOULD be done before opening the TCP 350 connection. From the RP interface, the record created in Gatekeeper 351 contains only the RP's connection information, and this information 352 is given to KMP (IKEv2) to obtain the negotiated parameters to 353 protect the underlying TCP session by [RFC5925]. 355 3.1.1. TCP-AO interface to Gatekeeper 357 TCP-AO expects an external entity to provision its MKTs in order to 358 protect TCP sessions. The Gatekeeper module provides this function 359 so that all TCP-based RPs can benefit from this common interface. 361 The following are the details of the interface between TCP-AO and the 362 GK: 364 1. After getting the negotiated parameters and mutually 365 authenticated Master key from the KMP, the Gatekeeper inserts a 366 corresponding MKT and parameters into TCP-AO. The session- 367 specific parameters include negotiated Connection identifiers, 368 MAC algorithms, KDFs, KeyIDs, the TCP option flag and the Master 369 Key given by the KMP. 371 2. MKT IDs (as specified in Section 3.1 of TCP-AO [RFC5925]) require 372 a SendID and a RecvID for each MKT, which are mutually agreed by 373 the connection endpoints. These 1-byte quantities need to be 374 part of the MKT when the KMP key(s) are populated in MKT. 376 3. For long-lived TCP sessions, the Gatekeeper removes the old MKTs 377 from TCP-AO after rekeying the corresponding new MKTs, to 378 continuously protect the underlying TCP sessions. 380 4. In general, restarted TCP sessions can use existing MKT in TCP-AO 381 i.e., IKEv2 need not be retriggered, since new key and parameter 382 negotiation is not needed due to the protection already provided 383 by TCP-AO (refer Section 5.3.1 of TCP-AO [RFC5925]). However, if 384 GKR and hence TCP-AO MKT is created with full socket pair (in 385 other words without using ranges, masks, wildcards for socket 386 pair values, for the cases as specified in Section 7.1), then 387 IKEv2 needs to be retriggered to get the new master key for the 388 corresponding restarted TCP session. 390 3.2. Other pairwise RPs interface to the Gatekeeper 392 When a non-TCP-based RP is configured to use the KMP, before 393 initiating connection with peer; connection identifiers, all 394 configured Message Authentication Code (MAC) algorithms, all 395 configured Key Derivation Function (KDF) parameters, rekey lifetime 396 and reference to the PAD are populated in the Gatekeeper record. The 397 RP connection identifiers at the Gatekeeper could be either full 398 socket pair i.e., local IP address, remote IP address, local, remote 399 transport ports and protocol or partial socket pair, indicated with 400 wildcards as required. 402 For non-TCP-based RPs all negotiated parameters from KMP are 403 populated in Crypto Key table database [ietf-karp-crypto-key-table]. 404 The entries in this database as specified in [ietf-karp-crypto-key- 405 table] SHOULD directly be used by non-TCP-based RPs for securing the 406 protocol messages. 408 3.3. KMP interaction with the Gatekeeper 410 As an initiator, IKEv2 expects an external trigger that contains the 411 information required to negotiate security associations. There needs 412 to be a way to trigger the KMP to initiate negotiation with all the 413 provisioned parameters of a Gatekeeper record by any pairwise RP. A 414 similar trigger is also required to rekey, to maintain the negotiated 415 SAs for long-lived connections. As a responder to the peer IKEv2 416 requests and CHILD_SA creation; Gatekeeper record is consulted 417 through the reference in PAD as described in Section 3.3.2 . 419 The purpose of this section is to define a common interface between 420 the Gatekeeper and the IKEv2 KMP and also to list all the negotiated 421 parameters to form an entry in the Crypto Key Tables as described in 422 Section 3.3.1 . 424 The following are the details: 426 1. At the time of a new connection, a trigger to the KMP occurs to 427 negotiate the session-specific parameters with the needed 428 information on MAC algorithm, Traffic Selectors, and additionally 429 for the TCP-based RPs KDF parameter, the TCP option flag from the 430 Gatekeeper record are given as input parameters. The Gatekeeper 431 at the peer is expected to have similar provisioning in place for 432 responding to the received KMP request. 434 2. A KMP session identifier, provided by a successful key 435 negotiation by the KMP, needs to be stored and should be used 436 when the Gatekeeper make decision based on the lifetime to rekey 437 the existing session. 439 3. For TCP-based RPs, MKT IDs (as specified in Section 3.1 of TCP-AO 440 [RFC5925]) require a SendID and a RecvID for each MKT, mutually 441 agreed by the connection endpoints. These 1-byte quantities need 442 to be negotiated by the KMP with the peer to populate in the MKT. 443 These fields are populated as "LocalKeyName" and "PeerKeyName" in 444 the Crypto Key Table entry. 446 4. Crypto Key Table "Peers" field SHOULD be populated with the peer 447 IP address. 449 5. For TCP-based RPs, KMP-negotiated KDF parameters for each session 450 used to generate traffic keys from master keys to be populated in 451 MKT. The same is referred as "KDF" in a corresponding Crypto Key 452 Table entry. 454 6. A KMP-negotiated MAC algorithm, MKT connection identifiers 455 (negotiated traffic selectors) and optionally life time for 456 traffic keys for each session, need to be populated in MKT. The 457 same is referred as "AlgID" in corresponding Crypto Key 458 Table entry. 460 7. The "Key" field defined in Crypto Key Table contains a long-lived 461 symmetric cryptographic key or Master Key in the format of a 462 lower-case hexadecimal string. The size of the Key depends on 463 the KDF and the AlgID. 465 8. IKEv2 does not negotiate rekey lifetime and rekeying is based on 466 local operator policy. The Gatekeeper MUST add this capability 467 for tracking the key lifetime provisioned at RPs and explicitly 468 triggering the KMP to rekey when indicated. This rekey trigger 469 then creates a new MKT for the underlying TCP connection. 470 Implementations can proactively negotiate a new MKT Master Key 471 before the lifetime of the current Master key expires. 473 The two essential databases being interacted by the Gatekeeper are 474 explained below. 476 3.3.1. Interaction with KARP Crypto Key Table 478 KMP negotiated parameters are kept in the crypto key table database 479 as specified in [ietf-karp-crypto-key-table]. In case of Manual 480 keying, all the provisioned information including master key at RP is 481 populated in the crypto key table database through the Gatekeeper to 482 keep a common interface. The database is characterized as a table, 483 where each row represents a single long-lived symmetric cryptographic 484 key or Master key. The Gatekeeper record SHOULD have a reference to 485 the Crypto Key Table Entry. One of the reasons to separate the 486 negotiated parameters in a different table is to alleviate the 487 population manually or through an external source. Non-TCP-based RPs 488 can eventually use crypto key table entries to secure the protocol 489 messages as specified in [ietf-karp-crypto-key-table]. 491 3.3.2. Interface to the PAD 493 The Peer Authorization Database (PAD) for IPsec is described in 494 Section 4.4.3 of [RFC4301]. This section describes the embodiments 495 of the same in the context of RP security associations and security 496 policies provisioned at the routing protocols. This is still the 497 link between policies provisioned at the routing protocol and the SAs 498 created by IKEv2 KMP. Instead of the Security Policy Database (SPD), 499 Gatekeeper record holds the data for traffic selectors for child SA 500 creation. 502 Gatekeeper Record PAD Entry 504 +------------+ +------------+ 505 | RP1 |------------------------>| Peer X | 506 | | | | 507 | | +--------------->| | 508 +------------+ / +------------+ 509 / 510 +------------+ / 511 | | / 512 | RP2 |---+ 513 | | 514 +------------+ 516 +------------+ +------------+ 517 | | | | 518 | RP1/RP3 |------------------------>| Peer Y | 519 | | | | 520 +------------+ +------------+ 522 Figure 3: KARP KMP: Gatekeeper interface to the PAD 524 As shown in Figure 3, multiple RPs can point to the same peer and in 525 this case, a PAD entry holds the reference to both the corresponding 526 Gatekeeper records. The PAD entry for the IKEv2 peer is used to 527 constrain the creation of child SAs; specifically, the PAD entry 528 specifies how the Gatekeeper record is searched using a traffic 529 selector proposal from a peer. For CHILD_SA creation, peer IP 530 addresses asserted in traffic selector payloads SHOULD be used for 531 Gatekeeper record lookups based on the remote IP address field 532 portion of a Gatekeeper Record entry. 534 3.4. Impact of Policy changes 536 Once the routing session is secured either by TCP-AO or non-TCP-based 537 RP itself, any security policy changes initiated by the operator at 538 RP MUST cause a tear down of the existing session and MUST be 539 replaced with a new CHILD_SA at IKEV2 KMP and corresponding new MKT 540 at TCP-AO. Similarly, any changes in the peer Authentication data at 541 PAD MUST cause re-authentication of the peer at IKEv2 KMP with 542 changed credentials and also due to this change, all CHILD_SAs/MKTs 543 need to re-negotiated. 545 4. IANA Considerations 547 This document defines no new namespaces. 549 5. Security Considerations 551 This document does not introduce any new security threats for IKEv2 552 [RFC5996] or TCP-AO [RFC5925]. For more detailed security 553 considerations please refer the Security Considerations section of 554 the KARP Design Guide [RFC6518] document as well as KARP threat 555 document [I-D.ietf-karp-threats-reqs]. 557 6. Acknowledgements 559 The authors would like to thank Joel Halpern for his initial 560 discussions and providing feedback on the document. The authors also 561 thank Tero Kivinin and Dan Harkins for reviewing the document and Ron 562 Bonica for his initial requirement discussions. Thanks to Sam 563 Hartman for his KARP working group discussions on this topic. The 564 Gatekeeper module is originally proposed by Joe Touch. 566 7. Appendix A 568 7.1. BGP Multi Session and transport level differentiation 570 [ietf-idr-bgp-multisession] describes MP-BGP, which uses multiple TCP 571 sessions between a pair of BGP speakers. Each TCP session is used to 572 exchange routes related by some session-based attribute, such as AFI/ 573 SAFI. The reason transport level distinction is required could be 574 because of operator policy. Though it is less likely to see 575 different MAC/KDF parameters for each of these sessions, it is 576 possible rekey lifetimes or TCP option flags for TCP-AO can be 577 different for each of these AFI/SAFI based sessions. 579 If transport level separation is required for all sessions between a 580 pair of BGP speakers, a unique and full socket pair (i.e., a local IP 581 address, a remote IP address, a local TCP port, and a remote TCP 582 port) MUST be known before establishing a TCP connection. The full 583 socket pair is required for both unique MKT creation in TCP-AO, as 584 well as for the KMP to negotiate unique Master keys for each 585 connection. 587 The use of different IP addresses to differentiate connections in 588 multi session BGP is discouraged in [ietf-idr-bgp-multisession] and 589 the destination port is always BGP. As a result, the only option for 590 transport level differentiation is by knowing the source port of the 591 connection being initiated. This is required to negotiate unique KMP 592 SAs by the Gatekeeper, as well as to configure unique TCP-AO MKTs for 593 each TCP connection. How source port lock-down is done is beyond the 594 scope of this document (this is an implementation issue) and this can 595 be achieved in many different ways before making the TCP connection. 597 The Gatekeeper interface, defined in Section 3, is oblivious to this 598 issue and can well accommodate this requirement. 600 8. References 602 8.1. Normative References 604 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 605 Requirement Levels", BCP 14, RFC 2119, March 1997. 607 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 608 Authentication Option", RFC 5925, June 2010. 610 [RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms 611 for the TCP Authentication Option (TCP-AO)", RFC 5926, 612 June 2010. 614 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 615 "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 616 5996, September 2010. 618 [RFC5998] Eronen, P., Tschofenig, H., and Y. Sheffer, "An Extension 619 for EAP-Only Authentication in IKEv2", RFC 5998, September 620 2010. 622 8.2. Informative References 624 [I-D.ietf-idr-bgp-multisession] 625 Scudder, J., Appanna, C., and I. Varlashkin, "Multisession 626 BGP", draft-ietf-idr-bgp-multisession-07 (work in 627 progress), September 2012. 629 [I-D.ietf-karp-crypto-key-table] 630 Housley, R., Polk, T., Hartman, S., and D. Zhang, 631 "Database of Long-Lived Symmetric Cryptographic Keys", 632 draft-ietf-karp-crypto-key-table-10 (work in progress), 633 December 2013. 635 [I-D.ietf-karp-threats-reqs] 636 Lebovitz, G., Bhatia, M., and B. Weis, "Keying and 637 Authentication for Routing Protocols (KARP) Overview, 638 Threats, and Requirements", draft-ietf-karp-threats- 639 reqs-07 (work in progress), December 2012. 641 [I-D.mahesh-karp-rkmp] 642 Jethanandani, M., Weis, B., Patel, K., Zhang, D., Hartman, 643 S., Chunduri, U., Tian, A., and J. Touch, "Negotiation for 644 Keying Pairwise Routing Protocols in IKEv2", draft-mahesh- 645 karp-rkmp-05 (work in progress), November 2013. 647 [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery 648 Protocol (MSDP)", RFC 3618, October 2003. 650 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 651 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 652 3748, June 2004. 654 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 655 Key Management", BCP 107, RFC 4107, June 2005. 657 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 658 Protocol 4 (BGP-4)", RFC 4271, January 2006. 660 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 661 Internet Protocol", RFC 4301, December 2005. 663 [RFC4746] Clancy, T. and W. Arbaugh, "Extensible Authentication 664 Protocol (EAP) Password Authenticated Exchange", RFC 4746, 665 November 2006. 667 [RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using 668 the Elliptic Curve Digital Signature Algorithm (ECDSA)", 669 RFC 4754, January 2007. 671 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 672 Specification", RFC 5036, October 2007. 674 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 675 (PCE) Communication Protocol (PCEP)", RFC 5440, March 676 2009. 678 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 679 (BFD)", RFC 5880, June 2010. 681 [RFC5931] Harkins, D. and G. Zorn, "Extensible Authentication 682 Protocol (EAP) Authentication Using Only a Password", RFC 683 5931, August 2010. 685 [RFC6124] Sheffer, Y., Zorn, G., Tschofenig, H., and S. Fluhrer, "An 686 EAP Authentication Method Based on the Encrypted Key 687 Exchange (EKE) Protocol", RFC 6124, February 2011. 689 [RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for 690 Routing Protocols (KARP) Design Guidelines", RFC 6518, 691 February 2012. 693 Authors' Addresses 695 Uma Chunduri 696 Ericsson Inc. 697 300 Holger Way 698 San Jose, California 95134 699 USA 701 Phone: +1 (408) 750-5678 702 Email: uma.chunduri@ericsson.com 704 Albert Tian 705 Ericsson Inc. 706 300 Holger Way 707 San Jose, California 95134 708 USA 710 Phone: +1 (408) 750-5210 711 Email: albert.tian@ericsson.com 713 Joe Touch 714 USC/ISI 715 4676 Admiralty Way, 716 Marina del Rey, California 90292-6695 717 USA 719 Phone: +1 (310) 448-9151 720 Email: touch@isi.edu