idnits 2.17.1 draft-nir-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 (July 16, 2012) is 4273 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 2407 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2408 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) == Outdated reference: A later version (-10) exists of draft-ietf-behave-lsn-requirements-08 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 3 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 Y. Nir 3 Internet-Draft Check Point 4 Intended status: Standards Track July 16, 2012 5 Expires: January 17, 2013 7 A TCP transport for the Internet Key Exchange 8 draft-nir-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 packet loss makes them unreliable. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on January 17, 2013. 33 Copyright Notice 35 Copyright (c) 2012 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 1. Introduction 50 The Internet Key Exchange (IKE) specified in [RFC2407] and [RFC2408], 51 and IKEv2 as specified in [RFC5996] uses UDP to transport the 52 exchange messages. Some of those messages may be fairly large. 53 Specifically, the 5th and 6th messages of IKEv1 Main Mode, the first 54 and second messages of IKEv1 Aggressive Mode, and the messages of 55 IKEv2 IKE_AUTH exchange can become quite large, as they may contain a 56 chain of certificates, a signature payload (called "Auth" in IKEv2), 57 CRLs, and in the case of IKEv2, some configuration information that 58 is carried in the CFG payload. 60 When such UDP packets exceed the path MTU, they get fragmented. This 61 increases the probability of packets getting dropped, but the 62 retransmission mechanisms in IKE (as described in section 2.1 of RFC 63 5996) takes care of that. More recently we have seen a number of 64 service providers dropping fragmented packets. Firewalls and NAT 65 devices need to keep state for each packet where some but not all of 66 the fragments have been received. This creates a burden in terms of 67 memory, especially for high capacity devices such as Carrier-Grade 68 NAT (CGN) or high 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]) rather than over UDP. IKE packets 81 (both versions) describe their own length, so they are well-suited 82 for transport over a stream-based connection such as TCP. The 83 Initiator opens a TCP connection to the Responder's port 500, sends 84 the requests and receives the responses, and then closes the 85 connection. TCP can handle arbitrary-length messages, works well 86 with any sized 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. 97 SSL VPNs tunnel IP packets over TLS, but the latest firewalls are 98 also TLS proxies, and are able to defeat this as well. 100 This document is not part of that arms race. It is only meant to 101 allow IKE to work When faced with broken infrastructure that drops 102 large IP packets. 104 1.2. Conventions Used in This Document 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 2. The Protocol 112 2.1. Initiator 114 An Initiator MAY try IKE using TCP for any request. It opens a TCP 115 connection from an arbitrary port to port 500 of the Responder. When 116 the three-way handshake completes, the Initiator MUST send the 117 request. If the Initiator knows that this request is the last 118 request needed at this time, it SHOULD half-close the TCP connection, 119 although it MAY wait until the last response is received. When all 120 responses have been received, the Initiator MUST close the 121 connection. If the peer has closed the connection before all 122 requests have been transmitted or responded to, the Initiator SHOULD 123 either open a new TCP connection or transmit them over UDP again. 125 It MUST accept responses sent over IKE within the same connection, 126 but MUST also accept responses over other transports, if the request 127 had been sent over them as well. 129 2.2. Responder 131 A Responder MAY accept TCP connections to port 500, and if it does, 132 it MUST accept IKE requests over this connection. Responses to 133 requests received over this connection MUST also go over this 134 connection. If the connection has closed before the Responder had 135 had a chance to respond, it MUST NOT respond over UDP, but MUST 136 instead wait for a retransmission over UDP or over another TCP 137 connection. 139 The responder MUST accept different requests on different transports. 140 Specifically, the Responder MUST NOT rely on subsequent requests 141 coming over the same transport. For example, it is entirely 142 acceptable to have the first two requests on IKE Main Mode come over 143 UDP port 500, while the last request comes over TCP, and the 144 following Quick Mode request might come over UDP port 4500 (because 145 NAT has been detected). 147 A responder that receives an IKEv2 Initial request over any other 148 transport MUST send an IKE_TCP_SUPPORTED notification (Section 2.5) 149 in the Initial response. the responder MAY send this notification 150 even if the Initial request was received over TCP. 152 If the responder has some requests of its own to send, it MUST NOT 153 use a connection that has been opened by a peer. Instead, it MUST 154 either use UDP or else open a new TCP connection to the original 155 Initiator's TCP port 500. 157 The normal flow of things is that the Initiator opens a connection 158 and closes its side first. The responder closes after sending the 159 last response where the initiator has already half-closed the 160 connection. If, however, a significant amount of time has passed, 161 and neither new requests arrive nor the connection is closed by the 162 initiator, the Responder MAY close or even reset the connection. 164 This specification makes no recommendation as to how long such a 165 timeout should be, but a few seconds should be enough. 167 2.3. Transmitter 169 The transmitter, whether an initiator transmitting a request or a 170 responder transmitting a response MUST NOT retransmit over the same 171 connection. TCP takes care of that. It SHOULD send the IKE header 172 and the IKE payloads with a single command or in rapid succession, 173 because the receiver might block on reading from the socket. 175 2.4. Receiver 177 The IKE header is copied from RFC 5996 below for reference: 179 1 2 3 180 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 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | IKE SA Initiator's SPI | 183 | | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | IKE SA Responder's SPI | 186 | | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Next Payload | MjVer | MnVer | Exchange Type | Flags | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Message ID | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | Length | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 Figure 1: IKE Header Format 197 The receiver MUST first read in the 28 bytes that make up the IKE 198 header. The Responder then subtracts 28 from the length field, and 199 reads the resulting number of bytes. The combined message, comprised 200 on 28 header bytes and whatever number of payload bytes is processed 201 the same way as regular UDP messages. That includes retransmission 202 detection, with one slight difference: if a retransmitted request is 203 detected, the response is retransmitted as well, but using the 204 current TCP connection rather than whatever other transport had been 205 used for the original transmission of the request. 207 2.5. IKE_TCP_SUPPORTED Notification 209 This notification is sent by a responder over non-TCP transports to 210 inform the initiator that this specification is supported. 212 The Notify payload is formatted as follows: 214 1 2 3 215 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 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 ! Next Payload !C! RESERVED ! Payload Length ! 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 ! Protocol ID ! SPI Size !IKE_TCP_SUPPORTED Message Type ! 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 o Protocol ID (1 octet) MUST be 0. 223 o SPI Size (1 octet) MUST be zero, in conformance with section 3.10 224 of [RFC5996]. 226 o IKE_TCP_SUPPORTED Notify Message Type (2 octets) - MUST be xxxxx, 227 the value assigned for IKE_TCP_SUPPORTED. TBA by IANA. 229 3. Operational Considerations 231 Most IKE messages are relatively short. Quick Mode in IKEv1, and all 232 but the IKE_AUTH exchange in IKEv2 are comprised of short messages 233 that fit in a single packet on most networks. It is only the 234 IKE_AUTH exchange in IKEv2, and the two last messages of Main Mode 235 that are long. UDP has advantages in lower latency and lower 236 resource consumption, so it makes sense to use UDP whenever TCP is 237 not required. 239 The requirements in Section 2.2 mean that different requests may be 240 sent over different transports. So the initiator can choose the 241 transport on a per-request basis. So one obvious policy would be to 242 do everything over UDP except the specific requests that tend to 243 become too big. This way the first messages use UDP, and the 244 Initiator can set up the TCP connection at the same time, eliminating 245 the latency penalty of using TCP. This may not always be the most 246 efficient policy, though. It means that the first messages sent over 247 TCP are relatively large ones, and TCP slow start may cause an extra 248 roundtrip, because the message may exceed the transmission window. 249 An initiator using this policy MUST NOT go to TCP if the responder 250 has not indicated support by sending the IKE_TCP_SUPPORTED 251 notification (Section 2.5) in the Initial response. 253 An alternative method, that is probably easier for the Initiator to 254 implement, is to do an entire "mission" using the same transport. So 255 if TCP is needed and an IKE SA has not yet been created, the 256 Initiator will open a TCP connection, and perform all 2-4 requests 257 needed to set up a child SA over the same connection. 259 Yet another policy would be to begin by using UDP, and at the same 260 time set up the TCP connection. If at any point the TCP handshake 261 completes, the next requests go over that connection. This method 262 can be used to auto-discover support of TCP on the responder. This 263 is easier for the user than configuring which peers support TCP, but 264 has the potential of wasting resources, as TCP connections may finish 265 the three-way handshake just when IKE over UDP has finished. The 266 requirements from the responder ensure that all these policies will 267 work. 269 3.1. Liveness Check 271 The TCP connections described in this document are short-lived. We 272 do not expect them to stay for the lifetime of the SA, but to get 273 torn down by either side within seconds of the SA being set up. 274 Because of this, they are not well-suited for the transport of short 275 requests such as those for liveness check. 277 Although liveness checks MAY be sent over TCP, this is not 278 recommended. 280 4. Security Considerations 282 Most of the security considerations for IKE over TCP are the same as 283 those for UDP as in RFC 5996. 285 For the Responder, listening to TCP port 500 involves all the risks 286 of maintaining any TCP server. Precautions against DoS attacks, such 287 as SYN cookies are RECOMMENDED. 289 5. IANA Considerations 291 IANA is requested to assign a notify message type from the status 292 types range (16418-40959) of the "IKEv2 Notify Message Types" 293 registry with name "IKE_TCP_SUPPORTED" 295 No IANA action is required for the TCP port, as TCP port 500 is 296 already allocated to "ISAKMP". 298 6. References 300 6.1. Normative References 302 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 303 Requirement Levels", BCP 14, RFC 2119, March 1997. 305 [RFC2407] Piper, D., "The Internet IP Security Domain of 306 Interpretation for ISAKMP", RFC 2407, November 1998. 308 [RFC2408] Maughan, D., Schneider, M., and M. Schertler, "Internet 309 Security Association and Key Management Protocol 310 (ISAKMP)", RFC 2408, November 1998. 312 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 313 "Internet Key Exchange Protocol Version 2 (IKEv2)", 314 RFC 5996, September 2010. 316 6.2. Informative References 318 [I-D.ietf-behave-lsn-requirements] 319 Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 320 and H. Ashida, "Common requirements for Carrier Grade NATs 321 (CGNs)", draft-ietf-behave-lsn-requirements-08 (work in 322 progress), July 2012. 324 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 325 RFC 793, September 1981. 327 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 328 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 329 RFC 4787, January 2007. 331 Author's Address 333 Yoav Nir 334 Check Point Software Technologies Ltd. 335 5 Hasolelim st. 336 Tel Aviv 67897 337 Israel 339 Email: ynir@checkpoint.com