idnits 2.17.1 draft-mahesh-karp-kmprp-00.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 (July 1, 2011) is 4683 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBD' is mentioned on line 452, but not defined ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) == Outdated reference: A later version (-10) exists of draft-ietf-karp-crypto-key-table-01 == Outdated reference: A later version (-07) exists of draft-ietf-karp-routing-tcp-analysis-00 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Jethanandani 3 Internet-Draft B. Weis 4 Intended status: Standards Track K. Patel 5 Expires: January 2, 2012 Cisco Systems 6 July 1, 2011 8 Key Management for Pairwise Routing Protocol 9 draft-mahesh-karp-kmprp-00 11 Abstract 13 This document defines an automated method of Key Management for 14 routing protocol that need pair-wise keys. 16 Requirements Language 18 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 19 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 20 document are to be interpreted as described in RFC 2119 [RFC2119]. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 2, 2012. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Protocol Exchanges . . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. RP_INIT . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.2. RP_AUTH . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.3. RP_ADD . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 2.4. INFORMATIONAL . . . . . . . . . . . . . . . . . . . . . . 5 62 3. Header and Payload Formats . . . . . . . . . . . . . . . . . . 5 63 3.1. Security Association Payload . . . . . . . . . . . . . . . 6 64 3.1.1. Proposal Substructure . . . . . . . . . . . . . . . . 6 65 3.1.1.1. Transforms Substructures . . . . . . . . . . . . . 8 66 3.1.1.1.1. KMPRP . . . . . . . . . . . . . . . . . . . . 8 67 3.1.1.1.2. TCP-AO Transforms . . . . . . . . . . . . . . 8 68 4. Operation Details . . . . . . . . . . . . . . . . . . . . . . 10 69 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 4.2. Initial Key Specific Data Exchange . . . . . . . . . . . . 11 71 4.3. Key Specific Data Rollover Exchange . . . . . . . . . . . 11 72 5. Key Management Database (KMDB) . . . . . . . . . . . . . . . . 11 73 6. Protocol Interaction . . . . . . . . . . . . . . . . . . . . . 12 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 76 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 79 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 82 1. Introduction 84 Key management today is limited to statically configuring master keys 85 in individual routers. This document extends currently defined IKEv2 86 protocol to define an automated method of Key Management for Pairwise 87 Routing Protocol (KMPRP) that allows network devices to automatically 88 exchange key material related information between the network 89 devices. 91 2. Protocol Exchanges 93 The exchange of private keying material between two network devices 94 using a dedicated key management protocol is a requirement as 95 articulated in [I-D.ietf-karp-routing-tcp-analysis]. There is no 96 need to define an entirely new protocol for this purpose, when 97 existing mature protocol exchanges and methods have been vetted. 98 This draft makes use of the IKEv2 protocol exchanges, state machine, 99 and policy definitions to define a dedicated key management protocol. 100 However, as IKEv2 was developed exclusively for the use of IPsec, 101 these protocol exchanges are incorporated by reference into the 102 present key protocol definitions, and are exchanged using a dedicated 103 UDP port number (TDB - IANA). The use of a dedicated UDP port will 104 clearly differentiate this protocol from IKEv2. 106 In the following figures, the notations contained in the message are 107 defined as follows. 109 +----------+------------------------------+ 110 | Notation | Payload | 111 +----------+------------------------------+ 112 | AUTH | Authentication | 113 | CERT | Certificate | 114 | CERTREQ | Certificate Request | 115 | D | Delete | 116 | HDR | KMPRP Header (not a payload) | 117 | IDi | Identification - Initiator | 118 | IDr | Identification - Responder | 119 | KE | Key Exchange | 120 | Ni, Nr | Nonce | 121 | N | Notify | 122 | SA | Security Association | 123 | SK | Encrypted and Authenticated | 124 | TSi | Traffic Selector - Initiator | 125 | TSr | Traffic Selector - Responder | 126 +----------+------------------------------+ 128 Acronyms Used in Protocol Exchange 130 2.1. RP_INIT 132 The RP Initial Exchange (RP_INIT) is identical to the IKE_SA_INIT 133 exchange defined in Internet Key Exchange Protocol Version 2 134 [RFC5996]. The RP_INIT exchange is a two-message exchange that 135 allows the network devices to negotiate cryptographic algorithms, 136 exchange nonces, and do a Diffe-Hellman (DH) [DH] exchange, for their 137 routing protocols, after which protocols on these network devices can 138 communicate privately. Note that at this point the network devices 139 have not identified their peer. For the details of this exchange, 140 refer to IKE_SA_INIT in Internet Key Exchange Protocol Version 2 141 [RFC5996]. 143 Peer (Initiator) Peer (Responder) 144 -------------------- ------------------ 145 HDR, SAi1, KEi, Ni --> 146 <-- HDR, SAr1, KEr, Nr, [CERTREQ,] 148 RP_INIT 150 2.2. RP_AUTH 152 Next, the network devices perform a RP Authentication exchange 153 (RP_AUTH), which is substantially the same as the IKE_AUTH exchange 154 defined in RFC 5996, except that the SA payload contains policy 155 specific to the routing protocol security policy (labeled SArpi and 156 SArpr) rather than IPsec policy (SAi2, SAr2 defined in RFC 5996). 157 The SArpi and SArpr payloads are described in Section 3; for the 158 details of the rest of the exchange please refer to IKE_AUTH in RFC 159 5996. 161 Peer (Initiator) Peer (Responder) 162 -------------------- ------------------ 163 HDR, SK {IDi, [CERT,] [CERTREQ,] 164 [IDr,] AUTH, SArpi, 165 TSi, TSr} --> 166 <-- HDR, SK {IDr, [CERT,] AUTH, 167 SArpr, TSi, TSr} 169 RP_AUTH 171 In the RP_AUTH exchange, the Initiator proposes one or more sets of 172 policies for one routing protocol in the SArpi. The Responder 173 returns the one policy contained in SArpi that it accepts. Based on 174 this policy, appropriate keying material is derived from the existing 175 shared keying material. At the successful conclusion of the RP_AUTH 176 exchange, the initiator and responder have agreed upon a single set 177 of policy and keying material for a particular routing protocol. 179 2.3. RP_ADD 181 The network devices may then destroy the state associated with the RP 182 SA, continuing to use the RP policy and keying material, or they may 183 choose to retain them for the further use. If both the network 184 devices choose to retain them, they may use the RP SA to subsequently 185 agree upon replacement policy for the same RP, or agree upon policy 186 and keying material for another routing protocol. Either case will 187 require the use of the RP Additional Exchange (RP_ADD), similar to 188 the IKEv2 CREATE_CHILD_SA exchange as defined in RFC 5996. 190 Peer (Initiator) Peer (Responder) 191 -------------------- ------------------ 192 HDR, SK {SArpi, Ni, [KEi ], 193 TSi, TSr} --> 194 <-- HDR, SK {SArpr, Nr, [KEr ], 195 TSi, TSr} 197 RP_ADD 199 In the RP_ADD exchange, the SA payloads in the RP_ADD exchange are 200 used identically as in the RP_AUTH exchange. For details on the rest 201 of the exchange, refer to the CREATE_CHILD_SA exchange as defined in 202 RFC 5996. 204 2.4. INFORMATIONAL 206 The IKEv2 INFORMATIONAL exchange is also useful for deleting specific 207 RP SAs or sending status information. The Notify (N) and Delete (D) 208 payloads are as those defined by IKEv2 [IKEV2-PARAMS]. For example, 209 if the Responder refused to accept one of Proposals sent by the 210 Initiator, it would return an INFORMATIONAL exchange of type 211 NO_PROPOSAL_CHOSEN instead of the response to RP_ADD. 212 Peer (Initiator) Peer (Responder) 213 ------------------- ------------------ 214 HDR, SK {[N,] [D,] ... } --> 215 <-- HDR, SK {[N,] [D,] ... } 217 INFORMATIONAL 219 3. Header and Payload Formats 221 The protocol defined in this memo uses a HDR identical to the Generic 222 Payload Header defined in section 3.2 of RFC 5996. The new exchanges 223 defined in this memo are not used with IKEv2. A new IANA registry is 224 to be created to identify the RP exchange types and payloads 225 described in this section. 227 3.1. Security Association Payload 229 The Security Association (SA) payload contains a list of Proposals, 230 which describe one or more sets of policy that a router is willing to 231 use to protect a routing protocol. It is identical to the SA payload 232 described in RFC 5996, and the details of the fields are described 233 there. 235 In the Initiator's message, the SArpi payload contains a list of 236 Proposal payloads (as defined in the next section), each of which 237 contains a single set of policy that can be applied to the packets 238 described in the Traffic Selector (TS) payloads in the same exchange. 239 For example, the TS payloads may describe a set of IP addresses and 240 ports which are a BGP connection, and the SA payload contains a list 241 of proposals describing what policy the router is willing to use to 242 protect that BGP traffic. Each set of policy is given a particular 243 "Proposal Number" uniquely identifying this set of policy. 245 The responder includes a single Proposal payload in it's SA policy, 246 which denotes the choice it has made amongst the initiator's list of 247 Proposals. Any attributes of a selected transform MUST be returned 248 unmodified as explained in IKEv2 [RFC5996] section 3.3.6. The 249 initiator of an exchange MUST check that the accepted offer is 250 consistent with one of its proposals, and if not MUST terminate the 251 exchange. 253 1 2 3 254 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Next Payload |C| RESERVED | Payload Length | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | | 259 ~ ~ 260 | | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 Security Association Payload 265 The Security Association Payload fields are defined as in RFC 5996. 267 3.1.1. Proposal Substructure 269 The Proposal (P) substructure of the Security Association Payload 270 contains an identification for the set of policy choices, the 271 security protocol offered in the proposal, and details of the 272 cryptographic choices offered. 274 1 2 3 275 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | 0 (last) or 2 | Reserved | Proposal Length | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Proposal Num | Protocol ID | RT Protocol|Num Transforms | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | | 282 ~ ~ 283 | | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 Proposal Payload 288 o 0 (last) or 2 (more) (1 octet) - Specifies whether this is the last 289 Proposal Substructure in the SA. 291 o RESERVED (1 octet) - MUST be sent as zero; MUST be ignored on 292 receipt. 294 o Proposal Length (2 octets, unsigned integer) - Length of this 295 proposal, including all transforms and attributes that follow. 297 o Proposal Num (1 octet) - When a proposal is made, the first 298 proposal in an SA payload MUST be 1, and subsequent proposals MUST be 299 one more than the previous proposal (indicating an OR of the two 300 proposals). When a proposal is accepted, the proposal number in the 301 SA payload MUST match the number on the proposal sent that was 302 accepted. 304 o Protocol ID (1 octet) - Specifies the protocol identifier for the 305 current negotiation. 307 Protocol Protocol ID Reference 308 ---------------------------------------------- 309 KMPRP 1 310 TCP-AO 2 RFC 5925 311 LDP Discovery Key 3 TBD 312 Standards Action 4-128 313 Private Use 129-255 315 Protocol ID 317 o RT Protocol (1 octet) - Specifies the routing protocol identifier 318 for the current negotiation. 320 Routing (RT) Protocol Protocol ID Reference 321 --------------------------------------------- 322 BGP 1 RFC 4271 323 LDP 2 RFC 5036 324 MSDP 3 RFC 3618 325 PIM PORT 4 326 PCEP 5 RFC 5440 328 Routing Protocol 330 o Num Transforms (1 octet) - Specifies the number of transforms in 331 this proposal. 333 o Transforms (variable) - One or more transform substructures. 335 3.1.1.1. Transforms Substructures 337 Each Proposal has a list of Transform (T) substructures, each of 338 which describe a particular set of cryptographic policy choices. 339 This is useful for an initiator to propose multiple cryptographic 340 choices for the same policy described in its associated Proposal 341 payload. 343 3.1.1.1.1. KMPRP 345 This transform payload is used negotiate policy to protect the KMPRP 346 exchanges. The Transforms are identical to the Transforms specified 347 to negotiate IKE policy in Section 3.3.2 of IKEv2 [RFC5996]. 349 3.1.1.1.2. TCP-AO Transforms 351 The TCP-AO [RFC5925] transform payload contains the following fields. 353 1 2 3 354 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | 0 (last) or 3 | RESERVED | Transform Length | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | SendID |Auth Alg | KDF | Flags | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 TCP-AO Transforms 363 o 0 (last) or 3 (more) (1 octet) - Specifies whether this is the last 364 Transform Substructure in the Proposal. 366 o RESERVED (1 octet) - MUST be sent as zero; MUST be ignored on 367 receipt. 369 o Transform Length (2 octets) - The length (in octets) of the 370 Transform Substructure including Header and Attributes. 372 o SendID (1 octet) - The TCP-AO KeyID that the sender will use to 373 represent this Transform. The KeyID will be used to generate the 374 keys independently on each network device at the end of the exchange. 376 o Auth Alg (1 octet) - The Authentication algorithm defined as a part 377 of this Transform. Values are defined in Cryptographic Algorithms 378 for the TCP Authentication Option [RFC5926]. 380 Auth Alg ID 381 ------------------------------ 382 HMAC-SHA-1-96 1 383 AES-128-CMAC-96 2 384 Standards Action 3-128 385 Private Use 129-255 387 Authentication Algorithm 389 o KDF (1 octet) - The KDF defined as a part of this Transform. 390 Values are defined in Cryptographic Algorithms for the TCP 391 Authentication Option [RFC5926]. 393 KDF ID 394 ------------------------------ 395 KDF_HMAC_SHA1 1 396 KDF_AES_128_CMAC 2 397 Standards Action 3-128 398 Private Use 129-255 400 Key Derivation Functions 402 o Flags (1 octet) - Indicates specific options for TCP-AO. The bits 403 are as follows: 405 +-+-+-+-+-+-+-+-+ 406 |O|X|X|X|X|X|X|X| 407 +-+-+-+-+-+-+-+-+ 409 In the description below, a bit being 'set' means its value is '1', 410 while 'cleared' means its value is '0'. 'X' bits MUST be cleared 411 when sending and MUST be ignored on receipt. 413 o O (Options) - This bit indicates whether or not TCP Options are to 414 be included in the bytes protected by the authentication 415 calculation. This bit is set to indicate that TCP Options are to 416 be ignored and cleared to indicate that TCP Options are protected. 418 When a TCP-AO transform is chosen, keying material for the TCP-AO 419 master key is generated as follows, where Ni and Nr are unique to 420 this exchange. The value SK_D is defined in RFC 5996, and refers to 421 the value derived from SKEYSEED that is used to derive new keys 422 (e.g., for TCP-AO). 424 = prf+(SK_d, Ni | Nr) 426 4. Operation Details 428 4.1. General 430 KMPRP is used to dynamically derive key material information between 431 the two network devices trying to establish or maintain a routing 432 protocol neighbor adjacency. Typically network devices running the 433 routing protocols establish neighbor adjacencies at the routing 434 protocol level. These routing protocols may run different security 435 algorithms that provide transport level security for the protocol 436 neighbor adjacencies. Depending on the security algorithm used, the 437 routing protocols are configured with security algorithm specific 438 keys that are either long term keys or short term session keys. 439 These keys are specific to the security algorithms used to enforce 440 transport level security for the routing protocols. 442 A routing protocol causes KMPRP to execute when it needs key material 443 to establish neighbor adjacency. This can be as a result of the 444 routing protocol neighbor being configured, neighbor changed or 445 updated, a local rekey policy decision, or some other event dictated 446 by the implementation. The key material would allow the network 447 devices to then independently generate the same key and establish a 448 KMPRP neighbor adjacency between them. This is typically done by the 449 Initiator (KMPRP speaker) initiating a KMPRP RP_INIT exchange 450 mentioned in the section 2.1 towards its KMPRP peer. As part of 451 RP_INIT exchange, KMPRP will send a message to the KMPRP peer's well 452 known KMPRP UDP port [TBD] by IANA. The format of the message is 453 explained in section 3. The procedure to exchange key information is 454 explained in section 3. Once the key material information is 455 successfully exchanged by both the KMPRP speaker, the KMPRP neighbor 456 adjacency may be torn down. 458 The master key data received from KMPRP peers are stored in the 459 separate Key Management Database known as KMDB. KMDB follows the 460 guidelines in[I-D.ietf-karp-crypto-key-table], and each entry 461 consists of Key specific information, Security algorithm to which the 462 Key is applicable to, Routing Protocol Clients of interest, and the 463 announcing KMPRP Peer. KMDB is also used to notify the routing 464 protocols about the key updates. Typically key material information 465 is exchanged whenever a routing protocol is about to create a new 466 neighbor adjacency. This is considered as an Initial Key exchange 467 mode. Key material information is also exchanged to refresh existing 468 key data on an already existing neighbor adjacency. This is 469 considered as Key rollover exchange mode. The following sections 470 describes their detail behavior. 472 4.2. Initial Key Specific Data Exchange 474 Routing protocols informs KMPRP of its new neighbor adjacency. It 475 does so by creating a local entry in KMDB which consists of a 476 Security algorithm, Key specific information, routing protocol client 477 and the routing protocol neighbor. Upon a successful creation of 478 such an entry KMPRP initiates KMPRP peering with the neighbor and 479 starts initial KMPRP RP_INIT exchange explained in section 2.1 480 followed by the RP_AUTH exchanged explained in section 2.2. Once the 481 key related information is successfully exchanged, KMDB may invoke 482 the routing protocol client to provide key specific information 483 updates if any. 485 4.3. Key Specific Data Rollover Exchange 487 Key rollover exchange may be initiated at a pre-configured time 488 interval or as part of a manual configuration and is outside the 489 scope of this document. The procedure of Key Rollover exchange is 490 exactly same as the Initial Key specific data exchange described 491 above. 493 5. Key Management Database (KMDB) 495 Protocol interaction between KMPRP and its client routing protocols 496 is typically done using KMDB. Routing protocols update KMDB by 497 installing a new Key related information or purging an existing Key 498 specific information. As part of the KMDB update, KMPRP initiates 499 peering connections with its appropriate KMPRP peers to announce the 500 updated key related information. KMPRP may also receive an updated 501 key related information from its peers which gets installed in KMDB. 502 Whenever KMPRP updates KMDB with updated key information from its 503 peers, it notifies client routing protocols of its updates. 505 6. Protocol Interaction 507 Routing protocols could end up with multiple keys when updated by 508 KMDB. Typically, routing protocols should use the keys till the 509 point its peers have transitioned to a new key. Once the peers have 510 transitioned to a new key, routing protocols could put the old keys 511 on timers and eventually free them. The reason to put them on timer 512 and not free them right away is to ensure that all out of order 513 packets in TCP are handled correctly. 515 7. IANA Considerations 517 A new UDP port number will need to be assigned for systems that want 518 to implement this protocol. 520 A new IANA registry is to be created to identify the RP exchange 521 types and payloads. 523 Note to RFC Editor: this section may be removed on publication as an 524 RFC. 526 8. Security Considerations 528 TBD 530 9. Acknowledgements 532 During the development of TCP-AO, Gregory Lebovitz noted that a 533 protocol based on an IKEv2 exchange would be a good automated key 534 management method for deriving a TCP-AO master key. 536 Many protocol definitions and protocol formats come from RFC 5996, 537 either by reference or inclusion. 539 10. References 541 10.1. Normative References 543 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 544 Requirement Levels", BCP 14, RFC 2119, March 1997. 546 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 547 Authentication Option", RFC 5925, June 2010. 549 [RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms 550 for the TCP Authentication Option (TCP-AO)", RFC 5926, 551 June 2010. 553 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 554 "Internet Key Exchange Protocol Version 2 (IKEv2)", 555 RFC 5996, September 2010. 557 10.2. Informative References 559 [DH] Diffie, W. and M. Hellman, "New Directions in 560 Cryptography", IEEE Transactions on Information 561 Theory, V.IT-22 n. 6, June 1977. 563 [I-D.ietf-karp-crypto-key-table] 564 Housley, R. and T. Polk, "Database of Long-Lived Symmetric 565 Cryptographic Keys", draft-ietf-karp-crypto-key-table-01 566 (work in progress), May 2011. 568 [I-D.ietf-karp-routing-tcp-analysis] 569 Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 570 BGP, LDP, PCEP, and MSDP Security According to KARP Design 571 Guide", draft-ietf-karp-routing-tcp-analysis-00 (work in 572 progress), June 2011. 574 [IKEV2-PARAMS] 575 "Internet Key Exchange Version 2 (IKEv2) Parameters", . 579 Authors' Addresses 581 Mahesh Jethanandani 582 Cisco Systems 583 170 Tasman Drive 584 San Jose, California CA 585 USA 587 Phone: +1 (408) 527-8230 588 Fax: 589 Email: mjethanandani@gmail.com 590 URI: 592 Brian Weis 593 Cisco Systems 594 170 W. Tasman Drive 595 San Jose, California 95134 596 USA 598 Phone: +1 (408) 526-4796 599 Fax: 600 Email: bew@cisco.com 601 URI: 603 Keyur Patel 604 Cisco Systems 605 170 Tasman Drive 606 San Jose, California 95134 607 USA 609 Phone: _1 (408) 526-7183 610 Fax: 611 Email: keyupate@cisco.com 612 URI: