idnits 2.17.1 draft-ietf-lisp-crypto-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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 91: '...for key exchange MUST be one round-tri...' RFC 2119 keyword, line 296: '...the RLOC-set, it MUST send a Map-Reque...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 12, 2015) is 3389 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 4492 (Obsoleted by RFC 8422) ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) == Outdated reference: A later version (-05) exists of draft-mcgrew-aead-aes-cbc-hmac-sha2-03 == Outdated reference: A later version (-22) exists of draft-ietf-lisp-lcaf-04 == Outdated reference: A later version (-04) exists of draft-fuller-lisp-ddt-03 == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-06 Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force D. Farinacci 3 Internet-Draft lispers.net 4 Intended status: Experimental January 12, 2015 5 Expires: July 16, 2015 7 LISP Data-Plane Confidentiality 8 draft-ietf-lisp-crypto-00 10 Abstract 12 This document describes a mechanism for encrypting LISP encapsulated 13 traffic. The design describes how key exchange is achieved using 14 existing LISP control-plane mechanisms as well as how to secure the 15 LISP data-plane from third-party surveillance attacks. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on July 16, 2015. 34 Copyright Notice 36 Copyright (c) 2015 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Diffie-Hellman Key Exchange . . . . . . . . . . . . . . . . . 3 54 4. Encoding and Transmitting Key Material . . . . . . . . . . . 4 55 5. Data-Plane Operation . . . . . . . . . . . . . . . . . . . . 6 56 6. Dynamic Rekeying . . . . . . . . . . . . . . . . . . . . . . 7 57 7. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 59 8.1. SAAG Support . . . . . . . . . . . . . . . . . . . . . . 8 60 8.2. LISP-Crypto Security Threats . . . . . . . . . . . . . . 8 61 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 62 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 64 10.2. Informative References . . . . . . . . . . . . . . . . . 9 65 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 10 66 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 10 67 B.1. Changes to draft-ietf-lisp-crypto-00.txt . . . . . . . . 10 68 B.2. Changes to draft-farinacci-lisp-crypto-01.txt . . . . . . 10 69 B.3. Changes to draft-farinacci-lisp-crypto-00.txt . . . . . . 11 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 72 1. Introduction 74 The Locator/ID Separation Protocol [RFC6830] defines a set of 75 functions for routers to exchange information used to map from non- 76 routable Endpoint Identifiers (EIDs) to routable Routing Locators 77 (RLOCs). LISP ITRs and PITRs encapsulate packets to ETRs and RTRs. 78 Packets that arrive at the ITR or PITR are typically not modified. 79 Which means no protection or privacy of the data is added. If the 80 source host encrypts the data stream then the encapsulated packets 81 can be encrypted but would be redundant. However, when plaintext 82 packets are sent by hosts, this design can encrypt the user payload 83 to maintain privacy on the path between the encapsulator (the ITR or 84 PITR) to a decapsulator (ETR or RTR). 86 This draft has the following requirements for the solution space: 88 o Do not require a separate Public Key Infrastructure (PKI) that is 89 out of scope of the LISP control-plane architecture. 91 o The budget for key exchange MUST be one round-trip time. That is, 92 only a two packet exchange can occur. 94 o Use symmetric keying so faster cryptography can be performed in 95 the LISP data plane. 97 o Avoid a third-party trust anchor if possible. 99 o Provide for rekeying when secret keys are compromised. 101 o At this time, encapsulated packet authentication is not a strong 102 requirement. 104 2. Overview 106 The approach proposed in this draft is to not rely on the LISP 107 mapping system to store security keys. This will provide for a 108 simpler and more secure mechanism. Secret shared keys will be 109 negotiated between the ITR and the ETR in Map-Request and Map-Reply 110 messages. Therefore, when an ITR needs to obtain the RLOC of an ETR, 111 it will get security material to compute a shared secret with the 112 ETR. 114 The ITR can compute 3 shared-secrets per ETR the ITR is encapsulating 115 to. And when the ITR encrypts a packet before encapsulation, it will 116 identify the key it used for the crypto calculation so the ETR knows 117 which key to use for decrypting the packet after decapsulation. By 118 using key-ids in the LISP header, we can also get rekeying 119 functionality. 121 3. Diffie-Hellman Key Exchange 123 LISP will use a Diffie-Hellman [RFC2631] key exchange sequence and 124 computation for computing a shared secret. The Diffie-Hellman 125 parameters will be passed in Map-Request and Map-Reply messages. 127 Here is a brief description how Diff-Hellman works: 129 +----------------------------+---------+----------------------------+ 130 | ITR | | ETR | 131 +------+--------+------------+---------+------------+---------------+ 132 |Secret| Public | Calculates | Sends | Calculates | Public |Secret| 133 +------|--------|------------|---------|------------|--------|------+ 134 | i | p,g | | p,g --> | | | e | 135 +------|--------|------------|---------|------------|--------|------+ 136 | i | p,g,I |g^i mod p=I | I --> | | p,g,I | e | 137 +------|--------|------------|---------|------------|--------|------+ 138 | i | p,g,I | | <-- E |g^e mod p=E | p,g | e | 139 +------|--------|------------|---------|------------|--------|------+ 140 | i,s |p,g,I,E |E^i mod p=s | |I^e mod p=s |p,g,I,E | e,s | 141 +------|--------|------------|---------|------------|--------|------+ 143 Public-key exchange for computing a shared private key [DH] 145 Diffie-Hellman parameters 'p' and 'g' must be the same values used by 146 the ITR and ETR. The ITR computes public-key 'I' and transmits 'I' 147 in a Map-Request packet. When the ETR receives the Map-Request, it 148 uses parameters 'p' and 'g' to compute the ETR's public key 'E'. The 149 ETR transmits 'E' in a Map-Reply message. At this point, the ETR has 150 enough information to compute 's', the shared secret, by using 'I' as 151 the base and the ETR's private key 'e' as the exponent. When the ITR 152 receives the Map-Reply, it uses the ETR's public-key 'E' with the 153 ITR's private key 'i' to compute the same 's' shared secret the ETR 154 computed. The value 'p' is used as a modulus to create the width of 155 the shared secret 's'. 157 4. Encoding and Transmitting Key Material 159 The Diffie-Hellman key material is transmitted in Map-Request and 160 Map-Reply messages. Diffie-Hellman parameters are encoded in the 161 LISP Security Type LCAF [LCAF]. 163 0 1 2 3 164 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 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | AFI = 16387 | Rsvd1 | Flags | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Type = 11 | Rsvd2 | 6 + n | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Key Count | Rsvd3 | Key Algorithm | Rsvd4 |R| 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | Key Length | Key Material ... | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | ... Key Material | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | AFI = x | Locator Address ... | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 Diffie-Hellman parameters encoded in Key Material field 181 The 'Key Count' field encodes the number of {'Key-Length', 'Key- 182 Material'} fields included in the encoded LCAF. A maximum number of 183 keys that can be encoded are 3 keys, each identified by key-id 1, 184 followed by key-id 2, an finally key-id 3. 186 The 'R' bit is not used for this use-case of the Security Type LCAF 187 but is reserved for [LISP-DDT] security. 189 The 'Key Algorithm' encodes the cryptographic algorithm used. The 190 following values are defined: 192 Null: 0 193 Group-ID: 1 194 AES: 2 195 3DES: 3 196 SHA-256: 4 198 When the 'Key Algorithm' value is 1 (Group-ID), the 'Key Material' 199 field is encoded as: 201 0 1 2 3 202 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 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Group ID | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Public Key ... | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 Points to Key Material values from IANA Registry 211 The Group-ID values are defined in [RFC2409] and [RFC3526] which 212 describe the Diffie Hellman parameters used for key exchange. 214 When the 'Key Algorithm' value is not 1 (Group-ID), the 'Key 215 Material' field is encoded as: 217 0 1 2 3 218 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 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | g-length | g-value ... | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | p-length | p-value ... | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Public Key ... | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 Key Length describes the length of the Key Material field 229 When an ITR or PITR sends a Map-Request, they will encode their own 230 RLOC in Security Type LCAF format within the ITR-RLOCs field. When a 231 ETR or RTR sends a Map-Reply, they will encode their RLOCs in 232 Security Type LCAF format within the RLOC-record field of each EID- 233 record supplied. 235 If an ITR or PITR sends a Map-Request with a Security Type LCAF 236 included and the ETR or RTR does not want to have encapsulated 237 traffic encrypted, they will return a Map-Reply with no RLOC records 238 encoded with the Security Type LCAF. This signals to the ITR or PITR 239 that it should not encrypt traffic (it cannot encrypt traffic anyways 240 since no ETR public-key was returned). 242 Likewise, if an ITR or PITR wish to include multiple key-ids in the 243 Map-Request but the ETR or RTR wish to use some but not all of the 244 key-ids, they return a Map-Reply only for those key-ids they wish to 245 use. 247 5. Data-Plane Operation 249 The LISP encapsulation header [RFC6830] requires changes to encode 250 the key-id for the key being used for encryption. 252 0 1 2 3 253 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 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 / | Source Port = xxxx | Dest Port = 4341 | 256 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 \ | UDP Length | UDP Checksum | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 L |N|L|E|V|I|P|K|K| Nonce/Map-Version | 260 I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 S / | Instance ID/Locator-Status-Bits | 262 P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 K-bits indicate when packet is encrypted and which key used 266 When the KK bits are 00, the encapsulated packet is not encrypted. 267 When the value of the KK bits is 1, 2, or 3, it encodes the key-id of 268 the secret keys computed during the Diffie-Hellman Map-Request/Map- 269 Reply exchange. 271 When an ITR or PITR receives a packet to be encapsulated, they will 272 first decide what key to use, encode the key-id into the LISP header, 273 and use that key to encrypt all packet data that follows the LISP 274 header. Therefore, the outer header, UDP header, and LISP header 275 travel as plaintext. 277 There is an open working group item to discuss if the data 278 encapsulation header needs change for encryption or any new 279 applications. This draft proposes changes to the existing header so 280 experimentation can continue without making large changes to the 281 data-plane at this time. 283 6. Dynamic Rekeying 285 Since multiple keys can be encoded in both control and data messages, 286 an ITR can encapsulate and encrypt with a specific key while it is 287 negotiating other keys with the same ETR. Soon as an ETR or RTR 288 returns a Map-Reply, it should be prepared to decapsulate and decrypt 289 using the new keys computed with the new Diffie-Hellman parameters 290 received in the Map-Request and returned in the Map-Reply. 292 RLOC-probing can be used to change keys by the ITR at any time. And 293 when an initial Map-Request is sent to populate the ITR's map-cache, 294 the Map-Requests flows across the mapping system where a single ETR 295 from the Map-Reply RLOC-set will respond. If the ITR decides to use 296 the other RLOCs in the RLOC-set, it MUST send a Map-Request directly 297 to key negotiate with the ETR. This process may be used to test 298 reachability from an ITR to an ETR initially when a map-cache entry 299 is added for the first time, so an ITR can get both reachability 300 status and keys negotiated with one Map-Request/Map-Reply exchange. 302 A rekeying event is defined to be when an ITR or PITR changes the p, 303 g, or the public-key in a Map-Request. The ETR or RTR compares the 304 p, g, and public-key it last received from the ITR for the key-id, 305 and if any value has changed, it computes a new public-key of its own 306 with the new p and g values from the Map-Request and returns it in 307 the Map-Reply. Now a new shared secret is computed and can be used 308 for the key-id for encryption by the ITR and decryption by the ETR. 309 When the ITR or PITR starts this process of negotiating a new key, it 310 must not use the corresponding key-id in encapsulated packets until 311 it receives a Map-Reply from the ETR with the p and g values it 312 expects (the values it sent in a Map-Request). 314 Note when RLOC-probing continues to maintain RLOC reachability and 315 rekeying is not desirable, the ITR or RTR can either not include the 316 Security Type LCAF in the Map-Request or supply the same key material 317 as it recieved from the last Map-Reply from the ETR or RTR. This 318 approach signals to the ETR or RTR that no rekeying event is 319 requested. 321 7. Future Work 323 By using AES-GCM [RFC5116], or HMAC-CBC [AES-CBC], it has been 324 suggested that encapsulated packet authentication (through encryption 325 [RFC4106]) could be supported. There is current work in progress to 326 investigate these techniques for the LISP data-plane. However, it 327 will require encapsulation header changes to LISP. 329 For performance considerations, Elliptic-Curve Diffie Hellman (ECDH) 330 can be used as specified in [RFC4492] to reduce CPU cycles required 331 to compute shared secret keys. 333 8. Security Considerations 335 8.1. SAAG Support 337 The LISP working group will seek help from the SAAG working group for 338 security advice. The SAAG will be involved early in the design 339 process so they have early input and review. 341 8.2. LISP-Crypto Security Threats 343 Since ITRs and ETRs participate in key exchange over a public non- 344 secure network, a man-in-the-middle (MITM) could circumvent the key 345 exhange and compromise data-plane confidentiality. This can happen 346 when the MITM is acting as a Map-Replier, provides its own public key 347 so the ITR and the MITM generate a shared secret key among each 348 other. If the MITM is in the data path between the ITR and ETR, it 349 can use the shared secret key to decrypt traffic from the ITR. 351 Since LISP can secure Map-Replies by the authentication process 352 specified in [LISP-SEC], the ITR can detect when a MITM has signed a 353 Map-Reply for an EID-prefix it is not authoritative for. When an ITR 354 determines the signature verification fails, it discards and does not 355 reuse the key exchange parameters, avoids using the ETR for 356 encapsulation, and issues a severe log message to the network 357 adminstrator. Optionally, the ITR can send RLOC-probes to the 358 compromised RLOC to determine if can reach the authoriative ETR. And 359 when the ITR validates the signature of a Map-Reply, it can begin 360 encrypting and encapsulating packets to the RLOC of ETR. 362 9. IANA Considerations 364 This draft requires the use of the registry that selects Diffie 365 Hellman parameters. Rather than convey the key exchange parameters 366 directly in LISP control packets, a Group-ID from the registry will 367 be used. The Group-ID values are defined in [RFC2409] and [RFC3526]. 369 10. References 371 10.1. Normative References 373 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 374 (IKE)", RFC 2409, November 1998. 376 [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 377 2631, June 1999. 379 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 380 Diffie-Hellman groups for Internet Key Exchange (IKE)", 381 RFC 3526, May 2003. 383 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 384 (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 385 4106, June 2005. 387 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 388 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 389 for Transport Layer Security (TLS)", RFC 4492, May 2006. 391 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 392 Encryption", RFC 5116, January 2008. 394 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 395 Locator/ID Separation Protocol (LISP)", RFC 6830, January 396 2013. 398 10.2. Informative References 400 [AES-CBC] McGrew, D., Foley, J., and K. Paterson, "Authenticated 401 Encryption with AES-CBC and HMAC-SHA", draft-mcgrew-aead- 402 aes-cbc-hmac-sha2-03.txt (work in progress), . 404 [DH] "Diffie-Hellman key exchange", Wikipedia 405 http://en.wikipedia.org/wiki/Diffie-Hellman_key_exchange, 406 . 408 [LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 409 Address Format", draft-ietf-lisp-lcaf-04.txt (work in 410 progress), . 412 [LISP-DDT] 413 Fuller, V., Lewis, D., Ermaagan, V., and A. Jain, "LISP 414 Delegated Database Tree", draft-fuller-lisp-ddt-03 (work 415 in progress), . 417 [LISP-SEC] 418 Maino, F., Ermagan, V., Cabellos, A., and D. Saucez, 419 "LISP-Secuirty (LISP-SEC)", draft-ietf-lisp-sec-06 (work 420 in progress), . 422 Appendix A. Acknowledgments 424 The author would like to thank Dan Harkins, Brian Weis, Joel Halpern, 425 Fabio Maino, Ed Lopez, and Roger Jorgensen for their interest, 426 suggestions, and discussions about LISP data-plane security. 428 In addition, the support and suggestions from the SAAG working group 429 were helpful and appreciative. 431 Appendix B. Document Change Log 433 B.1. Changes to draft-ietf-lisp-crypto-00.txt 435 o Posted January 2015. 437 o Changing draft-farinacci-lisp-crypto-01 to draft-ietf-lisp-crypto- 438 00. This draft has become a working group document 440 o Add text to indicate the working group may work on a new data 441 encapsulation header format for data-plane encryption. 443 B.2. Changes to draft-farinacci-lisp-crypto-01.txt 445 o Posted July 2014. 447 o Add Group-ID to the encoding format of Key Material in a Security 448 Type LCAF and modify the IANA Considerations so this draft can use 449 key exchange parameters from the IANA registry. 451 o Indicate that the R-bit in the Security Type LCAF is not used by 452 lisp-crypto. 454 o Add text to indicate that ETRs/RTRs can negotiate less number of 455 keys from which the ITR/PITR sent in a Map-Request. 457 o Add text explaining how LISP-SEC solves the problem when a man-in- 458 the-middle becomes part of the Map-Request/Map-Reply key exchange 459 process. 461 o Add text indicating that when RLOC-probing is used for RLOC 462 reachability purposes and rekeying is not desired, that the same 463 key exchange parameters should be used so a reallocation of a 464 pubic key does not happen at the ETR. 466 o Add text to indicate that ECDH can be used to reduce CPU 467 requirements for computing shared secret-keys. 469 B.3. Changes to draft-farinacci-lisp-crypto-00.txt 471 o Initial draft posted February 2014. 473 Author's Address 475 Dino Farinacci 476 lispers.net 477 San Jose, California 478 USA 480 Phone: 408-718-2001 481 Email: farinacci@gmail.com