idnits 2.17.1 draft-ietf-ipsecme-ike-tcp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 4, 2012) is 4160 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) == Outdated reference: A later version (-10) exists of draft-ietf-behave-lsn-requirements-09 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Nir 3 Internet-Draft Check Point 4 Intended status: Standards Track December 4, 2012 5 Expires: June 7, 2013 7 A TCP transport for the Internet Key Exchange 8 draft-ietf-ipsecme-ike-tcp-01 10 Abstract 12 This document describes using TCP for IKE messages. This facilitates 13 the transport of large messages over paths where fragments are either 14 dropped, or where packet loss makes the use of large UDP packets 15 unreliable. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on June 7, 2013. 34 Copyright Notice 36 Copyright (c) 2012 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 1. Introduction 51 The Internet Key Exchange version 2 (IKEv2), specified in [RFC5996] 52 uses UDP to transport the exchange messages. Some of those messages 53 may be fairly large. Specifically, the messages of the IKE_AUTH 54 exchange can become quite large, as they may contain a chain of 55 certificates, an "Auth" payload (that may contain a public key 56 signature), CRLs, and some configuration information that is carried 57 in the CFG payload. 59 When such UDP packets exceed the path MTU, they get fragmented. This 60 increases the probability of packets being dropped. The 61 retransmission mechanisms in IKE (as described in section 2.1 of RFC 62 5996) takes care of that as long as packet loss is at a reasonable 63 level. More recently we have seen a number of service providers 64 dropping fragmented packets. Firewalls and NAT devices need to keep 65 state for each packet where some (but not all) of the fragments have 66 passed through. This creates a burden in terms of memory, especially 67 for high capacity devices such as Carrier-Grade NAT (CGN) or high 68 capacity firewalls. 70 The BEHAVE working group has an Internet Draft describing required 71 behavior of CGNs ([I-D.ietf-behave-lsn-requirements]). It requires 72 CGNs to comply with [RFC4787], which in section 11 requires NAT 73 devices to support fragments. However, some people deploying IKE 74 have found that some ISPs have begun to drop fragments in preparation 75 for deploying CGNs. While we all hope for a future where all devices 76 comply with the emerging standards, or even a future where CGNs are 77 not required, we have to make IKE work today. 79 The solution described in this document is to transport the IKE 80 messages over a TCP ([RFC0793]) connection rather than over UDP. IKE 81 packets describe their own length, so they are well-suited for 82 transport over a stream-based connection such as TCP. The Initiator 83 opens a TCP connection to the Responder's port 500, sends the 84 requests and receives the responses, and then closes the connection. 85 TCP can handle arbitrary-length messages, works well with any sized 86 data, and is well supported by all ISP infrastructure. 88 1.1. Non-Goals of this Specification 90 Firewall traversal is not a goal of this specification. If a 91 firewall has a policy to block IKE and/or IPsec, hiding the IKE 92 exchange in TCP is not expected to help. Some implementations hide 93 both IKE and IPsec in a TCP connection, usually pretending to be 94 HTTPS by using port 443. This has a significant impact on bandwidth 95 and gateway capacity, and even this is defeated by better firewalls. 96 SSL VPNs tunnel IP packets over TLS, but the latest firewalls are 97 also TLS proxies, and are able to defeat this as well. 99 This document is not part of that arms race. It is only meant to 100 allow IKE to work When faced with broken infrastructure that drops 101 large IP packets. 103 1.2. Conventions Used in This Document 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119]. 109 2. The Protocol 111 2.1. Initiator 113 An Initiator MAY try IKE using TCP for any request. It opens a TCP 114 connection from an arbitrary port to port 500 of the Responder. When 115 the three-way handshake completes, the Initiator MUST send the 116 request. If the Initiator knows that this request is the last 117 request needed at this time, it MAY half-close the TCP connection, or 118 it MAY wait until the last response has been received. When all 119 responses have been received, the Initiator MUST close the 120 connection. If the peer has closed the connection before all 121 requests have been transmitted or responded to, the Initiator SHOULD 122 either open a new TCP connection or transmit them over UDP again. 124 An initiator MUST accept responses sent over IKE within the same 125 connection, but MUST also accept responses over other transports, if 126 the request had been sent over them as well. 128 An initiator that is configured to respond to IKE over TCP on some 129 port, and is not prevented from receiving TCP connections by network 130 address translation (see Section 3.2), MUST send an IKE_TCP_SUPPORTED 131 notification (Section 2.5) in the Initial request. 133 Note that stateless cookies may be dependent on some of the 134 parameters of the connection, so retransmitting the IKE_INITIAL 135 request with a stateless cookie over a different transport may cause 136 the cookie to be invalid. For this reason, retransmissions with a 137 cookie SHOULD be sent over the same transport. 139 2.2. Responder 141 A Responder MAY accept TCP connections to port 500, and if it does, 142 it MUST accept IKE requests over this connection. Responses to 143 requests received over this connection MUST also go over this 144 connection. If the connection has closed before the Responder has 145 had a chance to respond, it MUST NOT respond over UDP, but MUST 146 instead wait for a retransmission over UDP or over another TCP 147 connection. 149 The responder MUST accept different requests on different transports. 150 Specifically, the Responder MUST NOT rely on subsequent requests 151 coming over the same transport. For example, it is entirely 152 acceptable to have the IKE_INITIAL exchange come over UDP port 500, 153 while the IKE_AUTH request comes over TCP, and some following 154 requests might come over UDP port 4500 (because NAT has been 155 detected). 157 A responder that is configured to support IKE over TCP and receives 158 an IKEv2 Initial request over any other transport MUST send an 159 IKE_TCP_SUPPORTED notification (Section 2.5) in the Initial response. 160 the responder MAY send this notification even if the Initial request 161 was received over TCP. 163 If the responder has some requests of its own to send, it MUST NOT 164 use a connection that has been opened by a peer. Instead, it MUST 165 either use UDP or else open a new TCP connection to the original 166 Initiator's TCP port, specified in the IKE_TCP_SUPPORTED notification 167 in the Initial request. If the Initial request did not include this 168 notification, the original Responder MUST NOT initiate IKE over TCP 169 to the original Initiator. 171 The normal flow of things is that the Initiator opens a connection 172 and closes its side first. The responder closes after sending the 173 last response where the initiator has already half-closed the 174 connection. If, however, a significant amount of time has passed, 175 and neither new requests arrive nor the connection is closed by the 176 initiator, the Responder MAY close or even reset the connection. 178 This specification makes no recommendation as to how long such a 179 timeout should be, but a few seconds should be enough. 181 The stateless cookie mechanism in IKEv2 only assures that the 182 initiator is able to respond to the address and port of the request. 183 TCP already provides this with the three-way handshake. If the 184 IKE_INITIAL exchange is transmitted over TCP, the stateless cookie 185 mechanism SHOULD NOT be used. 187 2.3. Transmitter 189 The transmitter, whether an initiator transmitting a request or a 190 responder transmitting a response MUST NOT retransmit over the same 191 connection. TCP takes care of that. It SHOULD send the IKE header 192 and the IKE payloads with a single command or in rapid succession, 193 because the receiver might block on reading from the socket. 195 2.4. Receiver 197 The IKE header is copied from RFC 5996 below for reference: 199 1 2 3 200 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 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | IKE SA Initiator's SPI | 203 | | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | IKE SA Responder's SPI | 206 | | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | Next Payload | MjVer | MnVer | Exchange Type | Flags | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Message ID | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | Length | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 Figure 1: IKE Header Format 217 The receiver MUST first read in the 28 bytes that make up the IKE 218 header. The Responder then subtracts 28 from the length field, and 219 reads the resulting number of bytes. The combined message, comprised 220 on 28 header bytes and whatever number of payload bytes is processed 221 the same way as regular UDP messages. That includes retransmission 222 detection, with one slight difference: if a retransmitted request is 223 detected, the response is retransmitted as well, but using the 224 current TCP connection rather than whatever other transport had been 225 used for the original transmission of the request. 227 2.5. IKE_TCP_SUPPORTED Notification 229 This notification is sent by a responder over non-TCP transports to 230 inform the initiator that this specification is supported and 231 configured. 233 The Notify payload is formatted as follows: 235 1 2 3 236 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 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 ! Next Payload !C! RESERVED ! Payload Length ! 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 ! Protocol ID ! SPI Size !IKE_TCP_SUPPORTED Message Type ! 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | TCP Port | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 o Protocol ID (1 octet) MUST be 0. 246 o SPI Size (1 octet) MUST be zero, in conformance with section 3.10 247 of RFC 5996. 248 o IKE_TCP_SUPPORTED Notify Message Type (2 octets) - MUST be xxxxx, 249 the value assigned for IKE_TCP_SUPPORTED. TBA by IANA. 250 o TCP port (2 octets) - The TCP port to which the recipient should 251 open TCP connections. This is not necessarily the same port that 252 the IKE gateway is listening to. See Section 3.2. If the sender 253 is not subject to network address translation, the port SHOULD be 254 500. 256 3. Operational Considerations 258 Most IKE messages are relatively short. All but the IKE_AUTH 259 exchange in IKEv2 are comprised of short messages that fit in a 260 single packet on most networks. The Informational exchange could be 261 an exception, as it may contain arbitrary-length CFG payloads, but in 262 practice this is not done. It is only the IKE_AUTH exchange that has 263 long messages. UDP has advantages in lower latency and lower 264 resource consumption, so it makes sense to use UDP whenever TCP is 265 not required. 267 The requirements in Section 2.2 were written so that different 268 requests may be sent over different transports. The initiator can 269 choose the transport on a per-request basis. So one obvious policy 270 would be to do everything over UDP except the specific requests that 271 tend to become too big. This way the first messages use UDP, and the 272 Initiator can set up the TCP connection at the same time, eliminating 273 the latency penalty of using TCP. This may not always be the most 274 efficient policy, though. It means that the first messages sent over 275 TCP are relatively large ones, and TCP slow start may cause an extra 276 roundtrip, because the message has exceeded the transmission window. 277 An initiator using this policy MUST NOT go to TCP if the responder 278 has not indicated support by sending the IKE_TCP_SUPPORTED 279 notification (Section 2.5) in the Initial response. 281 An alternative method, that is probably easier for the Initiator to 282 implement, is to do an entire "mission" using the same transport. So 283 if TCP is needed for long messages and an IKE SA has not yet been 284 created, the Initiator will open a TCP connection, and perform all 285 2-4 requests needed to set up a child SA over the same connection. 287 Yet another policy would be to begin by using UDP, and at the same 288 time set up the TCP connection. If at any point the TCP handshake 289 completes, the next requests go over that connection. This method 290 can be used to auto-discover support of TCP on the responder. This 291 is easier for the user than configuring which peers support TCP, but 292 has the potential of wasting resources, as TCP connections may finish 293 the three-way handshake just when IKE over UDP has finished. The 294 requirements from the responder ensure that all these policies will 295 work. 297 3.1. Liveness Check 299 The TCP connections described in this document are short-lived. We 300 do not expect them to stay for the lifetime of the SA, but to get 301 torn down by either side within seconds of the SA being set up. 302 Because of this, they are not well-suited for the transport of short 303 requests such as those for liveness check. 305 Although liveness checks MAY be sent over TCP, this is not 306 recommended. 308 On the other hand, see Section 3.2 for when liveness check should be 309 used. 311 3.2. Network Address Translation 313 If the IKE gateway is subject to network address translation (NAT), 314 TCP ports may be translated, so that one port on the NAT device gets 315 translated to some other port on the gateway. In this case, the 316 gateway MUST advertise the NAT device port in the IKE_TCP_SUPPORTED 317 notification. 319 In some cases, the NAT or some other box prevents incoming TCP 320 connections to the IKE peer behind it. In these cases, the IKE peer 321 MUST NOT advertise support using the IKE_TCP_SUPPORTED notification. 323 When IKE peers detect the presence of a NAT device during the IKE 324 exchange, they typically switch to working over UDP port 4500. 325 Sending the IKE_AUTH messages over this UDP port creates a port 326 mapping entry on the NAT device, and this mapping can then be used 327 for bidirectional traffic between the peers. When using IKE over 328 TCP, this mapping is not created, so traffic can only flow from the 329 initiator to the responder. To make a bidirectional mapping, it is 330 RECOMMENDED that when NAT is detected, initiators initiate a liveness 331 check using UDP 4500 to the responders immediately following the 332 successful IKE_AUTH exchange. 334 4. Security Considerations 336 Most of the security considerations for IKE over TCP are the same as 337 those for UDP as in RFC 5996. 339 For the Responder, listening to TCP port 500 involves all the risks 340 of maintaining any TCP server. Precautions against DoS attacks, such 341 as SYN cookies are RECOMMENDED. see [RFC4987] for details. 343 5. IANA Considerations 345 IANA is requested to assign a notify message type from the status 346 types range (16418-40959) of the "IKEv2 Notify Message Types" 347 registry with name "IKE_TCP_SUPPORTED" 349 No IANA action is required for the TCP port, as TCP port 500 is 350 already allocated to "ISAKMP". 352 6. References 354 6.1. Normative References 356 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 357 Requirement Levels", BCP 14, RFC 2119, March 1997. 359 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 360 "Internet Key Exchange Protocol Version 2 (IKEv2)", 361 RFC 5996, September 2010. 363 6.2. Informative References 365 [I-D.ietf-behave-lsn-requirements] 366 Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 367 and H. Ashida, "Common requirements for Carrier Grade NATs 368 (CGNs)", draft-ietf-behave-lsn-requirements-09 (work in 369 progress), August 2012. 371 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 372 RFC 793, September 1981. 374 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 375 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 376 RFC 4787, January 2007. 378 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 379 Mitigations", RFC 4987, August 2007. 381 Author's Address 383 Yoav Nir 384 Check Point Software Technologies Ltd. 385 5 Hasolelim st. 386 Tel Aviv 67897 387 Israel 389 Email: ynir@checkpoint.com