idnits 2.17.00 (12 Aug 2021) /tmp/idnits43082/draft-ietf-ipsecme-tcp-encaps-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 (December 3, 2016) is 1995 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: 'Section 12' is mentioned on line 129, but not defined == Missing Reference: 'Appendix A' is mentioned on line 291, but not defined == Missing Reference: 'Section 4' is mentioned on line 882, but not defined == Missing Reference: 'Figure 2' is mentioned on line 468, but not defined == Missing Reference: 'ChangeCipherSpec' is mentioned on line 847, but not defined == Missing Reference: 'CERTREQ' is mentioned on line 700, but not defined == Missing Reference: 'CERT' is mentioned on line 704, but not defined == Missing Reference: 'CP' is mentioned on line 742, but not defined -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network T. Pauly 3 Internet-Draft Apple Inc. 4 Intended status: Standards Track S. Touati 5 Expires: June 6, 2017 Ericsson 6 R. Mantha 7 Cisco Systems 8 December 3, 2016 10 TCP Encapsulation of IKE and IPsec Packets 11 draft-ietf-ipsecme-tcp-encaps-04 13 Abstract 15 This document describes a method to transport IKE and IPsec packets 16 over a TCP connection for traversing network middleboxes that may 17 block IKE negotiation over UDP. This method, referred to as TCP 18 encapsulation, involves sending both IKE packets for tunnel 19 establishment as well as tunneled packets using ESP over a TCP 20 connection. This method is intended to be used as a fallback option 21 when IKE cannot be negotiated over UDP. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on June 6, 2017. 40 Copyright Notice 42 Copyright (c) 2016 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Prior Work and Motivation . . . . . . . . . . . . . . . . 3 59 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 60 2. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. TCP-Encapsulated Header Formats . . . . . . . . . . . . . . . 5 62 3.1. TCP-Encapsulated IKE Header Format . . . . . . . . . . . 5 63 3.2. TCP-Encapsulated ESP Header Format . . . . . . . . . . . 6 64 4. TCP-Encapsulated Stream Prefix . . . . . . . . . . . . . . . 6 65 5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 7 66 5.1. Recommended Fallback from UDP . . . . . . . . . . . . . . 7 67 6. Connection Establishment and Teardown . . . . . . . . . . . . 8 68 7. Interaction with NAT Detection Payloads . . . . . . . . . . . 9 69 8. Using MOBIKE with TCP encapsulation . . . . . . . . . . . . . 9 70 9. Using IKE Message Fragmentation with TCP encapsulation . . . 10 71 10. Considerations for Keep-alives and DPD . . . . . . . . . . . 10 72 11. Middlebox Considerations . . . . . . . . . . . . . . . . . . 10 73 12. Performance Considerations . . . . . . . . . . . . . . . . . 11 74 12.1. TCP-in-TCP . . . . . . . . . . . . . . . . . . . . . . . 11 75 12.2. Added Reliability for Unreliable Protocols . . . . . . . 11 76 12.3. Quality of Service Markings . . . . . . . . . . . . . . 11 77 12.4. Maximum Segment Size . . . . . . . . . . . . . . . . . . 12 78 13. Security Considerations . . . . . . . . . . . . . . . . . . . 12 79 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 80 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 81 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 16.1. Normative References . . . . . . . . . . . . . . . . . . 12 83 16.2. Informative References . . . . . . . . . . . . . . . . . 13 84 Appendix A. Using TCP encapsulation with TLS . . . . . . . . . . 14 85 Appendix B. Example exchanges of TCP Encapsulation with TLS . . 15 86 B.1. Establishing an IKE session . . . . . . . . . . . . . . . 15 87 B.2. Deleting an IKE session . . . . . . . . . . . . . . . . . 17 88 B.3. Re-establishing an IKE session . . . . . . . . . . . . . 18 89 B.4. Using MOBIKE between UDP and TCP Encapsulation . . . . . 18 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 92 1. Introduction 94 IKEv2 [RFC7296] is a protocol for establishing IPsec tunnels, using 95 IKE messages over UDP for control traffic, and using Encapsulating 96 Security Payload (ESP) messages for tunneled data traffic. Many 97 network middleboxes that filter traffic on public hotspots block all 98 UDP traffic, including IKE and IPsec, but allow TCP connections 99 through since they appear to be web traffic. Devices on these 100 networks that need to use IPsec (to access private enterprise 101 networks, to route voice-over-IP calls to carrier networks, or 102 because of security policies) are unable to establish IPsec tunnels. 103 This document defines a method for encapsulating both the IKE control 104 messages as well as the IPsec data messages within a TCP connection. 106 Using TCP as a transport for IPsec packets adds a third option to the 107 list of traditional IPsec transports: 109 1. Direct. Currently, IKE negotiations begin over UDP port 500. 110 If no NAT is detected between the initiator and the receiver, 111 then subsequent IKE packets are sent over UDP port 500 and 112 IPsec data packets are sent using ESP [RFC4303]. 114 2. UDP Encapsulation [RFC3948]. If a NAT is detected between the 115 initiator and the receiver, then subsequent IKE packets are 116 sent over UDP port 4500 with four bytes of zero at the start of 117 the UDP payload and ESP packets are sent out over UDP port 118 4500. Some peers default to using UDP encapsulation even when 119 no NAT are detected on the path as some middleboxes do not 120 support IP protocols other than TCP and UDP. 122 3. TCP Encapsulation. If both of the other two methods are not 123 available or appropriate, both IKE negotiation packets as well 124 as ESP packets can be sent over a single TCP connection to the 125 peer. 127 Direct use of ESP or UDP Encapsulation should be preferred by IKE 128 implementations due to performance concerns when using TCP 129 Encapsulation [Section 12]. Most implementations should use TCP 130 Encapsulation only on networks where negotiation over UDP has been 131 attempted without receiving responses from the peer, or if a network 132 is known to not support UDP. 134 1.1. Prior Work and Motivation 136 Encapsulating IKE connections within TCP streams is a common approach 137 to solve the problem of UDP packets being blocked by network 138 middleboxes. The goal of this document is to promote 139 interoperability by providing a standard method of framing IKE and 140 ESP message within streams, and to provide guidelines for how to 141 configure and use TCP encapsulation. 143 Some previous alternatives include: 145 Cellular Network Access Interworking Wireless LAN (IWLAN) uses IKEv2 146 to create secure connections to cellular carrier networks for 147 making voice calls and accessing other network services over 148 Wi-Fi networks. 3GPP has recommended that IKEv2 and ESP packets 149 be sent within a TLS connection to be able to establish 150 connections on restrictive networks. 152 ISAKMP over TCP Various non-standard extensions to ISAKMP have been 153 deployed that send IPsec traffic over TCP or TCP-like packets. 155 SSL VPNs Many proprietary VPN solutions use a combination of TLS and 156 IPsec in order to provide reliability. 158 IKEv2 over TCP IKEv2 over TCP as described in 159 [I-D.nir-ipsecme-ike-tcp] is used to avoid UDP fragmentation. 161 The goal of this specification is to provide a standardized method 162 for using TCP streams to transport IPsec that is compatible with the 163 current IKE standard, and avoids the overhead of other alternatives 164 that always rely on TCP or TLS. 166 1.2. Requirements Language 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 170 document are to be interpreted as described in RFC 2119 [RFC2119]. 172 2. Configuration 174 One of the main reasons to use TCP encapsulation is that UDP traffic 175 may be entirely blocked on a network. Because of this, support for 176 TCP encapsulation is not specifically negotiated in the IKE exchange. 177 Instead, support for TCP encapsulation must be pre-configured on both 178 the initiator and the responder. 180 The configuration defined on each peer should include the following 181 parameters: 183 o One or more TCP ports on which the responder will listen for 184 incoming connections. Note that the initiator may initiate TCP 185 connections to the responder from any local port. The ports on 186 which the responder listens will likey be based on the ports 187 commonly allowed on restricted networks. 189 o Optionally, an extra framing protocol to use on top of TCP to 190 further encapsulate the stream of IKE and IPsec packets. See 191 Appendix A for a detailed discussion. 193 This document leaves the selection of TCP ports up to 194 implementations. It is suggested to use TCP port 4500, which is 195 allocated for IPsec NAT Traversal. 197 Since TCP encapsulation of IKE and IPsec packets adds overhead and 198 has potential performance trade-offs compared to direct or UDP- 199 encapsulated tunnels (as described in Performance Considerations, 200 Section 12), implementations SHOULD prefer ESP direct or UDP 201 encapsulated tunnels over TCP encapsulated tunnels when possible. 203 3. TCP-Encapsulated Header Formats 205 Like UDP encapsulation, TCP encapsulation uses the first four bytes 206 of a message to differentiate IKE and ESP messages. TCP 207 encapsulation also adds a length field to define the boundaries of 208 messages within a stream. The message length is sent in a 16-bit 209 field that precedes every message. If the first 32-bits of the 210 message are zeros (a Non-ESP Marker), then the contents comprise an 211 IKE message. Otherwise, the contents comprise an ESP message. 212 Authentication Header (AH) messages are not supported for TCP 213 encapsulation. 215 Although a TCP stream may be able to send very long messages, 216 implementations SHOULD limit message lengths to typical UDP datagram 217 ESP payload lengths. The maximum message length is used as the 218 effective MTU for connections that are being encrypted using ESP, so 219 the maximum message length will influence characteristics of inner 220 connections, such as the TCP Maximum Segment Size (MSS). 222 Note that this method of encapsulation will also work for placing IKE 223 and ESP messages within any protocol that presents a stream 224 abstraction, beyond TCP. 226 3.1. TCP-Encapsulated IKE Header Format 228 1 2 3 229 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 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Length | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Non-ESP Marker | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | | 236 ~ IKE header [RFC7296] ~ 237 | | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 Figure 1 242 The IKE header is preceded by a 16-bit length field in network byte 243 order that specifies the length of the IKE message (including the 244 Non-ESP marker) within the TCP stream. As with IKE over UDP port 245 4500, a zeroed 32-bit Non-ESP Marker is inserted before the start of 246 the IKE header in order to differentiate the traffic from ESP traffic 247 between the same addresses and ports. 249 o Length (2 octets, unsigned integer) - Length of the IKE packet 250 including the Length Field and Non-ESP Marker. 252 3.2. TCP-Encapsulated ESP Header Format 254 1 2 3 255 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 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Length | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | | 260 ~ ESP header [RFC4303] ~ 261 | | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 Figure 2 266 The ESP header is preceded by a 16-bit length field in network byte 267 order that specifies the length of the ESP packet within the TCP 268 stream. 270 The SPI field in the ESP header MUST NOT be a zero value. 272 o Length (2 octets, unsigned integer) - Length of the ESP packet 273 including the Length Field. 275 4. TCP-Encapsulated Stream Prefix 277 Each stream of bytes used for IKE and IPsec encapsulation MUST begin 278 with a fixed sequence of six bytes as a magic value, containing the 279 characters "IKETCP" as ASCII values. This allows peers to 280 differentiate this protocol from other protocols that may be run over 281 the same TCP port. Since TCP encapsulated IPsec is not assigned to a 282 specific port, responders may be able to receive multiple protocols 283 on the same port. The bytes of the stream prefix do not overlap with 284 the valid start of any other known stream protocol. This value is 285 only sent once, by the Initiator only, at the beginning of any stream 286 of IKE and ESP messages. 288 If other framing protocols are used within TCP to further encapsulate 289 or encrypt the stream of IKE and ESP messages, the Stream Prefix must 290 be at the start of the Initiator's IKE and ESP message stream within 291 the added protocol layer [Appendix A]. Although some framing 292 protocols do support negotiating inner protocols, the stream prefix 293 should always be used in order for implementations to be as generic 294 as possible and not rely on other framing protocols on top of TCP. 296 0 1 2 3 4 5 297 +------+------+------+------+------+------+ 298 | 0x49 | 0x4b | 0x45 | 0x54 | 0x43 | 0x50 | 299 +------+------+------+------+------+------+ 301 Figure 3 303 5. Applicability 305 TCP encapsulation is applicable only when it has been configured to 306 be used with specific IKE peers. If a responder is configured to use 307 TCP encapsulation, it MUST listen on the configured port(s) in case 308 any peers will initiate new IKE sessions. Initiators MAY use TCP 309 encapsulation for any IKE session to a peer that is configured to 310 support TCP encapsulation, although it is recommended that initiators 311 should only use TCP encapsulation when traffic over UDP is blocked. 313 Since the support of TCP encapsulation is a configured property, not 314 a negotiated one, it is recommended that if there are multiple IKE 315 endpoints representing a single peer (such as multiple machines with 316 different IP addresses when connecting by Fully-Qualified Domain 317 Name, or endpoints used with IKE redirection), all of the endpoints 318 equally support TCP encapsulation. 320 If TCP encapsulation is being used for a specific IKE SA, all 321 messages for that IKE SA and its Child SAs MUST be sent over a TCP 322 connection until the SA is deleted or MOBIKE is used to change the SA 323 endpoints and/or encapsulation protocol. See Section 8 for more 324 details on using MOBIKE to transition between encapsulation modes. 326 5.1. Recommended Fallback from UDP 328 Since UDP is the preferred method of transport for IKE messages, 329 implementations that use TCP encapsulation should have an algorithm 330 for deciding when to use TCP after determining that UDP is unusable. 331 If an initiator implementation has no prior knowledge about the 332 network it is on and the status of UDP on that network, it SHOULD 333 always attempt negotiate IKE over UDP first. IKEv2 defines how to 334 use retransmission timers with IKE messages, and IKE_SA_INIT messages 335 specifically [RFC7296]. Generally, this means that the 336 implementation will define a frequency of retransmission, and the 337 maximum number of retransmissions allowed before marking the IKE SA 338 as failed. An implementation can attempt negotiation over TCP once 339 it has hit the maximum retransmissions over UDP, or slightly before 340 to reduce connection setup delays. It is recommended that the 341 initial message over UDP is retransmitted at least once before 342 falling back to TCP, unless the initiator knows beforehand that the 343 network is likely to block UDP. 345 6. Connection Establishment and Teardown 347 When the IKE initiator uses TCP encapsulation for its negotiation, it 348 will initiate a TCP connection to the responder using the configured 349 TCP port. The first bytes sent on the stream MUST be the stream 350 prefix value [Section 4]. After this prefix, encapsulated IKE 351 messages will negotiate the IKE SA and initial Child SA [RFC7296]. 352 After this point, both encapsulated IKE Figure 1 and ESP Figure 2 353 messages will be sent over the TCP connection. 355 In order to close an IKE session, either the initiator or responder 356 SHOULD gracefully tear down IKE SAs with DELETE payloads. Once all 357 SAs have been deleted, the initiator of the original connection MUST 358 close the TCP connection. 360 An unexpected FIN or a RST on the TCP connection may indicate either 361 a loss of connectivity, an attack, or some other error. If a DELETE 362 payload has not been sent, both sides SHOULD maintain the state for 363 their SAs for the standard lifetime or time-out period. The original 364 initiator (that is, the endpoint that initiated the TCP connection 365 and sent the first IKE_SA_INIT message) is responsible for re- 366 establishing the TCP connection if it is torn down for any unexpected 367 reason. Since new TCP connections may use different ports due to NAT 368 mappings or local port allocations changing, the responder MUST allow 369 packets for existing SAs to be received from new source ports. 371 A peer MUST discard a partially received message due to a broken 372 connection. 374 The streams of data sent over any TCP connection used for this 375 protocol MUST begin with the stream prefix value followed by a 376 complete message, which is either an encapsulated IKE or ESP message. 377 If the connection is being used to resume a previous IKE session, the 378 responder can recognize the session using either the IKE SPI from an 379 encapsulated IKE message or the ESP SPI from an encapsulated ESP 380 message. If the session had been fully established previously, it is 381 suggested that the initiator send an UPDATE_SA_ADDRESSES message if 382 MOBIKE is supported, or an INFORMATIONAL message (a keepalive) 383 otherwise. If either initiator or responder receives a stream that 384 cannot be parsed correctly, it MUST close the TCP connection. 386 An initiator SHOULD only open one TCP connection per IKE SA, over 387 which it sends all of the corresponding IKE and ESP messages. This 388 helps ensure that any firewall or NAT mappings allocated for the TCP 389 connection apply to all of the traffic associated with the IKE SA 390 equally. 392 A responder SHOULD at any given time send packets for an IKE SA and 393 its Child SAs over only one TCP connection. It should choose the TCP 394 connection on which it last received a valid and decryptable IKE or 395 ESP message. Since a connection may be broken and a new connection 396 re-established by the initiator without the responder being aware, a 397 responder SHOULD accept receiving IKE and ESP messages on a new 398 connection. It will then use that connection for all subsequent 399 responses. A responder MAY close a TCP connection that it perceives 400 as idle and extraneous (one previously used for IKE and ESP messages 401 that has been replaced by a new connection). 403 Multiple IKE SAs SHOULD NOT share a single TCP connection. 405 7. Interaction with NAT Detection Payloads 407 When negotiating over UDP port 500, IKE_SA_INIT packets include 408 NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP payloads to 409 determine if UDP encapsulation of IPsec packets should be used. 410 These payloads contain SHA-1 digests of the SPIs, IP addresses, and 411 ports. IKE_SA_INIT packets sent on a TCP connection SHOULD include 412 these payloads, and SHOULD use the applicable TCP ports when creating 413 and checking the SHA-1 digests. 415 If a NAT is detected due to the SHA-1 digests not matching the 416 expected values, no change should be made for encapsulation of 417 subsequent IKE or ESP packets, since TCP encapsulation inherently 418 supports NAT traversal. Implementations MAY use the information that 419 a NAT is present to influence keep-alive timer values. 421 8. Using MOBIKE with TCP encapsulation 423 When an IKE session is transitioned between networks using MOBIKE 424 [RFC4555], the initiator of the transition may switch between using 425 TCP encapsulation, UDP encapsulation, or no encapsulation. 426 Implementations that implement both MOBIKE and TCP encapsulation MUST 427 support dynamically enabling and disabling TCP encapsulation as 428 interfaces change. 430 When a MOBIKE-enabled initiator changes networks, the 431 UPDATE_SA_ADDRESSES notification SHOULD be sent out first over UDP 432 before attempting over TCP. If there is a response to the 433 UPDATE_SA_ADDRESSES notification sent over UDP, then the ESP packets 434 should be sent directly over IP or over UDP port 4500 (depending on 435 if a NAT was detected), regardless of if a connection on a previous 436 network was using TCP encapsulation. Similarly, if the responder 437 only responds to the UPDATE_SA_ADDRESSES notification over TCP, then 438 the ESP packets should be sent over the TCP connection, regardless of 439 if a connection on a previous network did not use TCP encapsulation. 441 9. Using IKE Message Fragmentation with TCP encapsulation 443 IKE Message Fragmentation [RFC7383] is not required when using TCP 444 encapsulation, since a TCP stream already handles the fragmentation 445 of its contents across packets. Since fragmentation is redundant in 446 this case, implementations might choose to not negotiate IKE 447 fragmentation. Even if fragmentation is negotiated, an 448 implementation MAY choose to not fragment when going over a TCP 449 connection. 451 If an implementation supports both MOBIKE and IKE fragmentation, it 452 SHOULD negotiate IKE fragmentation over a TCP encapsulated session in 453 case the session switches to UDP encapsulation on another network. 455 10. Considerations for Keep-alives and DPD 457 Encapsulating IKE and IPsec inside of a TCP connection can impact the 458 strategy that implementations use to detect peer liveness and to 459 maintain middlebox port mappings. Peer liveness should be checked 460 using IKE Informational packets [RFC7296]. 462 In general, TCP port mappings are maintained by NATs longers than UDP 463 port mappings, so IPsec ESP NAT keep-alives [RFC3948] SHOULD NOT be 464 sent when using TCP encapsulation. Any implementation using TCP 465 encapsulation MUST silently drop incoming NAT keep-alive packets, and 466 not treat them as errors. NAT keep-alive packets over a TCP 467 encapsulated IPsec connection will be sent with a length value of 1 468 byte, whose value is 0xFF [Figure 2]. 470 Note that depending on the configuration of TCP and TLS on the 471 connection, TCP keep-alives [RFC1122] and TLS keep-alives [RFC6520] 472 may be used. These MUST NOT be used as indications of IKE peer 473 liveness. 475 11. Middlebox Considerations 477 Many security networking devices such as Firewalls or Intrusion 478 Prevention Systems, network optimization/acceleration devices and 479 Network Address Translation (NAT) devices keep the state of sessions 480 that traverse through them. 482 These devices commonly track the transport layer and/or the 483 application layer data to drop traffic that is anomalous or malicious 484 in nature. 486 A network device that monitors up to the application layer will 487 commonly expect to see HTTP traffic within a TCP socket running over 488 port 80, if non-HTTP traffic is seen (such as TCP encapsulated IKE), 489 this could be dropped by the security device. 491 A network device that monitors the transport layer will track the 492 state of TCP sessions, such as TCP sequence numbers. TCP 493 encapsulation of IKE should therefore use standard TCP behaviors to 494 avoid being dropped by middleboxes. 496 12. Performance Considerations 498 Several aspects of TCP encapsulation for IKE and IPsec packets may 499 negatively impact the performance of connections within the tunnel. 500 Implementations should be aware of these and take these into 501 consideration when determining when to use TCP encapsulation. 503 12.1. TCP-in-TCP 505 If the outer connection between IKE peers is over TCP, inner TCP 506 connections may suffer effects from using TCP within TCP. In 507 particular, the inner TCP's round-trip-time estimation will be 508 affected by the burstiness of the outer TCP. This will make loss- 509 recovery of the inner TCP traffic less reactive and more prone to 510 spurious retransmission timeouts. 512 12.2. Added Reliability for Unreliable Protocols 514 Since ESP is an unreliable protocol, transmitting ESP packets over a 515 TCP connection will change the fundamental behavior of the packets. 516 Some application-level protocols that prefer packet loss to delay 517 (such as Voice over IP or other real-time protocols) may be 518 negatively impacted if their packets are retransmitted by the TCP 519 connection due to packet loss. 521 12.3. Quality of Service Markings 523 Quality of Service (QoS) markings, such as DSCP and Traffic Class, 524 should be used with care on TCP connections used for encapsulation. 525 Individual packets SHOULD NOT use different markings than the rest of 526 the connection, since packets with different priorities may be routed 527 differently and cause unnecessary delays in the connection. 529 12.4. Maximum Segment Size 531 A TCP connection used for IKE encapsulation SHOULD negotiate its 532 maximum segment size (MSS) in order to avoid unnecessary 533 fragmentation of packets. 535 13. Security Considerations 537 IKE responders that support TCP encapsulation may become vulnerable 538 to new Denial-of-Service (DoS) attacks that are specific to TCP, such 539 as SYN-flooding attacks. Responders should be aware of this 540 additional attack-surface. 542 Responders should be careful to ensure that the stream prefix 543 "IKETCP" uniquely identifies streams using the TCP encapsulation 544 protocol. The prefix was chosen to not overlap with the start of any 545 known valid protocol over TCP, but implementations should make sure 546 to validate this assumption in order to avoid unexpected processing 547 of TCP connections. 549 Attackers may be able to disrupt the TCP connection by sending 550 spurious RST packets. Due to this, implementations SHOULD make sure 551 that IKE session state persists even if the underlying TCP connection 552 is torn down. 554 14. IANA Considerations 556 This memo includes no request to IANA. 558 TCP port 4500 is already allocated to IPsec. This port MAY be used 559 for the protocol described in this document, but implementations MAY 560 prefer to use other ports based on local policy. 562 15. Acknowledgments 564 The authors would like to acknowledge the input and advice of Stuart 565 Cheshire, Delziel Fernandes, Yoav Nir, Christoph Paasch, Yaron 566 Sheffer, David Schinazi, Graham Bartlett, Byju Pularikkal, March Wu 567 and Kingwel Xie. Special thanks to Eric Kinnear for his 568 implementation work. 570 16. References 572 16.1. Normative References 574 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 575 Requirement Levels", BCP 14, RFC 2119, 576 DOI 10.17487/RFC2119, March 1997, 577 . 579 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 580 Kivinen, "Internet Key Exchange Protocol Version 2 581 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 582 2014, . 584 16.2. Informative References 586 [I-D.nir-ipsecme-ike-tcp] 587 Nir, Y., "A TCP transport for the Internet Key Exchange", 588 draft-nir-ipsecme-ike-tcp-01 (work in progress), July 589 2012. 591 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 592 Communication Layers", STD 3, RFC 1122, 593 DOI 10.17487/RFC1122, October 1989, 594 . 596 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within 597 HTTP/1.1", RFC 2817, DOI 10.17487/RFC2817, May 2000, 598 . 600 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 601 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 602 RFC 3948, DOI 10.17487/RFC3948, January 2005, 603 . 605 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 606 RFC 4303, DOI 10.17487/RFC4303, December 2005, 607 . 609 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 610 (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, 611 . 613 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 614 (TLS) Protocol Version 1.2", RFC 5246, 615 DOI 10.17487/RFC5246, August 2008, 616 . 618 [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport 619 Layer Security (TLS) and Datagram Transport Layer Security 620 (DTLS) Heartbeat Extension", RFC 6520, 621 DOI 10.17487/RFC6520, February 2012, 622 . 624 [RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 625 (IKEv2) Message Fragmentation", RFC 7383, 626 DOI 10.17487/RFC7383, November 2014, 627 . 629 Appendix A. Using TCP encapsulation with TLS 631 This section provides recommendations on the support of TLS with the 632 TCP encapsulation. 634 When using TCP encapsulation, implementations may choose to use TLS 635 [RFC5246], to be able to traverse middle-boxes, which may block non 636 HTTP traffic. 638 If a web proxy is applied to the ports for the TCP connection, and 639 TLS is being used, the initiator can send an HTTP CONNECT message to 640 establish a tunnel through the proxy [RFC2817]. 642 The use of TLS should be configurable on the peers. The responder 643 may expect to read encapsulated IKE and ESP packets directly from the 644 TCP connection, or it may expect to read them from a stream of TLS 645 data packets. The initiator should be pre-configured to use TLS or 646 not when communicating with a given port on the responder. 648 When new TCP connections are re-established due to a broken 649 connection, TLS must be re-negotiated. TLS Session Resumption is 650 recommended to improve efficiency in this case. 652 The security of the IKE session is entirely derived from the IKE 653 negotiation and key establishment and not from the TLS session (which 654 in this context is only used for encapsulation purposes), therefore 655 when TLS is used on the TCP connection, both the initiator and 656 responder SHOULD allow the NULL cipher to be selected for performance 657 reasons. 659 Implementations should be aware that the use of TLS introduces 660 another layer of overhead requiring more bytes to transmit a given 661 IKE and IPsec packet. For this reason, direct ESP, UDP 662 encapsulation, or TCP encapsulation without TLS should be preferred 663 in situations in which TLS is not required in order to traverse 664 middle-boxes. 666 Appendix B. Example exchanges of TCP Encapsulation with TLS 668 B.1. Establishing an IKE session 669 Client Server 670 ---------- ---------- 671 1) -------------------- TCP Connection ------------------- 672 (IP_I:Port_I -> IP_R:TCP443 or TCP4500) 673 TcpSyn ----------> 674 <---------- TcpSyn,Ack 675 TcpAck ----------> 677 2) --------------------- TLS Session --------------------- 678 ClientHello ----------> 679 ServerHello 680 Certificate* 681 ServerKeyExchange* 682 <---------- ServerHelloDone 683 ClientKeyExchange 684 CertificateVerify* 685 [ChangeCipherSpec] 686 Finished ----------> 687 [ChangeCipherSpec] 688 <---------- Finished 690 3) ---------------------- Stream Prefix -------------------- 691 "IKETCP" ----------> 692 4) ----------------------- IKE Session --------------------- 693 IKE_SA_INIT ----------> 694 HDR, SAi1, KEi, Ni, 695 [N(NAT_DETECTION_*_IP)] 696 <---------- IKE_SA_INIT 697 HDR, SAr1, KEr, Nr, 698 [N(NAT_DETECTION_*_IP)] 699 first IKE_AUTH ----------> 700 HDR, SK {IDi, [CERTREQ] 701 CP(CFG_REQUEST), IDr, 702 SAi2, TSi, TSr, ...} 703 <---------- first IKE_AUTH 704 HDR, SK {IDr, [CERT], AUTH, 705 EAP, SAr2, TSi, TSr} 706 EAP ----------> 707 repeat 1..N times 708 <---------- EAP 709 final IKE_AUTH ----------> 710 HDR, SK {AUTH} 711 <---------- final IKE_AUTH 712 HDR, SK {AUTH, CP(CFG_REPLY), 713 SA, TSi, TSr, ...} 714 ----------------- IKE Tunnel Established ---------------- 716 Figure 4 718 1. Client establishes a TCP connection with the server on port 443 719 or 4500. 721 2. Client initiates TLS handshake. During TLS handshake, the 722 server SHOULD NOT request the client's' certificate, since 723 authentication is handled as part of IKE negotiation. 725 3. Client send the Stream Prefix for TCP encapsulated IKE 726 [Section 4] traffic to signal the beginning of IKE negotation. 728 4. Client and server establish an IKE connection. This example 729 shows EAP-based authentication, although any authentication 730 type may be used. 732 B.2. Deleting an IKE session 734 Client Server 735 ---------- ---------- 736 1) ----------------------- IKE Session --------------------- 737 INFORMATIONAL ----------> 738 HDR, SK {[N,] [D,] 739 [CP,] ...} 740 <---------- INFORMATIONAL 741 HDR, SK {[N,] [D,] 742 [CP], ...} 744 2) --------------------- TLS Session --------------------- 745 close_notify ----------> 746 <---------- close_notify 747 3) -------------------- TCP Connection ------------------- 748 TcpFin ----------> 749 <---------- Ack 750 <---------- TcpFin 751 Ack ----------> 752 --------------------- Tunnel Deleted ------------------- 754 Figure 5 756 1. Client and server exchange INFORMATIONAL messages to notify IKE 757 SA deletion. 759 2. Client and server negotiate TLS session deletion using TLS 760 CLOSE_NOTIFY. 762 3. The TCP connection is torn down. 764 The deletion of the IKE SA should lead to the disposal of the 765 underlying TLS and TCP state. 767 B.3. Re-establishing an IKE session 769 Client Server 770 ---------- ---------- 771 1) -------------------- TCP Connection ------------------- 772 (IP_I:Port_I -> IP_R:TCP443 or TCP4500) 773 TcpSyn ----------> 774 <---------- TcpSyn,Ack 775 TcpAck ----------> 776 2) --------------------- TLS Session --------------------- 777 ClientHello ----------> 778 <---------- ServerHello 779 [ChangeCipherSpec] 780 Finished 781 [ChangeCipherSpec] ----------> 782 Finished 783 3) ---------------------- Stream Prefix -------------------- 784 "IKETCP" ----------> 785 4) <---------------------> IKE/ESP flow <------------------> 787 Figure 6 789 1. If a previous TCP connection was broken (for example, due to a 790 RST), the client is responsible for re-initiating the TCP 791 connection. The initiator's address and port (IP_I and Port_I) 792 may be different from the previous connection's address and 793 port. 795 2. In ClientHello TLS message, the client SHOULD send the Session 796 ID it received in the previous TLS handshake if available. It 797 is up to the server to perform either an abbreviated handshake 798 or full handshake based on the session ID match. 800 3. After TCP and TLS are complete, the client sends the Stream 801 Prefix for TCP encapsulated IKE traffic [Section 4]. 803 4. The IKE and ESP packet flow can resume. If MOBIKE is being 804 used, the initiator SHOULD send UPDATE_SA_ADDRESSES. 806 B.4. Using MOBIKE between UDP and TCP Encapsulation 808 Client Server 809 ---------- ---------- 810 (IP_I1:UDP500 -> IP_R:UDP500) 811 1) ----------------- IKE_SA_INIT Exchange ----------------- 812 (IP_I1:UDP4500 -> IP_R:UDP4500) 813 Intial IKE_AUTH -----------> 814 HDR, SK { IDi, CERT, AUTH, 815 CP(CFG_REQUEST), 816 SAi2, TSi, TSr, 817 N(MOBIKE_SUPPORTED) } 818 <----------- Initial IKE_AUTH 819 HDR, SK { IDr, CERT, AUTH, 820 EAP, SAr2, TSi, TSr, 821 N(MOBIKE_SUPPORTED) } 822 <---------------- IKE tunnel establishment -------------> 824 2) ------------ MOBIKE Attempt on new network -------------- 825 (IP_I2:UDP4500 -> IP_R:UDP4500) 826 INFORMATIONAL -----------> 827 HDR, SK { N(UPDATE_SA_ADDRESSES), 828 N(NAT_DETECTION_SOURCE_IP), 829 N(NAT_DETECTION_DESTINATION_IP) } 831 3) -------------------- TCP Connection ------------------- 832 (IP_I2:PORT_I -> IP_R:TCP443 or TCP4500) 833 TcpSyn -----------> 834 <----------- TcpSyn,Ack 835 TcpAck -----------> 837 4) --------------------- TLS Session --------------------- 838 ClientHello -----------> 839 ServerHello 840 Certificate* 841 ServerKeyExchange* 842 <----------- ServerHelloDone 843 ClientKeyExchange 844 CertificateVerify* 845 [ChangeCipherSpec] 846 Finished -----------> 847 [ChangeCipherSpec] 848 <----------- Finished 849 5) ---------------------- Stream Prefix -------------------- 850 "IKETCP" ----------> 852 6) ----------------------- IKE Session --------------------- 853 INFORMATIONAL -----------> 854 HDR, SK { N(UPDATE_SA_ADDRESSES), 855 N(NAT_DETECTION_SOURCE_IP), 856 N(NAT_DETECTION_DESTINATION_IP) } 858 <----------- INFORMATIONAL 860 HDR, SK { N(NAT_DETECTION_SOURCE_IP), 861 N(NAT_DETECTION_DESTINATION_IP) } 862 7) <----------------- IKE/ESP data flow -------------------> 864 Figure 7 866 1. During the IKE_SA_INIT exchange, the client and server exchange 867 MOBIKE_SUPPORTED notify payloads to indicate support for 868 MOBIKE. 870 2. The client changes its point of attachment to the network, and 871 receives a new IP address. The client attempts to re-establish 872 the IKE session using the UPDATE_SA_ADDRESSES notify payload, 873 but the server does not respond because the network blocks UDP 874 traffic. 876 3. The client brings up a TCP connection to the server in order to 877 use TCP encapsulation. 879 4. The client initiates and TLS handshake with the server. 881 5. The client sends the Stream Prefix for TCP encapsulated IKE 882 traffic [Section 4]. 884 6. The client sends the UPDATE_SA_ADDRESSES notify payload on the 885 TCP encapsulated connection. 887 7. The IKE and ESP packet flow can resume. 889 Authors' Addresses 891 Tommy Pauly 892 Apple Inc. 893 1 Infinite Loop 894 Cupertino, California 95014 895 US 897 Email: tpauly@apple.com 899 Samy Touati 900 Ericsson 901 300 Holger Way 902 San Jose, California 95134 903 US 905 Email: samy.touati@ericsson.com 906 Ravi Mantha 907 Cisco Systems 908 SEZ, Embassy Tech Village 909 Panathur, Bangalore 560 037 910 India 912 Email: ramantha@cisco.com