idnits 2.17.1 draft-ietf-ippm-ipsec-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 05, 2013) is 3949 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 (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPPM WG K. Pentikousis, Ed. 3 Internet-Draft Y. Cui 4 Intended status: Standards Track E. Zhang 5 Expires: January 06, 2014 Huawei Technologies 6 July 05, 2013 8 Network Performance Measurement for IPsec 9 draft-ietf-ippm-ipsec-00 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 the One-way and Two-Way Active Measurement Protocols (O/ 23 TWAMP) and proposes a method which combines IKEv2 and O/TWAMP as 24 defined in RFC 4656 and RFC 5357, respectively. This specification 25 aims, on the one hand, to ensure that O/TWAMP can be secured with the 26 best mechanisms we have at our disposal today while, on the other 27 hand, it facilitates the applicability of O/TWAMP to networks that 28 have already deployed IPsec. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on January 06, 2014. 47 Copyright Notice 48 Copyright (c) 2013 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3.1. O/TWAMP-Control Security . . . . . . . . . . . . . . . . 5 67 3.2. O/TWAMP-Test Security . . . . . . . . . . . . . . . . . . 6 68 3.3. O/TWAMP Security Root . . . . . . . . . . . . . . . . . . 6 69 3.4. O/TWAMP and IPsec . . . . . . . . . . . . . . . . . . . . 7 70 4. O/TWAMP for IPsec Networks . . . . . . . . . . . . . . . . . 8 71 4.1. Shared Key Derivation . . . . . . . . . . . . . . . . . . 8 72 4.2. Optimizations . . . . . . . . . . . . . . . . . . . . . . 10 73 4.2.1. Alternative 1 . . . . . . . . . . . . . . . . . . . . 11 74 4.2.2. Alternative 2 . . . . . . . . . . . . . . . . . . . . 13 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 77 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 80 8.2. Informative References . . . . . . . . . . . . . . . . . 15 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 83 1. Introduction 85 The One-way Active Measurement Protocol (OWAMP) [RFC4656] and the 86 Two-Way Active Measurement Protocol (TWAMP) [RFC5357] can be used to 87 measure network performance parameters, such as latency, bandwidth, 88 and packet loss by sending probe packets and monitoring their 89 experience in the network. In order to guarantee the accuracy of 90 network measurement results, security aspects must be considered. 91 Otherwise, attacks may occur and the authenticity of the measurement 92 results may be violated. For example, if no protection is provided, 93 an adversary in the middle may modify packet timestamps, thus 94 altering the measurement results. 96 Cryptographic security mechanisms, such as IPsec, have been 97 considered during the early stage of the specification of the two 98 active measurement protocols mentioned above. However, due to 99 several reasons, it was decided to avoid tying the development and 100 deployment of O/TWAMP to such security mechanisms. In practice, for 101 many networks, the issues listed in [RFC4656], Sec. 6.6 with respect 102 to IPsec are still valid. However, we expect that in the near future 103 IPsec will be deployed in many more hosts and networks than today. 104 For example, IPsec tunnels may be used to secure wireless channels. 105 In this case, what we are interested in is measuring network 106 performance specifically for the traffic carried by the tunnel, not 107 in general over the wireless channel. This document makes the case 108 that O/TWAMP should be cognizant when IPsec and other security 109 mechanisms are in place and can be leveraged upon. In other words, 110 it is now time to specify how O/TWAMP is used in a network 111 environment where IPsec is already deployed. We expect that in such 112 an environment, measuring IP performance over IPsec tunnels with O/ 113 TWAMP is an important tool for operators. 115 For example, when considering the use of O/TWAMP in networks with 116 IPsec deployed, we can take advantage of the IPsec key exchange 117 protocol [RFC5996]. In particular, we note that it is not necessary 118 to use distinct keys in OWAMP-Control and OWAMP-Test layers. One key 119 for encryption and another for authentication is sufficient for both 120 Control and Test layers. This obviates the need to generate two keys 121 for each layer and reduces the complexity of O/TWAMP protocols in an 122 IPsec environment. This observation comes from the fact that 123 separate session keys in the OWAMP-Control and OWAMP-Test layers were 124 designed for preventing reflection attacks when employing the current 125 mechanism. Once IPsec is employed, such a potential threat is 126 alleviated. 128 The remainder of this document is organized as follows. Section 3 129 motivates this work by revisiting the arguments made in [RFC4656] 130 against the use of IPsec; this section also summarizes protocol 131 operation with respect to security. Section 4 presents a method of 132 binding O/TWAMP and IKEv2 for network measurements between a sender 133 and a receiver which both support IPsec. Finally, Section 3 134 discusses the security considerations arising from the proposed 135 mechanisms. 137 2. Terminology 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in [RFC2119]. 143 3. Motivation 145 In order to motivate the solutions proposed in this document, let us 146 first revisit Section 6.6 of [RFC4656]. As we explain below, the 147 reasons originally listed therein may not apply in many cases today. 149 RFC 4656 opts against using IPsec and instead favors the use of "a 150 simple cryptographic protocol (based on a block cipher in CBC mode)". 151 The first argument justifying this decision in [RFC4656] is that 152 partial authentication in OWAMP authentication mode is not possible 153 with IPsec. IPsec indeed cannot authenticate only a part of a 154 packet. However, in an environment where IPsec is already deployed 155 and actively used, partial authentication for OWAMP contradicts the 156 operational reasons dictating the use of IPsec. It also increases 157 the operational complexity of OWAMP (and TWAMP) in networks where 158 IPsec is actively used and may in practice limit its applicability. 160 The second argument made is the need to keep separate deployment 161 paths between OWAMP and IPsec. In several currently deployed types 162 of networks IPsec is widely used to protect the data and signaling 163 planes. For example, in mobile telecommunication networks, the 164 deployment rate of IPsec exceeds 95% with respect to the LTE serving 165 network. In older technology cellular networks, such as UMTS and 166 GSM, IPsec use penetration is lower, but still quite significant. 167 Additionally, there is a great number of IPSec-based VPN applications 168 which are widely used in business applications to provide end-to-end 169 security over untrusted IEEE 802.11 wireless LANs. At the same time, 170 many IETF-standardized protocols make use of IPsec/IKE, including 171 MIPv4/v6, HIP, SCTP, BGP, NAT and SIP, just to name a few. 173 The third argument in [RFC4656] is that, effectively, the adoption of 174 IPsec in OWAMP may be problematic for "lightweight embedded devices". 175 However, since the publication of RFC 4656, a large number of 176 limited-resource and low-cost hardware, such as Ethernet switches, 177 DSL modems, and other such devices come with support for IPsec "out 178 of the box". Therefore concerns about implementation, although 179 likely valid a decade ago, are not well founded today. 181 Finally, everyday use of IPsec applications by field technicians and 182 good understanding of the IPsec API by many programmers should no 183 longer be a reason for concern. On the contrary: By now, IPsec open 184 source code is available for anyone who wants to use it. Therefore, 185 although IPsec does need a certain level of expertise to deal with 186 it, in practice, most competent technical personnel and programmers 187 have no problems using it on a daily basis. 189 OWAMP and TWAMP actually consist of two inter-related protocols: O/ 190 TWAMP-Control and O/TWAMP-Test. With respect to TWAMP, since "TWAMP 191 and OWAMP use the same protocol for establishment of Control and Test 192 procedures" [RFC5357] (Section 6), IPsec is also not considered. O/ 193 TWAMP-Control is used to initiate, start, and stop test sessions and 194 to fetch their results, whereas O/TWAMP-Test is used to exchange test 195 packets between two measurement nodes. 197 In the remainder of this section we review security for O/TWAMP- 198 Control and O/TWAMP-Test separately and then make the case for using 199 them over IPsec. 201 3.1. O/TWAMP-Control Security 203 O/TWAMP uses a simple cryptographic protocol which relies on 205 o AES in Cipher Block Chaining (AES-CBC) for confidentiality 207 o HMAC-SHA1 truncated to 128 bits for message authentication 209 Three modes of operation are supported: unauthenticated, 210 authenticated, and encrypted. The authenticated and encrypted modes 211 require that endpoints possess a shared secret, typically a 212 passphrase. The secret key is derived from the passphrase using a 213 password-based key derivation function PBKDF2 (PKCS#5) [RFC2898]. 215 In the unauthenticated mode, the security parameters are left unused. 216 In the authenticated and encrypted modes, security parameters are 217 negotiated during the control connection establishment. In short, 218 the client opens a TCP connection to the server in order to be able 219 to send OWAMP-Control commands. The server responds with a server 220 greeting, which contains the Challenge, Mode, Salt and Count. If the 221 client-requested mode is available, the client responds with a Set- 222 Up-Response message, wherein the KeyID, Token and Client IV are 223 included. The Token is the concatenation of a 16-octet challenge, a 224 16-octet AES Session-key used for encryption, and a 32-octet HMAC- 225 SHA1 Session-key used for authentication. The Token is encrypted 226 using AES-CBC. 228 Encryption uses a key derived from the shared secret associated with 229 KeyID. In the authenticated and encrypted modes, all further 230 communication is encrypted using the AES Session-key and 231 authenticated with the HMAC Session-key. The client encrypts 232 everything it transmits through the just-established O/TWAMP-Control 233 connection using stream encryption with Client-IV as the IV. 234 Correspondingly, the server encrypts its side of the connection using 235 Server-IV as the IV. The IVs themselves are transmitted in 236 cleartext. Encryption starts with the block immediately following 237 that containing the IV. 239 The AES Session-key and HMAC Session-key are generated randomly by 240 the client. The HMAC Session-key is communicated along with the AES 241 Session-key during O/TWAMP-Control connection setup. The HMAC 242 Session-key is derived independently of the AES Session-key. 244 3.2. O/TWAMP-Test Security 246 The O/TWAMP-Test protocol runs over UDP, using the sender and 247 receiver IP and port numbers that were negotiated during the Request- 248 Session exchange. O/TWAMP-Test has the same three modes as with O/ 249 TWAMP-Control (unauthenticated, authenticated, and encrypted) and all 250 O/TWAMP-Test sessions inherit the corresponding O/TWAMP-Control 251 session mode. 253 The O/TWAMP-Test packet format is the same in authenticated and 254 encrypted modes. The encryption and authentication operations are, 255 however, different. Similarly with the respective O/TWAMP-Control 256 session, each O/TWAMP-Test session has two keys: an AES Session-key 257 and an HMAC Session-key. However, there is a difference in how the 258 keys are obtained: 260 O/TWAMP-Control: the keys are generated by the client and 261 communicated (as part of the Token) during connection 262 establishment with the Set-Up-Response message. 264 O/TWAMP-Test: the keys are derived from the O/TWAMP-Control keys and 265 the session identifier (SID), which serve as inputs of the 266 key derivation function (KDF). The O/TWAMP-Test AES Session- 267 key is generated using the O/TWAMP-Control AES Session-key, 268 with the 16-octet session identifier (SID), for encrypting 269 and decrypting the packets of the particular O/TWAMP-Test 270 session. The O/TWAMP-Test HMAC Session-key is generated 271 using the O/TWAMP-Control HMAC Session-key, with the 16-octet 272 session identifier (SID), for authenticating the packets of 273 the particular O/TWAMP-Test session. 275 3.3. O/TWAMP Security Root 277 As discussed above, the AES Session-key and HMAC Session-key used in 278 the O/TWAMP-Test protocol are derived from the AES Session-key and 279 HMAC Session-key which are used in O/TWAMP-Control protocol. The AES 280 Session-key and HMAC Session-key used in the O/TWAMP-Control protocol 281 are generated randomly by the client, and encrypted with the shared 282 secret associated with KeyID. Therefore, the security root is the 283 shared secret key. Thus, key provision and management may become 284 overly complicated. Comparatively, a certificate-based approach 285 using IKEv2/IPsec can automatically manage the security root and 286 solve this problem, as we explain in Section 4. 288 3.4. O/TWAMP and IPsec 290 According to RFC 4656 the "deployment paths of IPsec and OWAMP could 291 be separate if OWAMP does not depend on IPsec." However, the problem 292 that arises in practice is that the security mechanism of O/TWAMP and 293 IPsec cannot coexist at the same time without adding overhead or 294 increasing complexity. 296 IPsec provides confidentiality and data integrity to IP datagrams. 297 Distinct protocols are provided: Authentication Header (AH), 298 Encapsulating Security Payload (ESP) and Internet Key Exchange (IKE 299 v1/v2). AH provides only integrity protection, while ESP can also 300 provide encryption. IKE is used for dynamical key negotiation and 301 automatic key management. 303 When sender and receiver implement O/TWAMP over IPsec, they need to 304 agree on a shared secret key during the IPsec tunnel establishment. 305 Subsequently, all IP packets sent by the sender are protected. If 306 the AH protocol is used, IP packets are transmitted in plaintext. 307 The authentication part covers the entire packet. So all test 308 information, such as UDP port number, and the test results will be 309 visible to any attacker, which can intercept these test packets, and 310 introduce errors or forge packets that may be injected during the 311 transmission. In order to avoid this attack, the receiver must 312 validate the integrity of these packets with the negotiated secret 313 key. If ESP is used, IP packets are encrypted, and hence only the 314 receiver can use the IPsec secret key to decrypt the IP packet, and 315 obtain the test data in order to assess the IP network performance 316 based on the measurements. Both the sender and receiver must support 317 IPsec to generate the security secret key of IPsec. 319 Currently, after the test packets are received by the receiver, it 320 cannot execute active measurement over IPsec. That is because the 321 receiver knows only the shared secret key but not the IPsec key, 322 while the test packets are protected by the IPsec key ultimately. 323 Therefore, it needs to be considered how to measure IP network 324 performance in an IPsec tunnel with O/TWAMP. Without this 325 functionality, the use of OWAMP and TWAMP over IPsec is hindered. 327 Of course, backward compatibility should be considered as well. That 328 is, the intrinsic security method based on shared key as specified in 329 the O/TWAMP standards can also still be suitable for other network 330 settings. There should be no impact on the current security 331 mechanisms defined in O/TWAMP for other use cases. This document 332 describes possible solutions to this problem which take advantage of 333 the secret key derived by IPsec, in order to provision the key needed 334 for active network measurements based on RFC 4656 and RFC 5357. 336 4. O/TWAMP for IPsec Networks 338 This section presents a method of binding O/TWAMP and IKEv2 for 339 network measurements between a sender and a receiver which both 340 support IPsec. In short, the shared key used for securing O/TWAMP 341 traffic is derived using IKEv2 [RFC5996]. 343 4.1. Shared Key Derivation 345 If the AH protocol is used, the IP packets are transmitted in 346 plaintext, but all O/TWAMP traffic is integrity-protected by IPsec. 347 Therefore, even if the peers choose to opt for the unauthenticated 348 mode, IPsec integrity protection is extended to O/TWAMP. 350 In the authenticated and encrypted modes, the shared secret can be 351 derived from the IKEv2 Security Association (SA), or IPsec SA. If 352 the shared secret key is derived from the IKEv2 SA, SKEYSEED must be 353 generated firstly. 355 SKEYSEED and its derivatives are computed as per [RFC5996], where prf 356 is a pseudorandom function: 358 SKEYSEED = prf( Ni | Nr, g^ir ) 360 Ni and Nr are nonces negotiated during the initial exchange. g^ir is 361 the shared secret from the ephemeral Diffie-Hellman exchange and is 362 represented as a string of octets. Note that this SKEYSEED can be 363 used as the O/TWAMP shared secret key directly. 365 Alternatively, the shared secret key can be generated as follows: 367 Shared secret key = PRF{ SKEYSEED, Session ID } 369 wherein the Session ID is the O/TWAMP-Test SID. 371 If the shared secret key is derived from the IPsec SA, the shared 372 secret key can be equal to KEYMAT, wherein 374 KEYMAT = prf+( SK_d, Ni | Nr ) 376 The term "prf+" stands for a function that outputs a pseudorandom 377 stream based on the inputs to a prf, while SK_d is defined in 378 [RFC5996] (Sections 2.13 and 1.2, respectively). The shared secret 379 key can alternatively be generated as follows: 381 Shared secret key = PRF{ KEYMAT, Session ID } 383 wherein the session ID is is the O/TWAMP-Test SID. 385 If rekeying for the IKE SA and IPsec SA occurs, the corresponding key 386 of the SA is updated. Generally, ESP and AH SAs always exist in 387 pairs, with one SA in each direction. If the SA is deleted, the key 388 generated from the IKE SA or IPsec SA should also be updated. 390 As discussed above, a binding association between the key generated 391 from IPsec and the O/TWAMP shared secret key needs to be considered. 392 The Security Association can be identified by the Security Parameter 393 Index (SPI) and protocol uniquely for a given sender and receiver 394 pair. So these parameters should be agreed upon during the 395 initiation of O/TWAMP. At the stage that the sender and receiver 396 negotiate the integrity key, the IPsec protocol and SPI SHOULD be 397 checked. Only if the two parameters are matched with the IPsec 398 information, should the O/TWAMP connection be established. 400 The SPI and protocol type are included in the Server Greeting of the 401 O/TWAMP-Control protocol (Figure 1). After the client receives the 402 greeting, it MUST close the connection if it receives a greeting with 403 an erroneous SPI and protocol value (Figure 2). Otherwise, the 404 client SHOULD respond with the following Set-Up-Response message and 405 generates the shared secret key. 407 +--------+ +--------+ 408 | Client | | Server | 409 +--------+ +--------+ 410 | | 411 |<---- TCP Connection ----->| 412 | | 413 |<---- Greeting message ----| 414 | | 415 |----- Set-Up-Response ---->| 416 | | 417 |<---- Server-Start --------| 418 | | 420 Figure 1: Initiation of O/TWAMP-Control 422 When using ESP, all IP packets are encrypted, and therefore only the 423 receiver can use the IPsec key to decrypt the IP active measurement 424 packets. In this case, the IPsec tunnel between the sender and 425 receiver provides additional security: even if the peers choose the 426 unauthenticated mode, IPsec encryption and integrity protection is 427 provided to O/TWAMP. If the sender and receiver decide to use the 428 authenticated or encrypted mode, the shared secret can also be 429 derived from IKE SA or IPsec SA. The method for key generation and 430 binding association is the same discussed above for the AH protocol 431 mode. 433 0 1 2 3 434 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 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | Protocol | 437 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | SPIi | 439 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | SPIr | 441 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | Mode | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | | 445 | Challenge (16 octets) | 446 | | 447 | | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | | 450 | Salt (16 octets) | 451 | | 452 | | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Count (4 octets) | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | | 457 | MBZ (12 octets) | 458 | | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 Figure 2: Server Greeting format 463 There is an encryption-only configuration in ESP, though this is not 464 recommended due to its limitations. Since it does not produce 465 integrity key in this case, either encryption-only ESP should be 466 prohibited for O/TWAMP, or a decryption failure should be 467 distinguished due to possible integrity attack. 469 4.2. Optimizations 471 The previous subsection described a method for deriving the shared 472 key for O/TWAMP by capitalizing on IPsec. We note, however, that the 473 O/TWAMP protocol uses distinct encryption and integrity keys for O/ 474 TWAMP-Control and O/TWAMP-Test. Consequently, four keys are 475 generated to protect O/TWAMP-Control and O/TWAMP-Test messages. 477 In fact, once IPsec is employed, one key for encryption and another 478 for authentication is sufficient for both the Control and Test 479 protocols. Therefore, in an IPsec environment we can reduce the 480 operational complexity of O/TWAMP protocols in a straightforward 481 manner, as discussed below. 483 EDITOR'S NOTE: 484 We expect that both optimization alternatives will be discussed 485 in the IPPM working group and we are looking forward to 486 community comments and feedback. 488 4.2.1. Alternative 1 490 If an IPsec SA is established between the server and the client, or 491 both server and client support IPsec, the root key for O/TWAMP-based 492 active network measurements can be derived from the IKE or IPsec SA. 494 If the root key that will be used in O/TWAMP network performance 495 measurements is derived from the IKE SA, SKEYSEED must be generated 496 first. SKEYSEED and its derivatives are computed as per [RFC5996]. 497 SKEYSEED can be used as the root key of O/TWAMP directly; then the 498 root key of O/TWAMP is equal to SKEYSEED. 500 If the root key of O/TWAMP is derived from the IPsec SA, the shared 501 secret key can be equal to KEYMAT. KEYMAT and its derivatives are 502 computed as per usual [RFC5996]. Then, the session keys for 503 encryption and authentication can be derived from the root key of O/ 504 TWAMP, wherein: 506 Session key for enc = PRF{ root key of O/TWAMP, "O/TWAMP enc" } 508 Session key for auth = PRF{ root key of O/TWAMP, "O/TWAMP auth" } 510 The former can provide encryption protection for O/TWAMP-Control and 511 O/TWAMP-Test messages, while the latter can provide integrity 512 protection. 514 Note that there are cases where rekeying the IKE SA and IPsec SA is 515 necessary, and after which the corresponding key of SA is updated. 516 If the SA is deleted, the O/TWAMP shared key generated from the IKE 517 SA or IPsec SA should also be updated. 519 In this optimization, the O/TWAMP-Control message exchange flow 520 remains as per Figure 1. However, the optimized Server Greeting 521 (Figure 3) can do without the Salt and Count parameters (cf. Figure 522 2) since the root key of O/TWAMP is derived from IKE SA or IPsec SA. 523 O/TWAMP security can rely on IPsec and the SPI can uniquely identify 524 the IPsec SA from which the root key was derived from. 526 0 1 2 3 527 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 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | Protocol | 530 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | SPIi | 532 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | SPIr | 534 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | Mode | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | | 538 | Challenge (16 octets) | 539 | | 540 | | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | | 543 | MBZ (12 octets) | 544 | | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 Figure 3: Optimized Server Greeting format 549 The format of the Set-Up-Response is illustrated in Figure 4. The 550 Token carried in the Set-Up-Response is calculated as follows: 552 Token = Enc_root-key( Challenge ) 554 where Challenge is the value received earlier in the Server Greeting 555 (Figure 3) 557 0 1 2 3 558 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 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | Mode | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | | 563 | Token (16 octets) | 564 | | 565 | | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | | 568 | Client-IV (12 octets) | 569 | | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 Figure 4: Set-Up-Response in Alternative 1 574 If the server authenticates the token successfully, then the O/TWAMP- 575 Control message exchange flow can continue. 577 4.2.2. Alternative 2 579 Another way for optimizing the shared key use is to set the O/TWAMP 580 session keys equal to the keys of the IPsec SA directly, i.e: 582 Session key for enc = encryption key of the IPsec SA 584 Session key for auth = integrity key of the IPsec SA 586 The former session key can provide encryption protection for O/TWAMP- 587 Control and O/TWAMP-Test messages, while the latter can provide 588 integrity protection. The point made in the previous subsection 589 about rekeying the IPsec SA applies here too. 591 0 1 2 3 592 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 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | Protocol | 595 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | SPIi | 597 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | SPIr | 599 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | Mode | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | | 603 | MBZ (12 octets) | 604 | | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 Figure 5: Optimized Server Greeting format 609 0 1 2 3 610 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 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | Mode | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | | 615 | Client-IV (12 octets) | 616 | | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 Figure 6: Set-Up-Response in Alternative 2 621 The O/TWAMP control message exchange flow is the same (Figure 1), 622 while the Server Greeting format is illustrated in Figure 5. The 623 Salt, Count and Challenge parameters can be eliminated since the 624 session keys of O/TWAMP are equal to keys of an IPsec SA directly. 625 SPI can identify the IPsec SA where the session keys derived from. 626 The Set-Up-Response is illustrated in Figure 6. 628 5. Security Considerations 630 As the shared secret key is derived from IPsec, the key derivation 631 algorithm strength and limitations are as per [RFC5996]. The 632 strength of a key derived from a Diffie-Hellman exchange using any of 633 the groups defined here depends on the inherent strength of the 634 group, the size of the exponent used, and the entropy provided by the 635 random number generator employed. The strength of all keys and 636 implementation vulnerabilities, particularly Denial of Service (DoS) 637 attacks are as defined in [RFC5996]. 639 EDITOR'S NOTE: 640 The IPPM community may want to revisit the arguments listed in 641 [RFC4656], Sec. 6.6. Other widely-used Internet security 642 mechanisms, such as TLS and DTLS, may also be considered for 643 future use over and above of what is already specified in 644 [RFC4656] [RFC5357]. 646 6. IANA Considerations 648 IANA may need to allocate additional values for the options presented 649 in this document. The values of the protocol field needed to be 650 assigned from the numbering space. 652 7. Acknowledgments 654 Emily Bi contributed to an earlier version of this document. 656 We thank Eric Chen and Yakov Stein for their comments on this draft, 657 and Al Morton for the discussion on related earlier work in IPPM WG. 659 8. References 661 8.1. Normative References 663 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 664 Requirement Levels", BCP 14, RFC 2119, March 1997. 666 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 667 Zekauskas, "A One-way Active Measurement Protocol 668 (OWAMP)", RFC 4656, September 2006. 670 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 671 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 672 RFC 5357, October 2008. 674 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 675 "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 676 5996, September 2010. 678 8.2. Informative References 680 [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography 681 Specification Version 2.0", RFC 2898, September 2000. 683 Authors' Addresses 685 Kostas Pentikousis (editor) 686 Huawei Technologies 687 Carnotstrasse 4 688 10587 Berlin 689 Germany 691 Email: k.pentikousis@huawei.com 693 Yang Cui 694 Huawei Technologies 695 Huawei Building, Q20, No.156, Rd. BeiQing 696 Haidian District , Beijing 100095 697 P. R. China 699 Email: cuiyang@huawei.com 701 Emma Zhang 702 Huawei Technologies 703 Huawei Building, Q20, No.156, Rd. BeiQing 704 Haidian District , Beijing 100095 705 P. R. China 707 Email: emma.zhanglijia@huawei.com