idnits 2.17.1 draft-smyslov-ipsec-tcp-guidelines-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack 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 (September 7, 2018) is 2048 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 September 7, 2018 5 Expires: March 11, 2019 7 Clarifications and Implementation Guidelines for using TCP Encapsulation 8 in IKEv2 9 draft-smyslov-ipsec-tcp-guidelines-00 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 http://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 March 11, 2019. 38 Copyright Notice 40 Copyright (c) 2018 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 (http://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. Retransmissions . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. Using Cookies and Puzzles . . . . . . . . . . . . . . . . . . 4 59 5. Error Handling in the IKE_SA_INIT . . . . . . . . . . . . . . 5 60 6. Interaction with MOBIKE Protocol . . . . . . . . . . . . . . 5 61 7. Using TCP Encapsulation with High Availability Cluster . . . 6 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 63 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 65 9.2. Informative References . . . . . . . . . . . . . . . . . 7 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 68 1. Introduction 70 The Internet Key Exchange version 2 (IKEv2) as it is defined in 71 [RFC7296] uses UDP as a transport protocol. As time passed the 72 network environment has been evolved and sometimes this evolution has 73 resulted in situations when UDP messages are dropped by network 74 infrastructure. This may happen either by incapability of network 75 devices to properly handle them (e.g. non-initial fragments of UDP 76 messages) of by deliberate configuration of network devices that 77 blocks UDP traffic. 79 Several standard solutions have been developed to deal with such 80 situations. In particular, [RFC7383] defines a way to avoid IP 81 fragmentation of large IKE messages and [RFC8229] specifies a way to 82 transfer IKEv2 and ESP (Encapsulated Security Payload) messages over 83 a stream protocol like TCP. This document focuses on the latter 84 specification and its goal is to give implementers guidelines how to 85 properly use reliable connection-oriented stream transport in IKEv2. 87 Since originally IKEv2 relied on unreliable transport, it was 88 designed to deal with this unreliability. IKEv2 has its own 89 retransmission timers, replay detection logic etc. Using reliable 90 transport makes many of such things unnecessary. On the other hand, 91 connection-oriented transport require IKEv2 to keep the connection 92 alive and to restore it in case it is broken, the tasks that were not 93 needed before. [RFC8229] gives recommendations how peers must behave 94 in different situations to keep the connection. However, 95 implementation experience has revealed that not all situations are 96 covered in [RFC8229], that may lead to interoperability problems or 97 to suboptimal performance. This memo gives implementers more 98 guidelines how to use reliable stream tranport in IKEv2 in 99 situations, which are not covered in [RFC8229]. 101 2. Terminology and Notation 103 This document shares the terinology with [RFC8229]. In particular, 104 it uses terms "TCP Originator" and "TCP Responder" to refer to the 105 parties that initiate or responded to the TCP connection created for 106 the initial IKE SA (in a possible series of successive rekeys). More 107 details are given in Section 1.2 of [RFC8229]. 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 111 "OPTIONAL" in this document are to be interpreted as described in BCP 112 14 [RFC2119] [RFC8174] when, and only when, they appear in all 113 capitals, as shown here. 115 3. Retransmissions 117 Section 2.1 of [RFC7296] describes how IKEv2 deals with unreliability 118 of UDP protocol. In brief, exchange initiator is responsible for 119 retransmissions and must retransmit requests message until response 120 message is received. If no reply is received after several 121 retransmissions, the SA is deleted. The responder never retransmits 122 but must resend the response message in case it receives 123 retransmitted request. 125 When IKEv2 uses reliable transport protocol, most of these rules 126 become unnecessary. Since [RFC8229] doesn't provide clear guidance 127 on using retransmissions in case of TCP encapsulation, this memo 128 gives the following rules. 130 o the exchange initiator SHOULD NOT retransmit request message; if 131 no response is received within some reasonable period of time, the 132 IKE SA is deleted 134 o if TCP connection is broken and then restored while the exchange 135 initiator is waiting for the response, the initiator MUST 136 retrasmit the request and continue to fait for the response 138 o the exchange responder acts as described in Section 2.1 of 139 [RFC7296], i.e. using TCP encapsulation doesn't change the 140 responder's behavior 142 4. Using Cookies and Puzzles 144 IKEv2 provides a DoS attack protection mechanism called Cookie, which 145 is described in Section 2.6 of [RFC7296]. [RFC8019] extends this 146 mechanism for protection against DDoS attacks by means of Client 147 Puzzles. Both mechanisms allow the responder to keep no state until 148 the initiator proves its IP address is real (and solves puzzle in the 149 latter case). 151 [RFC8229] gives no guidance on how these mechanisms should be used in 152 case of TCP encapsulation. However, the connection-oriented nature 153 of TCP brings additional considerations for using these mechanisms. 154 In general, Cookie provides less value in case of TCP encapsulation, 155 because when the responder receives the IKE_SA_INIT request the TCP 156 session has already been established, so the initiator's IP address 157 has been verified. Moreover, TCP Responder creates state as far as 158 the SYN packer is received (unless SYN Cookies described in [RFC4987] 159 are employed), that distorts the stateless nature of IKEv2 Cookies. 160 So, it makes little sense to send Cookie request in this situation, 161 unless the responder in concerned with the possibility of TCP 162 Sequence Number attacks (see [RFC6528] for details). On the other 163 hand, Puzzles still remain useful and their use requires using 164 Cookies. 166 The following considerations are applicable for using Cookie and 167 Puzzle mechanisms in case of TCP encapsulation. 169 o the exchange responder SHOULD NOT request Cookie unless the 170 responder has good reason to do it (like a concern of the 171 possibility of TCP Sequence Number attacks or Puzzle request is 172 sent in the same message) 174 o if the responder chooses to send Cookie request (possibly along 175 with Puzzle request), then the TCP connection that the IKE_SA_INIT 176 request message was received over SHOULD be closed, so that the 177 responder remains stateless at least until the Cookie (or Puzzle 178 Solution) is returned 180 * note, that if this TCP connection is closed, then the responder 181 MUST NOT include the initiator's TCP port into the Cookie 182 calculation (*), since the Cookie will be returned over a new 183 TCP connection with a different port 185 o the exchange initiator acts as described in Section 2.6 of 186 [RFC7296] and Section 7 of [RFC8019], i.e. using TCP encapsulation 187 doesn't change the initiator's behavior 189 (*) Examples of Cookie calculation methods are given in Section 2.6 190 of [RFC7296] and in Section 7.1.1.3 of [RFC8019] and they don't 191 include transport protocol ports. However these examples are given 192 for illustrative purposes, since Cookie generation algorithm is a 193 local matter and some implementations might include port numbers, 194 that won't work with TCP encapsulation. 196 5. Error Handling in the IKE_SA_INIT 198 Section 2.21.1 of [RFC7296] describes how error notifications should 199 be handled in the IKE_SA_INIT exchange. In particular, it is advised 200 that the initiator should not act immediately after receiving error 201 notification and should instead wait some time for valid response, 202 since the IKE_SA_INIT messages are completely unauthenticated. This 203 advise has little sense in case of TCP encapsulation. If the 204 initiator receives the response message over TCP, then either this 205 message is genuine and was sent by the peer, or the TCP session was 206 hijacked and the message is forged, but in this case no genuine 207 messages from the responder will be received. 209 So, in case of TCP encapsulation the initiator SHOULD NOT wait for 210 additional messages in case it receives error notification from the 211 responder in the IKE_SA_INIT exchange. 213 6. Interaction with MOBIKE Protocol 215 [RFC4555] defines MOBIKE protocol, that allows IKEv2 SA to migrate 216 between IP addresses. Section 8 of [RFC8229] describes how 217 interaction between MOBIKE and TCP encapsulation. This memo provides 218 clarifications and additional recommendations for using MOBIKE in 219 case of TCP encapsulation. 221 [RFC8229] recommends, that in case of IP address change, the 222 initiator first try UDP initiate the INFORMATIONAL exchange 223 containing UPDATE_SA_ADDRESSES notification using UDP transport and 224 if no response is received then send this notification over TCP 225 transport. This recommendation lacks some details. 227 o when switching from UDP to TCP the Message ID of the exchange MUST 228 NOT be changed 230 o on the other hand, when switching from UDP to TCP the content of 231 the NAT_DETECTION_SOURCE_IP notification included in the request 232 MUST be recalculated (because TCP source port will most probably 233 be different from UDP source port) 235 Section 3.7 of [RFC4555] describes an additional optional step in the 236 process of changing IP addresses called Return Routability Check. It 237 is performed by the responder in order to be sure that the new 238 initiator's address is in fact routable. In case of TCP 239 encapsulation this check has little value, since TCP handshake proves 240 rotability of the TCP Originator's address. So, in case of TCP 241 encapsulation the Return Routability Check SHOULD NOT be performed. 243 7. Using TCP Encapsulation with High Availability Cluster 245 [RFC6311] defines a support for High Availability in IKEv2. The core 246 idea is that in case of cluster failover a new active node 247 immediately initiates the special INFORMATION exchange containing the 248 IKEV2_MESSAGE_ID_SYNC motification, which instructs the client to 249 skip some number of Message IDs that might not be synchronized yet 250 between nodes at the time of failover. 252 The problem is that TCP states are much harder to synchronize than 253 IKE states - it requires access to TCP/IP stack internals, which is 254 not always avaivable for IKE/IPsec implementations. If a cluster 255 implementation doesn't synchronize TCP states between nodes, then 256 after failover event the new active node will not have any TCP 257 connection with the client, so the node cannot initiate the 258 INFORMATIONAL exchange as required by [RFC6311]. Since the cluster 259 usually acts as TCP Responder, the new active node cannot re- 260 establish TCP connection, since only the TCP Originator can do it. 261 And for the client the situation of cluster failover may remain 262 unknown for long time if it has no IKE or ESP traffic to send. Once 263 the client sends any ESP or IKEv2 packet, the cluster node will reply 264 with TCP RST and the client (as TCP Originator) will restore the TCP 265 connection so that the node will be able to initiate the 266 INFORMATIONAL exchange informing the client about the cluster 267 failover. 269 This memo makes the following recommendation: if support for High 270 Availability in IKEv2 is negotiated and TCP transport is used and a 271 client is TCP Originator, then the client SHOULD periodically send 272 IKEv2 messages (e.g. by initiating liveness check exchange) whenever 273 there is no any IKEv2 or ESP traffic. This differs from the 274 recommendations given in Section 2.4 of [RFC7296] in the following: 275 the liveness check should be periodically performed even if the 276 client has nothing to send over ESP. The frequency of sending such 277 messages should be high enough to allow quick detection and restoring 278 of broken TCP connection. 280 8. Security Considerations 282 Security considerations concerning using TCP encapsulation in IKEv2 283 and ESP are given in [RFC6311]. This memo doesn't provide additional 284 security considerations. 286 9. References 288 9.1. Normative References 290 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 291 Requirement Levels", BCP 14, RFC 2119, 292 DOI 10.17487/RFC2119, March 1997, . 295 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 296 (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, 297 . 299 [RFC6311] Singh, R., Ed., Kalyani, G., Nir, Y., Sheffer, Y., and D. 300 Zhang, "Protocol Support for High Availability of IKEv2/ 301 IPsec", RFC 6311, DOI 10.17487/RFC6311, July 2011, 302 . 304 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 305 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 306 May 2017, . 308 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 309 Kivinen, "Internet Key Exchange Protocol Version 2 310 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 311 2014, . 313 [RFC8019] Nir, Y. and V. Smyslov, "Protecting Internet Key Exchange 314 Protocol Version 2 (IKEv2) Implementations from 315 Distributed Denial-of-Service Attacks", RFC 8019, 316 DOI 10.17487/RFC8019, November 2016, . 319 [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation 320 of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, 321 August 2017, . 323 9.2. Informative References 325 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 326 Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, 327 . 329 [RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence 330 Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February 331 2012, . 333 [RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 334 (IKEv2) Message Fragmentation", RFC 7383, 335 DOI 10.17487/RFC7383, November 2014, . 338 Author's Address 340 Valery Smyslov 341 ELVIS-PLUS 342 PO Box 81 343 Moscow (Zelenograd) 124460 344 RU 346 Phone: +7 495 276 0211 347 Email: svan@elvis.ru