idnits 2.17.1 draft-smyslov-ipsecme-tcp-guidelines-03.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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([RFC8229], [RFC7296]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 17, 2019) is 1586 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 8229 (Obsoleted by RFC 9329) -- Obsolete informational reference (is this intentional?): RFC 6528 (Obsoleted by RFC 9293) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 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: Informational December 17, 2019 5 Expires: June 19, 2020 7 Clarifications and Implementation Guidelines for using TCP Encapsulation 8 in IKEv2 9 draft-smyslov-ipsecme-tcp-guidelines-03 11 Abstract 13 The Internet Key Exchange Protocol version 2 (IKEv2) defined in 14 [RFC7296] uses UDP transport for its messages. [RFC8229] specifies a 15 way to encapsulate IKEv2 and ESP (Encapsulating Security Payload) 16 messages in TCP, thus making possible to use them in network 17 environments that block UDP traffic. However, some nuances of using 18 TCP in IKEv2 are not covered by that specification. This document 19 provides clarifications and implementation guidelines for [RFC8229]. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on June 19, 2020. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3 57 3. TCP Encapsulation Format . . . . . . . . . . . . . . . . . . 3 58 4. Falling back from UDP to TCP . . . . . . . . . . . . . . . . 4 59 5. Retransmissions . . . . . . . . . . . . . . . . . . . . . . . 4 60 6. Using Cookies and Puzzles . . . . . . . . . . . . . . . . . . 4 61 7. Error Handling in the IKE_SA_INIT . . . . . . . . . . . . . . 5 62 8. Interaction with IKEv2 Extensions . . . . . . . . . . . . . . 6 63 8.1. MOBIKE Protocol . . . . . . . . . . . . . . . . . . . . . 6 64 8.2. IKEv2 Redirect . . . . . . . . . . . . . . . . . . . . . 7 65 8.3. IKEv2 Session Resumption . . . . . . . . . . . . . . . . 7 66 8.4. IKEv2 Protocol Support for High Availability . . . . . . 7 67 9. TCP Encapsulation Influence on IPsec SAs . . . . . . . . . . 8 68 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 69 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 70 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 12.1. Normative References . . . . . . . . . . . . . . . . . . 9 72 12.2. Informative References . . . . . . . . . . . . . . . . . 10 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 75 1. Introduction 77 The Internet Key Exchange version 2 (IKEv2) as it is defined in 78 [RFC7296] uses UDP as a transport protocol. As time passed the 79 network environment has been evolved and sometimes this evolution has 80 resulted in situations when UDP messages are dropped by network 81 infrastructure. This may happen either by incapability of network 82 devices to properly handle them (e.g. non-initial fragments of UDP 83 messages) of by deliberate configuration of network devices that 84 blocks UDP traffic. 86 Several standard solutions have been developed to deal with such 87 situations. In particular, [RFC7383] defines a way to avoid IP 88 fragmentation of large IKE messages and [RFC8229] specifies a way to 89 transfer IKEv2 and ESP (Encapsulated Security Payload) messages over 90 a stream protocol like TCP. This document focuses on the latter 91 specification and its goal is to give implementers guidelines how to 92 properly use reliable connection-oriented stream transport in IKEv2. 94 Since originally IKEv2 relied on unreliable transport, it was 95 designed to deal with this unreliability. IKEv2 has its own 96 retransmission timers, replay detection logic etc. Using reliable 97 transport makes many of such things unnecessary. On the other hand, 98 connection-oriented transport require IKEv2 to keep the connection 99 alive and to restore it in case it is broken, the tasks that were not 100 needed before. [RFC8229] gives recommendations how peers must behave 101 in different situations to keep the connection. However, 102 implementation experience has revealed that not all situations are 103 covered in [RFC8229], that may lead to interoperability problems or 104 to suboptimal performance. This memo gives implementers more 105 guidelines how to use reliable stream transport in IKEv2 in 106 situations, which are not covered in [RFC8229]. 108 2. Terminology and Notation 110 This document shares the terminology with [RFC8229]. In particular, 111 it uses terms "TCP Originator" and "TCP Responder" to refer to the 112 parties that initiate or responded to the TCP connection created for 113 the initial IKE SA (in a possible series of successive rekeys). More 114 details are given in Section 1.2 of [RFC8229]. 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 118 "OPTIONAL" in this document are to be interpreted as described in BCP 119 14 [RFC2119] [RFC8174] when, and only when, they appear in all 120 capitals, as shown here. 122 3. TCP Encapsulation Format 124 Section 3 of [RFC8229] describes how IKE and ESP packets are 125 encapsulated in TCP stream. For this purpose every IKE or ESP packet 126 is prepended with 16-bit Length field. However, the text in the 127 first para of the section is not very explicit on what the Length 128 field means - whether it indicates only the length of the following 129 IKE or ESP message or the length of field itself is also counted. 130 The following text in the same section clarifies it - the value of 131 the Length field includes the length of the field itself (2 octets). 132 It means that values 0 and 1 must never appear there. The receiver 133 MUST treat these values in the Length field as fatal error and MUST 134 close TCP session in this case. 136 Note, that since TCP header is longer than UDP header, and TCP 137 encapsulation also requires prepending of 16-bit Length field, some 138 very long ESP and IKE messages that could be sent over UDP cannot be 139 encapsulated in TCP, because their total length after encapsulation 140 would exceed 65535 and thus could not be represented in Length field. 142 4. Falling back from UDP to TCP 144 Section 5.1 of [RFC8229] describes how the fallback from UDP to TCP 145 must be handled. It is recommended, that in the absence of prior 146 knowledge, implementations first try to use UDP and then fall back 147 TCP if no reply is received within some period of time after several 148 retransmissions. In this case a new IKE_SA_INIT exchange MUST be 149 initiated with new initiator's SPI and with recalculated content of 150 NAT_DETECTION_SOURCE_IP notification. 152 5. Retransmissions 154 Section 2.1 of [RFC7296] describes how IKEv2 deals with unreliability 155 of UDP protocol. In brief, exchange initiator is responsible for 156 retransmissions and must retransmit requests message until response 157 message is received. If no reply is received after several 158 retransmissions, the SA is deleted. The responder never retransmits 159 but must resend the response message in case it receives 160 retransmitted request. 162 When IKEv2 uses reliable transport protocol, most of these rules 163 become unnecessary. Since [RFC8229] doesn't provide clear guidance 164 on using retransmissions in case of TCP encapsulation, this memo 165 gives the following rules. 167 o the exchange initiator SHOULD NOT retransmit request message; if 168 no response is received within some reasonable period of time, the 169 IKE SA is deleted 171 o if TCP connection is broken and then restored while the exchange 172 initiator is waiting for the response, the initiator MUST 173 retransmit the request and continue to wait for the response 175 o the exchange responder acts as described in Section 2.1 of 176 [RFC7296], i.e. using TCP encapsulation doesn't change the 177 responder's behavior 179 6. Using Cookies and Puzzles 181 IKEv2 provides a DoS attack protection mechanism called Cookie, which 182 is described in Section 2.6 of [RFC7296]. [RFC8019] extends this 183 mechanism for protection against DDoS attacks by means of Client 184 Puzzles. Both mechanisms allow the responder to keep no state until 185 the initiator proves its IP address is real (and solves puzzle in the 186 latter case). 188 [RFC8229] gives no guidance on how these mechanisms should be used in 189 case of TCP encapsulation. However, the connection-oriented nature 190 of TCP brings additional considerations for using these mechanisms. 191 In general, Cookie provides less value in case of TCP encapsulation, 192 because when the responder receives the IKE_SA_INIT request the TCP 193 session has already been established, so the initiator's IP address 194 has been verified. Moreover, TCP Responder creates state as far as 195 the SYN packer is received (unless SYN Cookies described in [RFC4987] 196 are employed), that violates the stateless nature of IKEv2 Cookies. 197 So, it makes little sense to send Cookie request in this situation, 198 unless the responder in concerned with the possibility of TCP 199 Sequence Number attacks (see [RFC6528] for details). On the other 200 hand, Puzzles still remain useful and their use requires using 201 Cookies. 203 The following considerations are applicable for using Cookie and 204 Puzzle mechanisms in case of TCP encapsulation. 206 o the exchange responder SHOULD NOT request Cookie unless the 207 responder has good reason to do it (like a concern of the 208 possibility of TCP Sequence Number attacks or Puzzle request is 209 sent in the same message) 211 o if the responder chooses to send Cookie request (possibly along 212 with Puzzle request), then the TCP connection that the IKE_SA_INIT 213 request message was received over SHOULD be closed, so that the 214 responder remains stateless at least until the Cookie (or Puzzle 215 Solution) is returned 217 * note, that if this TCP connection is closed, then the responder 218 MUST NOT include the initiator's TCP port into the Cookie 219 calculation (*), since the Cookie will be returned over a new 220 TCP connection with a different port 222 o the exchange initiator acts as described in Section 2.6 of 223 [RFC7296] and Section 7 of [RFC8019], i.e. using TCP encapsulation 224 doesn't change the initiator's behavior 226 (*) Examples of Cookie calculation methods are given in Section 2.6 227 of [RFC7296] and in Section 7.1.1.3 of [RFC8019] and they don't 228 include transport protocol ports. However these examples are given 229 for illustrative purposes, since Cookie generation algorithm is a 230 local matter and some implementations might include port numbers, 231 that won't work with TCP encapsulation. 233 7. Error Handling in the IKE_SA_INIT 235 Section 2.21.1 of [RFC7296] describes how error notifications should 236 be handled in the IKE_SA_INIT exchange. In particular, it is advised 237 that the initiator should not act immediately after receiving error 238 notification and should instead wait some time for valid response, 239 since the IKE_SA_INIT messages are completely unauthenticated. This 240 advice has little sense in case of TCP encapsulation. If the 241 initiator receives the response message over TCP, then either this 242 message is genuine and was sent by the peer, or the TCP session was 243 hijacked and the message is forged, but in this case no genuine 244 messages from the responder will be received. 246 So, in case of TCP encapsulation the initiator SHOULD NOT wait for 247 additional messages in case it receives error notification from the 248 responder in the IKE_SA_INIT exchange. 250 8. Interaction with IKEv2 Extensions 252 8.1. MOBIKE Protocol 254 MOBIKE protocol, that allows IKEv2 SA to migrate between IP 255 addresses, is defined in [RFC4555], and [RFC4621] further clarifies 256 the details of the protocol. Section 8 of [RFC8229] describes how 257 interaction between MOBIKE and TCP encapsulation. This memo provides 258 clarifications and additional recommendations for using MOBIKE in 259 case of TCP encapsulation. 261 [RFC8229] recommends, that in case of IP address change, the 262 initiator first initiates the INFORMATIONAL exchange containing 263 UPDATE_SA_ADDRESSES notification using UDP transport and if no 264 response is received then send this notification over TCP transport. 265 However, this recommendation lacks some details. In particular, it 266 is not clear whether falling back from UDP to TCP requires initiating 267 a new INFORMATIONAL exchange or not. 269 From MOBIKE point of view UDP and TCP transports can be seen as two 270 different network attachments, so falling back from the former to the 271 latter is very similar to changing peer's IP address. For that 272 reason, the initiator first initiates the INFORMATIONAL exchange over 273 UDP, and if no response is received within some period of time after 274 several retransmissions, then the initiator changes transport from 275 UDP to TCP in this very exchange. New INFORMATIONAL exchange MUST 276 NOT be started in this situation. 278 It means that after switching to TCP the content of the 279 NAT_DETECTION_SOURCE_IP notification will in most cases be incorrect 280 (since UDP and TCP source ports will most probably be different), and 281 the peer will falsely think that there is a NAT in between. This 282 should not cause problems because in this case all traffic will be 283 encapsulated in TCP anyway, and TCP encapsulation is the same with 284 regardless of NAT presence. 286 MOBIKE protocol defined the NO_NATS_ALLOWED notification that can be 287 used to detect the presence of NAT between peer and to refuse to 288 communicate in this situation. In case of TCP the NO_NATS_ALLOWED 289 notification SHOULD be ignored because TCP generally has no problems 290 with NAT boxes. 292 Section 3.7 of [RFC4555] describes an additional optional step in the 293 process of changing IP addresses called Return Routability Check. It 294 is performed by the responder in order to be sure that the new 295 initiator's address is in fact routable. In case of TCP 296 encapsulation this check has little value, since TCP handshake proves 297 routability of the TCP Originator's address. So, in case of TCP 298 encapsulation the Return Routability Check SHOULD NOT be performed. 300 8.2. IKEv2 Redirect 302 Redirect mechanism for IKEv2 is defined in [RFC5685]. This mechanism 303 allows security gateways to redirect clients to another gateway 304 either during IKE SA establishment or after it is set up. If a 305 client is connecting to a security gateway using TCP transport and 306 then is being redirected to another security gateway, then the client 307 must disregard the current transport. In other words, the client 308 MUST again first try UDP and then fall back to TCP while establishing 309 a new IKE SA, regardless of the transport of the SA the redirect 310 notification was received over (unless the client's configuration 311 instructs it to instantly use TCP for the gateway it is redirected 312 to). 314 8.3. IKEv2 Session Resumption 316 Session resumption for IKEv2 is defined in [RFC5723]. Once IKE SA is 317 established the server creates a resumption ticket where information 318 about this SA is stored, and transfers this ticket to the client. 319 The ticket may be later used to resume the IKE SA if it is deleted. 320 In the event of resumption the client presents the ticket in a new 321 exchange, called IKE_SESSION_RESUME. For the new SA some parameters 322 are taken from the ticket and some are re-negotiated (more details 323 are given in Section 5 of [RFC5723]). If TCP encapsulation was used 324 in an old SA, then the client SHOULD resume this SA using TCP, 325 without first trying to connect over UDP. 327 8.4. IKEv2 Protocol Support for High Availability 329 [RFC6311] defines a support for High Availability in IKEv2. The core 330 idea is that in case of cluster failover a new active node 331 immediately initiates the special INFORMATION exchange containing the 332 IKEV2_MESSAGE_ID_SYNC notification, which instructs the client to 333 skip some number of Message IDs that might not be synchronized yet 334 between nodes at the time of failover. 336 The problem is that TCP states are much harder to synchronize than 337 IKE states - it requires access to TCP/IP stack internals, which is 338 not always available for IKE/IPsec implementations. If a cluster 339 implementation doesn't synchronize TCP states between nodes, then 340 after failover event the new active node will not have any TCP 341 connection with the client, so the node cannot initiate the 342 INFORMATIONAL exchange as required by [RFC6311]. Since the cluster 343 usually acts as TCP Responder, the new active node cannot re- 344 establish TCP connection, since only the TCP Originator can do it. 345 And for the client the situation of cluster failover may remain 346 unknown for long time if it has no IKE or ESP traffic to send. Once 347 the client sends any ESP or IKEv2 packet, the cluster node will reply 348 with TCP RST and the client (as TCP Originator) will restore the TCP 349 connection so that the node will be able to initiate the 350 INFORMATIONAL exchange informing the client about the cluster 351 failover. 353 This memo makes the following recommendation: if support for High 354 Availability in IKEv2 is negotiated and TCP transport is used and a 355 client is TCP Originator, then the client SHOULD periodically send 356 IKEv2 messages (e.g. by initiating liveness check exchange) whenever 357 there is no any IKEv2 or ESP traffic. This differs from the 358 recommendations given in Section 2.4 of [RFC7296] in the following: 359 the liveness check should be periodically performed even if the 360 client has nothing to send over ESP. The frequency of sending such 361 messages should be high enough to allow quick detection and restoring 362 of broken TCP connection. 364 9. TCP Encapsulation Influence on IPsec SAs 366 Using TCP encapsulation makes impossible to use some features of 367 IPsec SA processing. In particular, there are two features that are 368 affected. 370 First, Section 8.1 of [RFC4301] requires all tunnel mode IPsec SAs to 371 be able to copy the Don't Fragment (DF) bit from inner IP header to 372 the outer (tunnel) one. With TCP encapsulation it's generally 373 impossible, because TCP/IP stack manages DF bit in the outer IP 374 header, and usually the stack ensures that the DF bit is set for TCP 375 packets to avoid IP fragmentation. 377 The other feature that is degraded with TCP encapsulation is an 378 ability to split traffic of different QoS classes into different 379 IPsec SAs, created by a single IKE SA. In this case the 380 Differentiated Services Code Point (DSCP) field is usually copied 381 from the inner IP header to the outer (tunnel) one, ensuring that 382 IPsec traffic of each SA receives the corresponding level of service. 383 With TCP encapsulation all IPsec SAs created by a single IKE SA will 384 share a single TCP connection and thus will receive the same level of 385 service. If this functionality is needed, implementations should 386 create several IKE SAs over TCP and assign a corresponding DSCP value 387 to each of them. 389 10. Security Considerations 391 Security considerations concerning using TCP encapsulation in IKEv2 392 and ESP are given in [RFC8229]. This memo doesn't provide additional 393 security considerations. 395 11. Acknowledgements 397 Author would like to thank Tommy Pauly and Tero Kivinen for their 398 valuable comments. 400 12. References 402 12.1. Normative References 404 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 405 Requirement Levels", BCP 14, RFC 2119, 406 DOI 10.17487/RFC2119, March 1997, 407 . 409 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 410 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 411 December 2005, . 413 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 414 (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, 415 . 417 [RFC5685] Devarapalli, V. and K. Weniger, "Redirect Mechanism for 418 the Internet Key Exchange Protocol Version 2 (IKEv2)", 419 RFC 5685, DOI 10.17487/RFC5685, November 2009, 420 . 422 [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange 423 Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, 424 DOI 10.17487/RFC5723, January 2010, 425 . 427 [RFC6311] Singh, R., Ed., Kalyani, G., Nir, Y., Sheffer, Y., and D. 428 Zhang, "Protocol Support for High Availability of IKEv2/ 429 IPsec", RFC 6311, DOI 10.17487/RFC6311, July 2011, 430 . 432 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 433 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 434 May 2017, . 436 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 437 Kivinen, "Internet Key Exchange Protocol Version 2 438 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 439 2014, . 441 [RFC8019] Nir, Y. and V. Smyslov, "Protecting Internet Key Exchange 442 Protocol Version 2 (IKEv2) Implementations from 443 Distributed Denial-of-Service Attacks", RFC 8019, 444 DOI 10.17487/RFC8019, November 2016, 445 . 447 [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation 448 of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, 449 August 2017, . 451 12.2. Informative References 453 [RFC4621] Kivinen, T. and H. Tschofenig, "Design of the IKEv2 454 Mobility and Multihoming (MOBIKE) Protocol", RFC 4621, 455 DOI 10.17487/RFC4621, August 2006, 456 . 458 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 459 Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, 460 . 462 [RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence 463 Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February 464 2012, . 466 [RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 467 (IKEv2) Message Fragmentation", RFC 7383, 468 DOI 10.17487/RFC7383, November 2014, 469 . 471 Author's Address 473 Valery Smyslov 474 ELVIS-PLUS 475 PO Box 81 476 Moscow (Zelenograd) 124460 477 RU 479 Phone: +7 495 276 0211 480 Email: svan@elvis.ru