idnits 2.17.1 draft-bi-ippm-ipsec-01.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 25, 2013) is 4078 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) ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) -- Obsolete informational reference (is this intentional?): RFC 2898 (Obsoleted by RFC 8018) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPPM Y. Cui 3 Internet-Draft E. Bi 4 Intended status: Standards Track K. Pentikousis, Ed. 5 Expires: August 29, 2013 Huawei Technologies 6 February 25, 2013 8 Network Performance Measurement for IPsec 9 draft-bi-ippm-ipsec-01.txt 11 Abstract 13 IPsec is a mature technology with several interoperable 14 implementations. Indeed, the use of IPsec tunnels is increasingly 15 gaining popularity in several deployment scenarios, not the least in 16 what used to be solely areas of traditional telecommunication 17 protocols. Wider deployment calls for mechanisms and methods that 18 enable tunnel end-users, as well as operators, to measure one-way and 19 two-way network performance. Unfortunately, however, standard IP 20 performance measurement security mechanisms cannot be readily used 21 with IPsec. This document makes the case for employing IPsec to 22 protect O/TWAMP and proposes a method which combines IKEv2 and 23 O/TWAMP as defined in RFC 4656 and RFC 5357, respectively. This 24 specification aims, on the one hand, to ensure that O/TWAMP can be 25 secured, while on the other hand, it extends the applicability of 26 O/TWAMP to networks that have already deployed IPsec. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on August 29, 2013. 45 Copyright Notice 47 Copyright (c) 2013 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology used in this document . . . . . . . . . . . . . . 4 64 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3.1. O/TWAMP-Control Security . . . . . . . . . . . . . . . . . 5 66 3.2. O/TWAMP-Test Security . . . . . . . . . . . . . . . . . . 6 67 3.3. O/TWAMP Security Root . . . . . . . . . . . . . . . . . . 6 68 3.4. Co-existence of O/TWAMP and IPsec . . . . . . . . . . . . 6 69 4. O/TWAMP over IPsec . . . . . . . . . . . . . . . . . . . . . . 7 70 5. Others . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 73 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 76 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 79 1. Introduction 81 The active measurement protocols OWAMP [RFC4656] and TWAMP [RFC5357] 82 can be used to measure network performance parameters, such as 83 latency, bandwidth, and packet loss by sending probe packets and 84 monitoring their experience in the network. In order to guarantee 85 the accuracy of network measurement results, security aspects must be 86 considered, otherwise, attacks may occur and authenticity may be 87 violated. For example, if no protection is provided, an adversary in 88 the middle may modify packet timestamps, thus altering the 89 measurement results. 91 Cryptographic security mechanisms, such as IPsec, have been 92 considered during the early stage of working towards the definition 93 of the two protocols mentioned above. However, due to several 94 reasons, it was preferred to avoid tying the development and 95 deployment of O/TWAMP protocols to such security mechanisms. In 96 practice, for many networks, the issues listed in [RFC4656], Sec. 6.6 97 with respect to IPsec are still valid. However, we expect that in 98 the near future IPsec will be deployed in many more hosts and 99 networks than today. For example, IPsec tunnels may be used to 100 secure wireless channels. In this case, what we are interested in is 101 measuring network performance specifically for the traffic carried by 102 the tunnel, not in general over of the wireless channel. Therefore, 103 in this document we attempt to make the case that for networks where 104 wide deployment of IPsec and other security mechanisms is mandatory 105 for a variety of reasons, there are increasingly more use cases in 106 which IPsec and O/TWAMP protocols are needed simultaneously. In 107 other words, we argue that it is now time to specify how O/TWAMP can 108 be used in a network environment where IPsec is already deployed. In 109 such an environment, measuring IP performance over IPsec tunnels with 110 O/TWAMP is an important tool for operators. 112 Another advantage of IPsec key exchange protocol may be that it is 113 not necessary to use distinct keys in OWAMP-Control and OWAMP-Test 114 layers. One key for encryption and another for authentication is 115 sufficient for both the Control and Test layers. This obviates the 116 need to generate two keys and could reduce the complexity of O/TWAMP 117 protocols in this environment. This observation comes from the fact 118 that separate session keys in Control and Test layers are designed 119 for preventing reflection attacks when employing the current 120 mechanism. Once IPsec is employed, such a potential threat is 121 alleviated. Note that this will be very useful in the environments 122 where IPsec capability has been supported. 124 2. Terminology used in this document 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 [RFC2119]. 130 3. Motivation 132 Let us first consider why the reasons originally listed in [RFC4656] 133 Sec. 6.6 may not apply today in many cases. First, the argument made 134 is that partial authentication in O/TWAMP authentication mode is not 135 possible with IPsec. IPsec indeed cannot authenticate only a part of 136 a packet. However, in an environment where IPsec is already deployed 137 and actively used, partial authentication of O/TWAMP contradicts the 138 operational reasons dictating the use of IPsec. At the same time, 139 this limits the applicability and use of O/TWAMP in networks using 140 IPsec. 142 The second argument made is the need to keep separate deployment 143 paths between O/TWAMP and IPsec. In several currently deployed types 144 of networks, IPsec is widely used to protect the data and signaling 145 planes. For example, in mobile telecommunication networks, the 146 deployment rate of IPsec exceeds 95% with respect to the LTE serving 147 network. In older technology cellular networks, such as UMTS and 148 GSM, IPsec use penetration is lower, but still quite significant. 149 Additionally, there is a great number of IPSec-based VPN applications 150 which are widely used in business applications to provide end-to-end, 151 or host-to-host security over IEEE 802.11 wireless LANs. At the same 152 time, lots of standardized protocols make use of IPsec/IKE, including 153 MIPv4/v6, HIP, SCTP, BGP, NAT and SIP, just to name a few. 155 Third, with respect to the support of IPsec in lightweight embedded 156 devices, nowadays, a large number of limited-resource and low-cost 157 devices, such as Ethernet switches, DSL modems, and other such 158 devices come with support for IPsec "out of the box". Therefore 159 concerns about implementation, although likely valid a decade ago, 160 are not well founded today. 162 Fourth, everyday use of IPsec applications by field technicians, on 163 the one hand, and good understanding of the IPsec API by many 164 programmers, on the other, should not be anymore a reason for 165 concern. On the contrary: By now, IPsec open source code is 166 available for anyone who wants to use it. Therefore, although IPsec 167 does need a certain level of expertise to deal with it, in practice, 168 most competent technical personnel and programmers have no problems 169 using it on a daily basis. 171 O/TWAMP actually consists of two inter-related protocols: O/TWAMP- 172 Control and O/TWAMP-Test. O/TWAMP-Control is used to initiate, 173 start, and stop test sessions and to fetch their results, whereas 174 O/TWAMP-Test is used to exchange test packets between two measurement 175 nodes. In the following subsections we consider security for each 176 one separately and then make the case for using them over IPsec. 178 3.1. O/TWAMP-Control Security 180 O/TWAMP uses a simple cryptographic protocol which relies on AES-CBC 181 for confidentiality and on HMAC-SHA1 truncated to 128 bits for 182 message authentication. Three modes of operation are supported: 183 unauthenticated, authenticated, and encrypted. The authenticated and 184 encrypted modes require that endpoints possess a shared secret, 185 typically a passphrase. The secret key is derived from the 186 passphrase using a password-based key derivation function PBKDF2 187 (PKCS#5) [RFC2898]. 189 In the unauthenticated mode, the security parameters are left unused. 190 In the authenticated and encrypted modes, security parameters are 191 negotiated during the control connection establishment. Before the 192 client can send commands to a server, it has to establish a 193 connection to the server. Then, the client opens a TCP connection to 194 the server on the well-known port number 861. The server responds 195 with a server greeting, which contains the Challenge, Mode, Salt and 196 Count. If the client wants to establish the connection, it responds 197 with a Set-Up-Response message, wherein the KeyID, Token and Client 198 IV are included. The Token is the concatenation of a 16-octet 199 challenge, a 16-octet AES Session-key used for encryption, and a 32- 200 octet HMAC-SHA1 Session-key used for authentication. The token 201 itself is encrypted using AES in Cipher Block Chaining (AES-CBC). 203 Encryption is performed using a key derived from the shared secret 204 associated with KeyID. In the authenticated and encrypted modes, all 205 further communications are encrypted using the AES Session-key and 206 authenticated with the HMAC Session-key. The client encrypts 207 everything it transmits through the just-established O/TWAMP-Control 208 connection using stream encryption with Client-IV as the IV. 209 Correspondingly, the server encrypts its side of the connection using 210 Server-IV as the IV. The IVs themselves are transmitted in 211 cleartext. Encryption starts with the block immediately following 212 the block containing the IV. 214 The AES Session-key and HMAC Session-key are generated randomly by 215 the client. The HMAC Session-key is communicated along with the AES 216 Session-key during O/TWAMP-Control connection setup. The HMAC 217 Session-key is derived independently of the AES Session-key. 219 3.2. O/TWAMP-Test Security 221 The O/TWAMP-Test protocol runs over UDP, using sender and receiver IP 222 and port numbers negotiated during the Request-Session exchange. As 223 with O/TWAMP-Control, O/TWAMP-Test has three modes: unauthenticated, 224 authenticated, and encrypted. All O/TWAMP-Test sessions that are 225 spawned by an O/TWAMP-Control session inherit its mode. 227 The O/TWAMP-Test packet format is the same in authenticated and 228 encrypted modes. The encryption and authentication operations are, 229 however, different. Similarly with the respective O/TWAMP-Control 230 session, each O/TWAMP-Test session has two keys: an AES Session-key 231 and an HMAC Session-key. However, there is a difference in how the 232 keys are obtained. In the case of O/TWAMP-Control, the keys are 233 generated by the client and communicated (as part of the Token) 234 during connection setup through the Set-Up-Response message. In the 235 case of O/TWAMP-Test, the keys are derived from the O/TWAMP-Control 236 keys and the session identifier (SID), as inputs of the key 237 derivation function (KDF). The O/TWAMP-Test AES Session-key is 238 generated by using the O/TWAMP-Control AES Session-key, with the 16- 239 octet session identifier (SID), for encrypting and decrypting the 240 packets of the particular O/TWAMP-Test session. The O/TWAMP-Test 241 HMAC Session-key is generated by using the O/TWAMP-Control HMAC 242 Session-key, with the 16-octet session identifier (SID), for 243 authenticating the packets of the particular O/TWAMP-Test session. 245 3.3. O/TWAMP Security Root 247 As discussed above, the AES Session-key and HMAC Session-key used in 248 the O/TWAMP-Test protocol are derived from the AES Session-key and 249 HMAC Session-key which are used in O/TWAMP-Control protocol. The AES 250 Session-key and HMAC Session-key used in the O/TWAMP-Control protocol 251 are generated randomly by the client, and encrypted with the shared 252 secret associated with KeyID. Therefore, the security root is the 253 shared secret key. Thus, key provision and management are 254 complicated and need to be taken care of appropriately. 255 Comparatively, a certificate-based approach in IKEv2/IPsec can 256 automatically manage the security root and solve this problem. 258 3.4. Co-existence of O/TWAMP and IPsec 260 According to [RFC4656] "[t]he deployment paths of IPsec and OWAMP 261 could be separate if OWAMP does not depend on IPsec." The problem 262 may occur in practice is that the security mechanism of O/TWAMP and 263 IPsec cannot co-exist at the same time. IPsec provides 264 confidentiality and data integrity to IP datagrams. Distinct 265 protocols are provided: Authentication Header (AH), Encapsulating 266 Security Payload (ESP) and Internet Key Exchange (IKE v1/v2). Only 267 integrity protection can be provided with AH. Both integrity and 268 encryption can be provided with ESP. The IKE Protocol is used for 269 dynamical key negotiation and automatic key management. 271 When the sender and receiver implement O/TWAMP over IPsec, they need 272 to agree on a shared key during the establishment of the IPsec 273 tunnel; subsequently all IP packets sent by the sender are protected. 274 If the AH protocol is used, IP packets are transmitted in plaintext. 275 The authentication part covers the entire packet. So all test 276 information, such as UDP port number, and the test results will be 277 visible to any attacker, which can intercept these test packets, and 278 introduce errors or forge packets that may be injected during the 279 transmission. In order to avoid this attack, the receiver must 280 validate the integrity of these packets with the negotiated secret 281 key. If ESP is used, IP packets are encrypted, and hence no other 282 than the receiver can use the IPsec secret key and decrypt the IP 283 packet, and then it can obtain the test data to assess the IP network 284 performance based on the measurements. So both the sender and 285 receiver must support IPsec to generate the security secret key of 286 IPsec. 288 In the current implementation of O/TWAMP, after the test packets are 289 received by the receiver, it cannot execute active measurement over 290 IPsec. That is because the receiver knows only the shared secret key 291 but not the IPsec key, while the test packets are protected by the 292 IPsec key ultimately. Therefore, it needs to be considered how to 293 measure IP network performance in an IPsec tunnel with O/TWAMP. 294 Without this functionality, the use of OWAMP and TWAMP over IPsec is 295 hindered. 297 Of course, backward compatibility should be considered, as well. 298 That is, the intrinsic security method based on shared key as 299 specified in the O/TWAMP standards can also fit the other platforms. 300 There should be no impact on the current security mechanisms defined 301 in O/TWAMP for other use cases. This document describes a possible 302 solution to this problem which takes advantage of the secret key 303 derived by IPsec, to provision the key needed in RFC 4656 and RFC 304 5357. 306 4. O/TWAMP over IPsec 308 A security method based on a shared secret key has been defined in 309 O/TWAMP [RFC4656][RFC5357]. In this section, in order to employ 310 O/TWAMP over IPsec, a method of binding O/TWAMP and IKEv2 is 311 described, for those both the sender and receiver supporting the 312 IPsec protocols. The shared key used in the security of O/TWAMP is 313 derived from IPsec [RFC5996]. If the AH protocol is used, the IP 314 packets are transmitted in plaintext. All of O/TWAMP is integrity- 315 protected by IPsec. Even if the peers choose to opt for the 316 unauthenticated mode, IPsec integrity protection is extended to 317 O/TWAMP. In the authenticated and encrypted modes, the shared secret 318 can be derived from IKE SA or IPsec SA. If the shared secret key is 319 derived from IKE SA, SKEYSEED must be generated firstly. SKEYSEED 320 and its derivatives are computed as per [RFC5996], where prf is a 321 pseudorandom function: 323 SKEYSEED = prf(Ni | Nr, g^ir) 325 Ni and Nr are nonces, negotiated during initial exchange. g^ir is the 326 shared secret from the ephemeral Diffie-Hellman exchange and is 327 represented as a string of octets. SKEYSEED can be used as the 328 shared secret key directly, then the shared key is equal to SKEYSEED. 329 Alternatively, the shared secret key can be generated as follows: 331 Shared secret key=PRF{ SKEYSEED, Session ID} 333 wherein the session ID is the SID agreed during the O/TWAMP-Test 334 protocol. 336 If the shared secret key is derived from IPsec SA, the shared secret 337 key can be equal to KEYMAT, wherein 339 KEYMAT = prf+(SK_d, Ni | Nr) 341 The term "prf+" describes a function that outputs a pseudorandom 342 stream based on the inputs to a prf [RFC5996]; or the shared secret 343 key can be generated as follows: 345 Shared secret key=PRF{ KEYMAT, Session ID} 347 wherein the session ID is the SID agreed during the O/TWAMP-Test 348 protocol. 350 There are some cases for rekeying IKE SA and IPsec SA, after which 351 the corresponding key of SA is updated. Generally ESP and AH SAs 352 always exist in pairs, with one SA in each direction. If the SA is 353 deleted, the key generated from the IKE SA or IPsec SA should also be 354 updated. 356 As discussed above, a binding association between the key generated 357 from IPsec and the shared secret key needs to be considered. SA can 358 be identified by SPI and protocol uniquely for a given sender and a 359 receiver. So these parameters should be agreed upon during the 360 O/TWAMP protocol. When the sender and receiver execute O/TWAMP 361 protocol to negotiate integrity key, the IPsec protocol and SPI 362 should be checked. Only if two parameters are matched with the 363 information of IPsec, should the O/TWAMP connection be established. 364 As illustrated in Fig. 1, the SPI and protocol type are included in 365 the server greeting of the O/TWAMP-Control protocol. After the 366 client receives the greeting, it closes the connection if it receives 367 a greeting with an erroneous SPI and protocol value. Otherwise, the 368 client responds with the following Set-Up-Response message and 369 generates the shared secret key. This message exchange flow is 370 illustrated as Fig. 1. 372 +--------+ +--------+ 373 | Client | | Server | 374 +--------+ +--------+ 375 | | 376 | TCP Connection | 377 |<------------------------->| 378 | | 379 | Greeting message | 380 |<--------------------------| 381 | | 382 | Set-Up-Response | 383 |-------------------------->| 384 | | 385 | | 386 | Server-Start | 387 |<--------------------------| 388 | | 390 Figure 1. The procedure of O/TWAMP-Control 392 The format of server greeting is illustrated in Fig. 2. The unused 393 12 octets are used to carry the new parameter: protocol and SPIs. 395 0 1 2 3 396 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 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | protocol | 399 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | SPIi | 401 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | SPIr | 403 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | Modes | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | | 407 | Challenge (16 octets) | 408 | | 409 | | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | | 412 | Salt (16 octets) | 413 | | 414 | | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Count (4 octets) | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | | 419 | MBZ (12 octets) | 420 | | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 Figure 2. The format of server greeting 425 In ESP, when the IP packets are encrypted, no other than the receiver 426 can use the IPsec key and decrypt the IP packets. It gains the test 427 data to process measurement IP performance. In this case, the IPsec 428 tunnel between the sender and receiver provides additional security. 429 Even if the peers choose the unauthenticated mode, IPsec encryption 430 and integrity protection is provided to O/TWAMP. If the sender and 431 receiver also want to use authenticated or encrypted mode, the shared 432 secret can be also derived from IKE SA or IPsec SA. The method of 433 key generation and binding association is the same as AH protocol 434 mode. 436 Besides, there is encryption-only configuration in ESP, though not 437 recommended due to its limitations. Since it does not produce 438 integrity key in this case, either encryption-only ESP should be 439 prohibited for O/TWAMP, or a decryption failure should be 440 distinguished due to possible integrity attack. 442 5. Others 444 The community may want to revisit the arguments listed in [RFC4656], 445 Sec. 6.6. Other widely-used Internet security mechanisms, such as 446 TLS and DTLS, may also be considered for future use over and above of 447 what is already specified in O/TWAMP. 449 6. Security Considerations 451 As the shared secret key is derived from IPsec, the key derivation 452 algorithm strength and limitations are as per [RFC5996]. The 453 strength of a key derived from a Diffie-Hellman exchange using any of 454 the groups defined here depends on the inherent strength of the 455 group, the size of the exponent used, and the entropy provided by the 456 random number generator employed. The strength of all keys and 457 implementation vulnerabilities, particularly DoS attacks are as 458 defined in [RFC5996]. 460 7. IANA Considerations 462 There may be IANA considerations for allocating additional value for 463 these options. The values of the protocol field needed to be 464 assigned from the numbering space. 466 8. Acknowledgments 468 We would like to thank Eric Chen and Yakov Stein for their comments, 469 and Al Morton for pointing to previous work discussed in IPPM WG. 471 9. References 473 9.1. Normative References 475 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 476 Requirement Levels", BCP 14, RFC 2119, March 1997. 478 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 479 Zekauskas, "A One-way Active Measurement Protocol 480 (OWAMP)", RFC 4656, September 2006. 482 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 483 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 484 RFC 5357, October 2008. 486 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 487 "Internet Key Exchange Protocol Version 2 (IKEv2)", 488 RFC 5996, September 2010. 490 9.2. Informative References 492 [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography 493 Specification Version 2.0", RFC 2898, September 2000. 495 Authors' Addresses 497 Yang Cui 498 Huawei Technologies 499 Huawei Building, Q20, No.156, Rd. BeiQing 500 Haidian District, Beijing 100095 501 P. R. China 503 Email: cuiyang@huawei.com 505 Emily Bi 506 Huawei Technologies 507 Huawei Building, Q20, No.156, Rd. BeiQing 508 Haidian District, Beijing 100095 509 P. R. China 511 Phone: +86-10-82881907 512 Email: bixiaoyu@huawei.com 514 Kostas Pentikousis (editor) 515 Huawei Technologies 516 Carnotstrasse 4 517 10587 Berlin 518 Germany 520 Email: k.pentikousis@huawei.com