idnits 2.17.1 draft-ietf-ipsecme-ikev2-intermediate-04.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 (June 15, 2020) is 1411 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: 'CERTREQ' is mentioned on line 144, but not defined -- Obsolete informational reference (is this intentional?): RFC 8229 (Obsoleted by RFC 9329) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Smyslov 3 Internet-Draft ELVIS-PLUS 4 Intended status: Standards Track June 15, 2020 5 Expires: December 17, 2020 7 Intermediate Exchange in the IKEv2 Protocol 8 draft-ietf-ipsecme-ikev2-intermediate-04 10 Abstract 12 This documents defines a new exchange, called Intermediate Exchange, 13 for the Internet Key Exchange protocol Version 2 (IKEv2). This 14 exchange can be used for transferring large amount of data in the 15 process of IKEv2 Security Association (SA) establishment. 16 Introducing Intermediate Exchange allows re-using existing IKE 17 Fragmentation mechanism, that helps to avoid IP fragmentation of 18 large IKE messages, but cannot be used in the initial IKEv2 exchange. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on December 17, 2020. 37 Copyright Notice 39 Copyright (c) 2020 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3 56 3. Intermediate Exchange Details . . . . . . . . . . . . . . . . 3 57 3.1. Support for Intermediate Exchange Negotiation . . . . . . 3 58 3.2. Using Intermediate Exchange . . . . . . . . . . . . . . . 4 59 3.3. The IKE_INTERMEDIATE Exchange Protection and 60 Authentication . . . . . . . . . . . . . . . . . . . . . 5 61 3.3.1. Protection of the IKE_INTERMEDIATE Messages . . . . . 5 62 3.3.2. Authentication of the IKE_INTERMEDIATE Exchanges . . 5 63 3.4. Error Handling in the IKE_INTERMEDIATE Exchange . . . . . 8 64 4. Interaction with other IKEv2 Extensions . . . . . . . . . . . 9 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 70 8.2. Informative References . . . . . . . . . . . . . . . . . 11 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 73 1. Introduction 75 The Internet Key Exchange protocol version 2 (IKEv2) defined in 76 [RFC7296] uses UDP as a transport for its messages. If size of the 77 messages is large enough, IP fragmentation takes place, that may 78 interfere badly with some network devices. The problem is described 79 in more detail in [RFC7383], which also defines an extension to the 80 IKEv2 called IKE Fragmentation. This extension allows IKE messages 81 to be fragmented at IKE level, eliminating possible issues caused by 82 IP fragmentation. However, the IKE Fragmentation cannot be used in 83 the initial IKEv2 exchange (IKE_SA_INIT). This limitation in most 84 cases is not a problem, since the IKE_SA_INIT messages used to be 85 small enough not to cause IP fragmentation. 87 However, the situation has been changing recently. One example of 88 the need to transfer large amount of data before IKE SA is created is 89 using Quantum Computer resistant key exchange methods in IKEv2. 90 Recent progress in Quantum Computing has brought a concern that 91 classical Diffie-Hellman key exchange methods will become insecure in 92 a relatively near future and should be replaced with Quantum Computer 93 (QC) resistant ones. Currently most of QC-resistant key exchange 94 methods have large public keys. If these keys are exchanged in the 95 IKE_SA_INIT, then most probably IP fragmentation will take place, 96 therefore all the problems caused by it will become inevitable. 98 A possible solution to the problem would be to use TCP as a transport 99 for IKEv2, as defined in [RFC8229]. However this approach has 100 significant drawbacks and is intended to be a "last resort" when UDP 101 transport is completely blocked by intermediate network devices. 103 This specification describes a way to transfer large amount of data 104 in IKEv2 using UDP transport. For this purpose the document defines 105 a new exchange for the IKEv2 protocol, called Intermediate Exchange 106 or IKE_INTERMEDIATE. One or more these exchanges may take place 107 right after the IKE_SA_INIT exchange and prior to the IKE_AUTH 108 exchange. The IKE_INTERMEDIATE exchange messages can be fragmented 109 using IKE Fragmentation mechanism, so these exchanges may be used to 110 transfer large amounts of data which don't fit into the IKE_SA_INIT 111 exchange without causing IP fragmentation. 113 The Intermediate Exchange can be used to transfer large public keys 114 of QC-resistant key exchange methods, but its application is not 115 limited to this use case. This exchange can also be used whenever 116 some data need to be transferred before the IKE_AUTH exchange and for 117 some reason the IKE_SA_INIT exchange is not suited for this purpose. 118 This document defines the IKE_INTERMEDIATE exchange without tying it 119 to any specific use case. It is expected that separate 120 specifications will define for which purposes and how the 121 IKE_INTERMEDIATE exchange is used in the IKEv2. 123 2. Terminology and Notation 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 127 "OPTIONAL" in this document are to be interpreted as described in BCP 128 14 [RFC2119] [RFC8174] when, and only when, they appear in all 129 capitals, as shown here. 131 3. Intermediate Exchange Details 133 3.1. Support for Intermediate Exchange Negotiation 135 The initiator indicates its support for Intermediate Exchange by 136 including a notification of type INTERMEDIATE_EXCHANGE_SUPPORTED in 137 the IKE_SA_INIT request message. If the responder also supports this 138 exchange, it includes this notification in the response message. 140 Initiator Responder 141 ----------- ----------- 142 HDR, SAi1, KEi, Ni, 143 [N(INTERMEDIATE_EXCHANGE_SUPPORTED)] --> 144 <-- HDR, SAr1, KEr, Nr, [CERTREQ], 145 [N(INTERMEDIATE_EXCHANGE_SUPPORTED)] 147 The INTERMEDIATE_EXCHANGE_SUPPORTED is a Status Type IKEv2 148 notification. Its Notify Message Type is 16438. Protocol ID and SPI 149 Size are both set to 0. This specification doesn't define any data 150 this notification may contain, so the Notification Data is left 151 empty. However, future enhancements of this specification may 152 override this. Implementations MUST ignore the non-empty 153 Notification Data if they don't understand its purpose. 155 3.2. Using Intermediate Exchange 157 If both peers indicated their support for the Intermediate Exchange, 158 the initiator may use one or more these exchanges to transfer 159 additional data. Using the IKE_INTERMEDIATE exchange is optional, 160 the initiator may find it unnecessary after completing the 161 IKE_SA_INIT exchange. 163 The Intermediate Exchange is denoted as IKE_INTERMEDIATE, its 164 Exchange Type is 43. 166 Initiator Responder 167 ----------- ----------- 168 HDR, ..., SK {...} --> 169 <-- HDR, ..., SK {...} 171 The initiator may use several IKE_INTERMEDIATE exchanges if 172 necessary. Since initiator's Window Size is initially set to one 173 (Section 2.3 of [RFC7296]), these exchanges MUST follow each other 174 and MUST all be completed before the IKE_AUTH exchange is initiated. 175 The IKE SA MUST NOT be considered as established until the IKE_AUTH 176 exchange is successfully completed. 178 The Message IDs for the IKE_INTERMEDIATE exchanges MUST be chosen 179 according to the standard IKEv2 rule, described in the Section 2.2. 180 of [RFC7296], i.e. it is set to 1 for the first IKE_INTERMEDIATE 181 exchange, 2 for the next (if any) and so on. The message ID for the 182 first pair of the IKE_AUTH messages is one more than the one that was 183 used in the last IKE_INTERMEDIATE exchange. 185 If the presence of NAT is detected in the IKE_SA_INIT exchange via 186 NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP 187 notifications, then the peers MUST switch to port 4500 immediately 188 once this exchange is completed, i.e. in the first IKE_INTERMEDIATE 189 exchange. 191 The content of the IKE_INTERMEDIATE exchange messages depends on the 192 data being transferred and will be defined by specifications 193 utilizing this exchange. However, since the main motivation for the 194 IKE_INTERMEDIATE exchange is to avoid IP fragmentation when large 195 amount of data need to be transferred prior to IKE_AUTH, the 196 Encrypted payload MUST be present in the IKE_INTERMEDIATE exchange 197 messages and payloads containing large data MUST be placed inside. 198 This will allow IKE Fragmentation [RFC7383] to take place, provided 199 it is supported by the peers and negotiated in the initial exchange. 201 3.3. The IKE_INTERMEDIATE Exchange Protection and Authentication 203 3.3.1. Protection of the IKE_INTERMEDIATE Messages 205 The keys SK_e[i/r] and SK_a[i/r] for the Encrypted payload in the 206 IKE_INTERMEDIATE exchanges are computed in a standard fashion, as 207 defined in the Section 2.14 of [RFC7296]. Every subsequent 208 IKE_INTERMEDIATE exchange uses the most recently calculated IKE SA 209 keys before this exchange is started. So, the first IKE_INTERMEDIATE 210 exchange always uses SK_e[i/r] and SK_a[i/r] keys that were computed 211 as a result of the IKE_SA_INIT exchange. If the first 212 IKE_INTERMEDIATE exchange performs additional key exchange resulting 213 in the update of SK_e[i/r] and SK_a[i/r], then these updated keys are 214 used for encryption and authentication of the next IKE_INTERMEDIATE 215 exchange, otherwise the current keys are used, and so on. 217 3.3.2. Authentication of the IKE_INTERMEDIATE Exchanges 219 The content of the IKE_INTERMEDIATE exchanges must be authenticated 220 in the IKE_AUTH exchange. For this purpose the definition of the 221 blob to be signed (or MAC'ed) from the Section 2.15 of [RFC7296] is 222 modified as follows in case INTERMEDIATE exchange(s) took place: 224 InitiatorSignedOctets = RealMsg1 | NonceRData | MACedIDForI | IntAuth 225 ResponderSignedOctets = RealMsg2 | NonceIData | MACedIDForR | IntAuth 227 IntAuth = IntAuth_1 [| IntAuth_2 [| IntAuth_3 ... ]] 229 IntAuth_1 = IntAuth_1_I | IntAuth_1_R 230 IntAuth_2 = IntAuth_2_I | IntAuth_2_R 231 IntAuth_3 = IntAuth_3_I | IntAuth_3_R 232 ... 234 IntAuth_1_I = prf(SK_pi_1, IntAuth_1_I_A [| IntAuth_1_I_P]) 235 IntAuth_2_I = prf(SK_pi_2, IntAuth_2_I_A [| IntAuth_2_I_P]) 236 IntAuth_3_I = prf(SK_pi_3, IntAuth_3_I_A [| IntAuth_3_I_P]) 237 ... 239 IntAuth_1_R = prf(SK_pr_1, IntAuth_1_R_A [| IntAuth_1_R_P]) 240 IntAuth_2_R = prf(SK_pr_2, IntAuth_2_R_A [| IntAuth_2_R_P]) 241 IntAuth_3_R = prf(SK_pr_3, IntAuth_3_R_A [| IntAuth_3_R_P]) 242 ... 244 IntAuth_1_I/IntAuth_1_R, IntAuth_2_I/IntAuth_2_R, IntAuth_3_I/ 245 IntAuth_3_R, etc. represent the results of applying the negotiated 246 prf to the content of the IKE_INTERMEDIATE messages sent by the 247 initiator (IntAuth_*_I) and by the responder (IntAuth_*_R) in an 248 order of increasing Message IDs (i.e. in an order the 249 IKE_INTERMEDIATE exchanges took place). The prf is applied to the 250 two chunks of data: mandatory IntAuth_*_[I/R]_A and optional 251 IntAuth_*_[I/R]_P. The IntAuth_*_[I/R]_A chunk lasts from the first 252 octet of the IKE Header (not including prepended four octets of 253 zeros, if port 4500 is used) to the last octet of the Encrypted 254 Payload header. The IntAuth_*_[I/R]_P chunk is present if the 255 Encrypted payload is not empty. It consists of the not yet encrypted 256 content of the Encrypted payload, excluding the Initialization 257 Vector, the Padding, the Pad Length and the Integrity Checksum Data 258 fields (see 3.14 of [RFC7296] for description of the Encrypted 259 payload). In other words, the IntAuth_*_[I/R]_P chunk is the inner 260 payloads of the Encrypted payload in plaintext form. 262 1 2 3 263 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 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ ^ 265 | IKE SA Initiator's SPI | | | 266 | | | | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I | 268 | IKE SA Responder's SPI | K | 269 | | E | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 271 | Next Payload | MjVer | MnVer | Exchange Type | Flags | H | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d | 273 | Message ID | r A 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 275 | Adjusted Length | | | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v | 277 | | | 278 ~ Unencrypted payloads (if any) ~ | 279 | | | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ | 281 | Next Payload |C| RESERVED | Adjusted Payload Length | | | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E v 283 | Initialization Vector | n 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ c ^ 285 | | r | 286 ~ Inner payloads (not yet encrypted) ~ P 287 | | P | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ l v 289 | Padding (0-255 octets) | Pad Length | d 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 291 ~ Integrity Checksum Data ~ | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v 294 Figure 1: Data to Authenticate in the IKE_INTERMEDIATE Exchange 295 Messages 297 Figure 1 illustrates the layout of the IntAuth_*_[I/R]_P (denoted as 298 P) and the IntAuth_*_[I/R]_A (denoted as A) chunks in case the 299 Encrypted payload is not empty. 301 For the purpose of prf calculation the Length field in the IKE header 302 and the Payload Length field in the Encrypted Payload header are 303 adjusted so that they don't count the lengths of Initialization 304 Vector, Integrity Checksum Data and Padding (along with Pad Length 305 field). In other words, the Length field in the IKE header (denoted 306 as Adjusted Length in Figure 1) is set to the sum of the lengths of 307 IntAuth_*_[I/R]_A and IntAuth_*_[I/R]_P, and the Payload Length field 308 in the Encrypted Payload header (denoted as Adjusted Payload Length 309 in Figure 1) is set to the length of IntAuth_*_[I/R]_P plus the size 310 of the Payload header (four octets). 312 The prf calculations MUST be applied to whole messages only, before 313 possible IKE Fragmentation. This ensures that the IntAuth will be 314 the same regardless of whether IKE Fragmentation takes place or not. 315 This is important since [RFC7383] allows sending first unfragmented 316 message and then resending it in fragmented form in case of no reply 317 is received. If the message was received in fragmented form, it 318 should be reconstructed before calculating prf as if it were received 319 unfragmented. The RESERVED field in the recontructed Encrypted 320 Payload header MUST be set to the value of the RESERVED field in the 321 Encrypted Fragment payload header from the first fragment (that with 322 Fragment Number equal to 1). 324 Note that it is possible to avoid actual reconstruction of the 325 message by incrementally calculating prf on decrypted (or ready to be 326 encrypted) fragments. However care must be taken to properly replace 327 the content of the Next Header and the Length fields so that the 328 result of computing prf is the same as if it were computed on 329 reconstructed message. 331 Each calculation of IntAuth_*_[I/R] uses its own keys SK_p[i/r]_*, 332 which are the most recently updated SK_p[i/r] keys available before 333 the corresponded IKE_INTERMEDIATE exchange is started. The first 334 IKE_INTERMEDIATE exchange always uses SK_p[i/r] keys that were 335 computed in the IKE_SA_INIT as SK_p[i/r]_1. If the first 336 IKE_INTERMEDIATE exchange performs additional key exchange resulting 337 in SK_p[i/r] update, then this updated SK_p[i/r] are used as SK_p[i/ 338 r]_2, otherwise the original SK_p[i/r] are used, and so on. Note, 339 that if keys are updated then for any given IKE_INTERMEDIATE exchange 340 the keys SK_e[i/r] and SK_a[i/r] used for its messages protection 341 (see Section 3.3.1) and the keys SK_p[i/r] for its authentication are 342 always from the same generation. 344 3.4. Error Handling in the IKE_INTERMEDIATE Exchange 346 Since messages of the IKE_INTERMEDIATE exchange are not authenticated 347 until the IKE_AUTH exchange successfully completes, possible errors 348 need to be handled with care. There is a trade-off between providing 349 a better diagnostics of the problem and a risk to become a part of 350 DoS attack. See Section 2.21.1 and 2.21.2 of [RFC7296] describe how 351 errors are handled in initial IKEv2 exchanges, these considerations 352 are also applied to the IKE_INTERMEDIATE exchange. 354 4. Interaction with other IKEv2 Extensions 356 The IKE_INTERMEDIATE exchanges MAY be used during the IKEv2 Session 357 Resumption [RFC5723] between the IKE_SESSION_RESUME and the IKE_AUTH 358 exchanges. To be able to use it peers MUST negotiate support for 359 intermediate exchange by including INTERMEDIATE_EXCHANGE_SUPPORTED 360 notifications in the IKE_SESSION_RESUME messages. Note, that a flag 361 whether peers supported the IKE_INTERMEDIATE exchange is not stored 362 in the resumption ticket and is determined each time from the 363 IKE_SESSION_RESUME exchange. 365 5. Security Considerations 367 The data that is transferred by means of the IKE_INTERMEDIATE 368 exchanges is not authenticated until the subsequent IKE_AUTH exchange 369 is completed. However, if the data is placed inside the Encrypted 370 payload, then it is protected from passive eavesdroppers. In 371 addition the peers can be certain that they receives messages from 372 the party he/she performed the IKE_SA_INIT with if they can 373 successfully verify the Integrity Checksum Data of the Encrypted 374 payload. 376 The main application for Intermediate Exchange is to transfer large 377 amount of data before IKE SA is set up without causing IP 378 fragmentation. For that reason it is expected that in most cases IKE 379 Fragmentation will be employed in the IKE_INTERMEDIATE exchanges. 380 Section 5 of [RFC7383] contains security considerations for IKE 381 Fragmentation. 383 Note, that if an attacker was able to break key exchange in real time 384 (e.g. by means of Quantum Computer), then the security of the 385 IKE_INTERMEDIATE exchange would degrade. In particular, such an 386 attacker would be able both to read data contained in the Encrypted 387 payload and to forge it. The forgery would become evident in the 388 IKE_AUTH exchange (provided the attacker cannot break employed 389 authentication mechanism), but the ability to inject forged the 390 IKE_INTERMEDIATE exchange messages with valid ICV would allow the 391 attacker to mount Denial-of-Service attack. Moreover, if in this 392 situation the negotiated prf was not secure against preimage attack 393 with known key, then the attacker could forge the IKE_INTERMEDIATE 394 exchange messages without later being detected in the IKE_AUTH 395 exchange. To do this the attacker should find the same 396 IntAuth_*_[I|R] value for the forged message as for original. 398 6. IANA Considerations 400 This document defines a new Exchange Type in the "IKEv2 Exchange 401 Types" registry: 403 43 IKE_INTERMEDIATE 405 This document also defines a new Notify Message Type in the "Notify 406 Message Types - Status Types" registry: 408 16438 INTERMEDIATE_EXCHANGE_SUPPORTED 410 7. Acknowledgements 412 The idea to use an intermediate exchange between IKE_SA_INIT and 413 IKE_AUTH was first suggested by Tero Kivinen. Scott Fluhrer and 414 Daniel Van Geest identified a possible problem with authentication of 415 the IKE_INTERMEDIATE exchange and helped to resolve it. Author is 416 also grateful to Tobias Brunner for raising good points concerning 417 authentication of the IKE_INTERMEDIATE exchange. 419 8. References 421 8.1. Normative References 423 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 424 Requirement Levels", BCP 14, RFC 2119, 425 DOI 10.17487/RFC2119, March 1997, 426 . 428 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 429 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 430 May 2017, . 432 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 433 Kivinen, "Internet Key Exchange Protocol Version 2 434 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 435 2014, . 437 [RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 438 (IKEv2) Message Fragmentation", RFC 7383, 439 DOI 10.17487/RFC7383, November 2014, 440 . 442 8.2. Informative References 444 [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation 445 of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, 446 August 2017, . 448 [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange 449 Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, 450 DOI 10.17487/RFC5723, January 2010, 451 . 453 Author's Address 455 Valery Smyslov 456 ELVIS-PLUS 457 PO Box 81 458 Moscow (Zelenograd) 124460 459 RU 461 Phone: +7 495 276 0211 462 Email: svan@elvis.ru