idnits 2.17.1 draft-ietf-ipsecme-tcp-encaps-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (October 31, 2016) is 2726 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 877, but not defined == Missing Reference: 'Figure 2' is mentioned on line 463, but not defined == Missing Reference: 'ChangeCipherSpec' is mentioned on line 843, but not defined == Missing Reference: 'CERTREQ' is mentioned on line 695, but not defined == Missing Reference: 'CERT' is mentioned on line 699, but not defined == Missing Reference: 'CP' is mentioned on line 737, 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: May 4, 2017 Ericsson 6 R. Mantha 7 Cisco Systems 8 October 31, 2016 10 TCP Encapsulation of IKE and IPsec Packets 11 draft-ietf-ipsecme-tcp-encaps-03 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 May 4, 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 . . . . . . . . . . . . . . . . . . 11 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 . . 14 86 B.1. Establishing an IKE session . . . . . . . . . . . . . . . 14 87 B.2. Deleting an IKE session . . . . . . . . . . . . . . . . . 16 88 B.3. Re-establishing an IKE session . . . . . . . . . . . . . 17 89 B.4. Using MOBIKE between UDP and TCP Encapsulation . . . . . 18 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 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 Multiple TCP connections between the initiator and the responder are 387 allowed, but their use must take into account the initiator 388 capabilities and the deployment model such as to connect to multiple 389 gateways handling different ESP SAs when deployed in a high 390 availability model. If multiple TCP connections are used, 391 implementations SHOULD allow receiving any IKE or ESP SA over any of 392 the TCP connections, not enforcing any strict mapping. It is also 393 possible to negotiate multiple IKE SAs over the same TCP connection 394 in order to reduce the number of connections between the two peers. 396 The processing of the TCP-encapsulated IKE and ESP packets is the 397 same when using either a single TCP connection or multiple TCP 398 connections. 400 7. Interaction with NAT Detection Payloads 402 When negotiating over UDP port 500, IKE_SA_INIT packets include 403 NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP payloads to 404 determine if UDP encapsulation of IPsec packets should be used. 405 These payloads contain SHA-1 digests of the SPIs, IP addresses, and 406 ports. IKE_SA_INIT packets sent on a TCP connection SHOULD include 407 these payloads, and SHOULD use the applicable TCP ports when creating 408 and checking the SHA-1 digests. 410 If a NAT is detected due to the SHA-1 digests not matching the 411 expected values, no change should be made for encapsulation of 412 subsequent IKE or ESP packets, since TCP encapsulation inherently 413 supports NAT traversal. Implementations MAY use the information that 414 a NAT is present to influence keep-alive timer values. 416 8. Using MOBIKE with TCP encapsulation 418 When an IKE session is transitioned between networks using MOBIKE 419 [RFC4555], the initiator of the transition may switch between using 420 TCP encapsulation, UDP encapsulation, or no encapsulation. 421 Implementations that implement both MOBIKE and TCP encapsulation MUST 422 support dynamically enabling and disabling TCP encapsulation as 423 interfaces change. 425 When a MOBIKE-enabled initiator changes networks, the 426 UPDATE_SA_ADDRESSES notification SHOULD be sent out first over UDP 427 before attempting over TCP. If there is a response to the 428 UPDATE_SA_ADDRESSES notification sent over UDP, then the ESP packets 429 should be sent directly over IP or over UDP port 4500 (depending on 430 if a NAT was detected), regardless of if a connection on a previous 431 network was using TCP encapsulation. Similarly, if the responder 432 only responds to the UPDATE_SA_ADDRESSES notification over TCP, then 433 the ESP packets should be sent over the TCP connection, regardless of 434 if a connection on a previous network did not use TCP encapsulation. 436 9. Using IKE Message Fragmentation with TCP encapsulation 438 IKE Message Fragmentation [RFC7383] is not required when using TCP 439 encapsulation, since a TCP stream already handles the fragmentation 440 of its contents across packets. Since fragmentation is redundant in 441 this case, implementations might choose to not negotiate IKE 442 fragmentation. Even if fragmentation is negotiated, an 443 implementation MAY choose to not fragment when going over a TCP 444 connection. 446 If an implementation supports both MOBIKE and IKE fragmentation, it 447 SHOULD negotiate IKE fragmentation over a TCP encapsulated session in 448 case the session switches to UDP encapsulation on another network. 450 10. Considerations for Keep-alives and DPD 452 Encapsulating IKE and IPsec inside of a TCP connection can impact the 453 strategy that implementations use to detect peer liveness and to 454 maintain middlebox port mappings. Peer liveness should be checked 455 using IKE Informational packets [RFC7296]. 457 In general, TCP port mappings are maintained by NATs longers than UDP 458 port mappings, so IPsec ESP NAT keep-alives [RFC3948] SHOULD NOT be 459 sent when using TCP encapsulation. Any implementation using TCP 460 encapsulation MUST silently drop incoming NAT keep-alive packets, and 461 not treat them as errors. NAT keep-alive packets over a TCP 462 encapsulated IPsec connection will be sent with a length value of 1 463 byte, whose value is 0xFF [Figure 2]. 465 Note that depending on the configuration of TCP and TLS on the 466 connection, TCP keep-alives [RFC1122] and TLS keep-alives [RFC6520] 467 may be used. These MUST NOT be used as indications of IKE peer 468 liveness. 470 11. Middlebox Considerations 472 Many security networking devices such as Firewalls or Intrusion 473 Prevention Systems, network optimization/acceleration devices and 474 Network Address Translation (NAT) devices keep the state of sessions 475 that traverse through them. 477 These devices commonly track the transport layer and/or the 478 application layer data to drop traffic that is anomalous or malicious 479 in nature. 481 A network device that monitors up to the application layer will 482 commonly expect to see HTTP traffic within a TCP socket running over 483 port 80, if non-HTTP traffic is seen (such as TCP encapsulated IKE), 484 this could be dropped by the security device. 486 A network device that monitors the transport layer will track the 487 state of TCP sessions, such as TCP sequence numbers. TCP 488 encapsulation of IKE should therefore use standard TCP behaviors to 489 avoid being dropped by middleboxes. 491 12. Performance Considerations 493 Several aspects of TCP encapsulation for IKE and IPsec packets may 494 negatively impact the performance of connections within the tunnel. 495 Implementations should be aware of these and take these into 496 consideration when determining when to use TCP encapsulation. 498 12.1. TCP-in-TCP 500 If the outer connection between IKE peers is over TCP, inner TCP 501 connections may suffer effects from using TCP within TCP. In 502 particular, the inner TCP's round-trip-time estimation will be 503 affected by the burstiness of the outer TCP. This will make loss- 504 recovery of the inner TCP traffic less reactive and more prone to 505 spurious retransmission timeouts. 507 12.2. Added Reliability for Unreliable Protocols 509 Since ESP is an unreliable protocol, transmitting ESP packets over a 510 TCP connection will change the fundamental behavior of the packets. 511 Some application-level protocols that prefer packet loss to delay 512 (such as Voice over IP or other real-time protocols) may be 513 negatively impacted if their packets are retransmitted by the TCP 514 connection due to packet loss. 516 12.3. Quality of Service Markings 518 Quality of Service (QoS) markings, such as DSCP and Traffic Class, 519 should be used with care on TCP connections used for encapsulation. 520 Individual packets SHOULD NOT use different markings than the rest of 521 the connection, since packets with different priorities may be routed 522 differently and cause unnecessary delays in the connection. 524 12.4. Maximum Segment Size 526 A TCP connection used for IKE encapsulation SHOULD negotiate its 527 maximum segment size (MSS) in order to avoid unnecessary 528 fragmentation of packets. 530 13. Security Considerations 532 IKE responders that support TCP encapsulation may become vulnerable 533 to new Denial-of-Service (DoS) attacks that are specific to TCP, such 534 as SYN-flooding attacks. Responders should be aware of this 535 additional attack-surface. 537 Responders should be careful to ensure that the stream prefix 538 "IKETCP" uniquely identifies streams using the TCP encapsulation 539 protocol. The prefix was chosen to not overlap with the start of any 540 known valid protocol over TCP, but implementations should make sure 541 to validate this assumption in order to avoid unexpected processing 542 of TCP connections. 544 Attackers may be able to disrupt the TCP connection by sending 545 spurious RST packets. Due to this, implementations SHOULD make sure 546 that IKE session state persists even if the underlying TCP connection 547 is torn down. 549 14. IANA Considerations 551 This memo includes no request to IANA. 553 TCP port 4500 is already allocated to IPsec. This port MAY be used 554 for the protocol described in this document, but implementations MAY 555 prefer to use other ports based on local policy. 557 15. Acknowledgments 559 The authors would like to acknowledge the input and advice of Stuart 560 Cheshire, Delziel Fernandes, Yoav Nir, Christoph Paasch, Yaron 561 Sheffer, David Schinazi, Graham Bartlett, Byju Pularikkal, March Wu 562 and Kingwel Xie. Special thanks to Eric Kinnear for his 563 implementation work. 565 16. References 567 16.1. Normative References 569 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 570 Requirement Levels", BCP 14, RFC 2119, 571 DOI 10.17487/RFC2119, March 1997, 572 . 574 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 575 Kivinen, "Internet Key Exchange Protocol Version 2 576 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 577 2014, . 579 16.2. Informative References 581 [I-D.nir-ipsecme-ike-tcp] 582 Nir, Y., "A TCP transport for the Internet Key Exchange", 583 draft-nir-ipsecme-ike-tcp-01 (work in progress), July 584 2012. 586 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 587 Communication Layers", STD 3, RFC 1122, 588 DOI 10.17487/RFC1122, October 1989, 589 . 591 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within 592 HTTP/1.1", RFC 2817, DOI 10.17487/RFC2817, May 2000, 593 . 595 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 596 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 597 RFC 3948, DOI 10.17487/RFC3948, January 2005, 598 . 600 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 601 RFC 4303, DOI 10.17487/RFC4303, December 2005, 602 . 604 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 605 (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, 606 . 608 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 609 (TLS) Protocol Version 1.2", RFC 5246, 610 DOI 10.17487/RFC5246, August 2008, 611 . 613 [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport 614 Layer Security (TLS) and Datagram Transport Layer Security 615 (DTLS) Heartbeat Extension", RFC 6520, 616 DOI 10.17487/RFC6520, February 2012, 617 . 619 [RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 620 (IKEv2) Message Fragmentation", RFC 7383, 621 DOI 10.17487/RFC7383, November 2014, 622 . 624 Appendix A. Using TCP encapsulation with TLS 626 This section provides recommendations on the support of TLS with the 627 TCP encapsulation. 629 When using TCP encapsulation, implementations may choose to use TLS 630 [RFC5246], to be able to traverse middle-boxes, which may block non 631 HTTP traffic. 633 If a web proxy is applied to the ports for the TCP connection, and 634 TLS is being used, the initiator can send an HTTP CONNECT message to 635 establish a tunnel through the proxy [RFC2817]. 637 The use of TLS should be configurable on the peers. The responder 638 may expect to read encapsulated IKE and ESP packets directly from the 639 TCP connection, or it may expect to read them from a stream of TLS 640 data packets. The initiator should be pre-configured to use TLS or 641 not when communicating with a given port on the responder. 643 When new TCP connections are re-established due to a broken 644 connection, TLS must be re-negotiated. TLS Session Resumption is 645 recommended to improve efficiency in this case. 647 The security of the IKE session is entirely derived from the IKE 648 negotiation and key establishment and not from the TLS session (which 649 in this context is only used for encapsulation purposes), therefore 650 when TLS is used on the TCP connection, both the initiator and 651 responder SHOULD allow the NULL cipher to be selected for performance 652 reasons. 654 Implementations should be aware that the use of TLS introduces 655 another layer of overhead requiring more bytes to transmit a given 656 IKE and IPsec packet. For this reason, direct ESP, UDP 657 encapsulation, or TCP encapsulation without TLS should be preferred 658 in situations in which TLS is not required in order to traverse 659 middle-boxes. 661 Appendix B. Example exchanges of TCP Encapsulation with TLS 663 B.1. Establishing an IKE session 664 Client Server 665 ---------- ---------- 666 1) -------------------- TCP Connection ------------------- 667 (IP_I:Port_I -> IP_R:TCP443 or TCP4500) 668 TcpSyn ----------> 669 <---------- TcpSyn,Ack 670 TcpAck ----------> 672 2) --------------------- TLS Session --------------------- 673 ClientHello ----------> 674 ServerHello 675 Certificate* 676 ServerKeyExchange* 677 <---------- ServerHelloDone 678 ClientKeyExchange 679 CertificateVerify* 680 [ChangeCipherSpec] 681 Finished ----------> 682 [ChangeCipherSpec] 683 <---------- Finished 685 3) ---------------------- Stream Prefix -------------------- 686 "IKETCP" ----------> 687 4) ----------------------- IKE Session --------------------- 688 IKE_SA_INIT ----------> 689 HDR, SAi1, KEi, Ni, 690 [N(NAT_DETECTION_*_IP)] 691 <---------- IKE_SA_INIT 692 HDR, SAr1, KEr, Nr, 693 [N(NAT_DETECTION_*_IP)] 694 first IKE_AUTH ----------> 695 HDR, SK {IDi, [CERTREQ] 696 CP(CFG_REQUEST), IDr, 697 SAi2, TSi, TSr, ...} 698 <---------- first IKE_AUTH 699 HDR, SK {IDr, [CERT], AUTH, 700 EAP, SAr2, TSi, TSr} 701 EAP ----------> 702 repeat 1..N times 703 <---------- EAP 704 final IKE_AUTH ----------> 705 HDR, SK {AUTH} 706 <---------- final IKE_AUTH 707 HDR, SK {AUTH, CP(CFG_REPLY), 708 SA, TSi, TSr, ...} 709 ----------------- IKE Tunnel Established ---------------- 711 Figure 4 713 1. Client establishes a TCP connection with the server on port 443 714 or 4500. 716 2. Client initiates TLS handshake. During TLS handshake, the 717 server SHOULD NOT request the client's' certificate, since 718 authentication is handled as part of IKE negotiation. 720 3. Client send the Stream Prefix for TCP encapsulated IKE 721 [Section 4] traffic to signal the beginning of IKE negotation. 723 4. Client and server establish an IKE connection. This example 724 shows EAP-based authentication, although any authentication 725 type may be used. 727 B.2. Deleting an IKE session 729 Client Server 730 ---------- ---------- 731 1) ----------------------- IKE Session --------------------- 732 INFORMATIONAL ----------> 733 HDR, SK {[N,] [D,] 734 [CP,] ...} 735 <---------- INFORMATIONAL 736 HDR, SK {[N,] [D,] 737 [CP], ...} 739 2) --------------------- TLS Session --------------------- 740 close_notify ----------> 741 <---------- close_notify 742 3) -------------------- TCP Connection ------------------- 743 TcpFin ----------> 744 <---------- Ack 745 <---------- TcpFin 746 Ack ----------> 747 --------------------- Tunnel Deleted ------------------- 749 Figure 5 751 1. Client and server exchange INFORMATIONAL messages to notify IKE 752 SA deletion. 754 2. Client and server negotiate TLS session deletion using TLS 755 CLOSE_NOTIFY. 757 3. The TCP connection is torn down. 759 Unless the TCP connection and/or TLS session are being used for 760 multiple IKE SAs, the deletion of the IKE SA should lead to the 761 disposal of the underlying TLS and TCP state. 763 B.3. Re-establishing an IKE session 765 Client Server 766 ---------- ---------- 767 1) -------------------- TCP Connection ------------------- 768 (IP_I:Port_I -> IP_R:TCP443 or TCP4500) 769 TcpSyn ----------> 770 <---------- TcpSyn,Ack 771 TcpAck ----------> 772 2) --------------------- TLS Session --------------------- 773 ClientHello ----------> 774 <---------- ServerHello 775 [ChangeCipherSpec] 776 Finished 777 [ChangeCipherSpec] ----------> 778 Finished 779 3) ---------------------- Stream Prefix -------------------- 780 "IKETCP" ----------> 781 4) <---------------------> IKE/ESP flow <------------------> 783 Figure 6 785 1. If a previous TCP connection was broken (for example, due to a 786 RST), the client is responsible for re-initiating the TCP 787 connection. The initiator's address and port (IP_I and Port_I) 788 may be different from the previous connection's address and 789 port. 791 2. In ClientHello TLS message, the client SHOULD send the Session 792 ID it received in the previous TLS handshake if available. It 793 is up to the server to perform either an abbreviated handshake 794 or full handshake based on the session ID match. 796 3. After TCP and TLS are complete, the client sends the Stream 797 Prefix for TCP encapsulated IKE traffic [Section 4]. 799 4. The IKE and ESP packet flow can resume. If MOBIKE is being 800 used, the initiator SHOULD send UPDATE_SA_ADDRESSES. 802 B.4. Using MOBIKE between UDP and TCP Encapsulation 804 Client Server 805 ---------- ---------- 806 (IP_I1:UDP500 -> IP_R:UDP500) 807 1) ----------------- IKE_SA_INIT Exchange ----------------- 808 (IP_I1:UDP4500 -> IP_R:UDP4500) 809 Intial IKE_AUTH -----------> 810 HDR, SK { IDi, CERT, AUTH, 811 CP(CFG_REQUEST), 812 SAi2, TSi, TSr, 813 N(MOBIKE_SUPPORTED) } 814 <----------- Initial IKE_AUTH 815 HDR, SK { IDr, CERT, AUTH, 816 EAP, SAr2, TSi, TSr, 817 N(MOBIKE_SUPPORTED) } 818 <---------------- IKE tunnel establishment -------------> 820 2) ------------ MOBIKE Attempt on new network -------------- 821 (IP_I2:UDP4500 -> IP_R:UDP4500) 822 INFORMATIONAL -----------> 823 HDR, SK { N(UPDATE_SA_ADDRESSES), 824 N(NAT_DETECTION_SOURCE_IP), 825 N(NAT_DETECTION_DESTINATION_IP) } 827 3) -------------------- TCP Connection ------------------- 828 (IP_I2:PORT_I -> IP_R:TCP443 or TCP4500) 829 TcpSyn -----------> 830 <----------- TcpSyn,Ack 831 TcpAck -----------> 833 4) --------------------- TLS Session --------------------- 834 ClientHello -----------> 835 ServerHello 836 Certificate* 837 ServerKeyExchange* 838 <----------- ServerHelloDone 839 ClientKeyExchange 840 CertificateVerify* 841 [ChangeCipherSpec] 842 Finished -----------> 843 [ChangeCipherSpec] 844 <----------- Finished 845 5) ---------------------- Stream Prefix -------------------- 846 "IKETCP" ----------> 848 6) ----------------------- IKE Session --------------------- 849 INFORMATIONAL -----------> 850 HDR, SK { N(UPDATE_SA_ADDRESSES), 851 N(NAT_DETECTION_SOURCE_IP), 852 N(NAT_DETECTION_DESTINATION_IP) } 854 <----------- INFORMATIONAL 855 HDR, SK { N(NAT_DETECTION_SOURCE_IP), 856 N(NAT_DETECTION_DESTINATION_IP) } 857 7) <----------------- IKE/ESP data flow -------------------> 859 Figure 7 861 1. During the IKE_SA_INIT exchange, the client and server exchange 862 MOBIKE_SUPPORTED notify payloads to indicate support for 863 MOBIKE. 865 2. The client changes its point of attachment to the network, and 866 receives a new IP address. The client attempts to re-establish 867 the IKE session using the UPDATE_SA_ADDRESSES notify payload, 868 but the server does not respond because the network blocks UDP 869 traffic. 871 3. The client brings up a TCP connection to the server in order to 872 use TCP encapsulation. 874 4. The client initiates and TLS handshake with the server. 876 5. The client sends the Stream Prefix for TCP encapsulated IKE 877 traffic [Section 4]. 879 6. The client sends the UPDATE_SA_ADDRESSES notify payload on the 880 TCP encapsulated connection. 882 7. The IKE and ESP packet flow can resume. 884 Authors' Addresses 886 Tommy Pauly 887 Apple Inc. 888 1 Infinite Loop 889 Cupertino, California 95014 890 US 892 Email: tpauly@apple.com 893 Samy Touati 894 Ericsson 895 300 Holger Way 896 San Jose, California 95134 897 US 899 Email: samy.touati@ericsson.com 901 Ravi Mantha 902 Cisco Systems 903 SEZ, Embassy Tech Village 904 Panathur, Bangalore 560 037 905 India 907 Email: ramantha@cisco.com