idnits 2.17.1 draft-ietf-ipsecme-tcp-encaps-05.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 (January 23, 2017) is 2643 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 935, but not defined == Missing Reference: 'Figure 2' is mentioned on line 492, but not defined == Missing Reference: 'ChangeCipherSpec' is mentioned on line 899, but not defined == Missing Reference: 'CERTREQ' is mentioned on line 741, but not defined == Missing Reference: 'CERT' is mentioned on line 746, but not defined == Missing Reference: 'CP' is mentioned on line 790, 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: July 27, 2017 Ericsson 6 R. Mantha 7 Cisco Systems 8 January 23, 2017 10 TCP Encapsulation of IKE and IPsec Packets 11 draft-ietf-ipsecme-tcp-encaps-05 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 July 27, 2017. 40 Copyright Notice 42 Copyright (c) 2017 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 . . . . . . . . . . . . . 10 70 9. Using IKE Message Fragmentation with TCP encapsulation . . . 10 71 10. Considerations for Keep-alives and DPD . . . . . . . . . . . 11 72 11. Middlebox Considerations . . . . . . . . . . . . . . . . . . 11 73 12. Performance Considerations . . . . . . . . . . . . . . . . . 11 74 12.1. TCP-in-TCP . . . . . . . . . . . . . . . . . . . . . . . 12 75 12.2. Added Reliability for Unreliable Protocols . . . . . . . 12 76 12.3. Quality of Service Markings . . . . . . . . . . . . . . 12 77 12.4. Maximum Segment Size . . . . . . . . . . . . . . . . . . 12 78 13. Security Considerations . . . . . . . . . . . . . . . . . . . 12 79 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 80 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 81 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 16.1. Normative References . . . . . . . . . . . . . . . . . . 13 83 16.2. Informative References . . . . . . . . . . . . . . . . . 14 84 Appendix A. Using TCP encapsulation with TLS . . . . . . . . . . 15 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 . . . . . 19 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. The responder MUST 354 wait for the entire stream prefix to be received on the stream before 355 trying to parse out any IKE or ESP messages. The stream prefix is 356 sent only once, and only by the initiator. 358 In order to close an IKE session, either the initiator or responder 359 SHOULD gracefully tear down IKE SAs with DELETE payloads. Once all 360 SAs have been deleted, the initiator of the original connection 361 SHOULD close the TCP connection if it does not intend to use the 362 connection for another IKE session to the responder. If the 363 connection is left idle, and the responder needs to clean up 364 resources, the responder MAY close the TCP connection. 366 An unexpected FIN or a RST on the TCP connection may indicate either 367 a loss of connectivity, an attack, or some other error. If a DELETE 368 payload has not been sent, both sides SHOULD maintain the state for 369 their SAs for the standard lifetime or time-out period. The original 370 initiator (that is, the endpoint that initiated the TCP connection 371 and sent the first IKE_SA_INIT message) is responsible for re- 372 establishing the TCP connection if it is torn down for any unexpected 373 reason. Since new TCP connections may use different ports due to NAT 374 mappings or local port allocations changing, the responder MUST allow 375 packets for existing SAs to be received from new source ports. 377 A peer MUST discard a partially received message due to a broken 378 connection. 380 Whenever the initiator opens a new TCP connection to be used for an 381 existing IKE SA, it MUST send the stream prefix first, before any IKE 382 or ESP messages. This follows the same behavior as the initial TCP 383 connection. 385 If the connection is being used to resume a previous IKE session, the 386 responder can recognize the session using either the IKE SPI from an 387 encapsulated IKE message or the ESP SPI from an encapsulated ESP 388 message. If the session had been fully established previously, it is 389 suggested that the initiator send an UPDATE_SA_ADDRESSES message if 390 MOBIKE is supported, or an INFORMATIONAL message (a keepalive) 391 otherwise. If either initiator or responder receives a stream that 392 cannot be parsed correctly (initiator stream missing the stream 393 prefix, or message frames not parsable as IKE or ESP messages), it 394 MUST close the TCP connection. If there is instead a syntax issue 395 within an IKE message, an implementation MUST send the INVALID_SYNTAX 396 notify payload and tear down the IKE session as ususal, rather than 397 tearing down the TCP connection directly. 399 An initiator SHOULD only open one TCP connection per IKE SA, over 400 which it sends all of the corresponding IKE and ESP messages. This 401 helps ensure that any firewall or NAT mappings allocated for the TCP 402 connection apply to all of the traffic associated with the IKE SA 403 equally. 405 A responder SHOULD at any given time send packets for an IKE SA and 406 its Child SAs over only one TCP connection. It SHOULD choose the TCP 407 connection on which it last received a valid and decryptable IKE or 408 ESP message. In order to be considered valid for choosing a TCP 409 connection, an IKE message successfully decrypt and be authenticated, 410 not be a retransmission of a previously received message, and be 411 within the expected window for IKE message IDs. Similarly, an ESP 412 message must pass authentication checks and be decrypted, not be a 413 replay of a previous message. 415 Since a connection may be broken and a new connection re-established 416 by the initiator without the responder being aware, a responder 417 SHOULD accept receiving IKE and ESP messages on both old and new 418 connections until the old connection is closed by the initiator. A 419 responder MAY close a TCP connection that it perceives as idle and 420 extraneous (one previously used for IKE and ESP messages that has 421 been replaced by a new connection). 423 Multiple IKE SAs MUST NOT share a single TCP connection. 425 7. Interaction with NAT Detection Payloads 427 When negotiating over UDP port 500, IKE_SA_INIT packets include 428 NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP payloads to 429 determine if UDP encapsulation of IPsec packets should be used. 430 These payloads contain SHA-1 digests of the SPIs, IP addresses, and 431 ports. IKE_SA_INIT packets sent on a TCP connection SHOULD include 432 these payloads, and SHOULD use the applicable TCP ports when creating 433 and checking the SHA-1 digests. 435 If a NAT is detected due to the SHA-1 digests not matching the 436 expected values, no change should be made for encapsulation of 437 subsequent IKE or ESP packets, since TCP encapsulation inherently 438 supports NAT traversal. Implementations MAY use the information that 439 a NAT is present to influence keep-alive timer values. 441 If a NAT is detected, implementations need to handle transport mode 442 TCP and UDP packet checksum fixup as defined for UDP encapsulation 443 [RFC3948]. 445 8. Using MOBIKE with TCP encapsulation 447 When an IKE session that has negotiated MOBIKE [RFC4555] is 448 transitioning between networks, the initiator of the transition may 449 switch between using TCP encapsulation, UDP encapsulation, or no 450 encapsulation. Implementations that implement both MOBIKE and TCP 451 encapsulation MUST support dynamically enabling and disabling TCP 452 encapsulation as interfaces change. 454 When a MOBIKE-enabled initiator changes networks, the 455 UPDATE_SA_ADDRESSES notification SHOULD be sent out first over UDP 456 before attempting over TCP. If there is a response to the 457 UPDATE_SA_ADDRESSES notification sent over UDP, then the ESP packets 458 should be sent directly over IP or over UDP port 4500 (depending on 459 if a NAT was detected), regardless of if a connection on a previous 460 network was using TCP encapsulation. Similarly, if the responder 461 only responds to the UPDATE_SA_ADDRESSES notification over TCP, then 462 the ESP packets should be sent over the TCP connection, regardless of 463 if a connection on a previous network did not use TCP encapsulation. 465 9. Using IKE Message Fragmentation with TCP encapsulation 467 IKE Message Fragmentation [RFC7383] is not required when using TCP 468 encapsulation, since a TCP stream already handles the fragmentation 469 of its contents across packets. Since fragmentation is redundant in 470 this case, implementations might choose to not negotiate IKE 471 fragmentation. Even if fragmentation is negotiated, an 472 implementation SHOULD NOT send fragments when going over a TCP 473 connection, although it MUST support receiving fragements. 475 If an implementation supports both MOBIKE and IKE fragmentation, it 476 SHOULD negotiate IKE fragmentation over a TCP encapsulated session in 477 case the session switches to UDP encapsulation on another network. 479 10. Considerations for Keep-alives and DPD 481 Encapsulating IKE and IPsec inside of a TCP connection can impact the 482 strategy that implementations use to detect peer liveness and to 483 maintain middlebox port mappings. Peer liveness should be checked 484 using IKE Informational packets [RFC7296]. 486 In general, TCP port mappings are maintained by NATs longers than UDP 487 port mappings, so IPsec ESP NAT keep-alives [RFC3948] SHOULD NOT be 488 sent when using TCP encapsulation. Any implementation using TCP 489 encapsulation MUST silently drop incoming NAT keep-alive packets, and 490 not treat them as errors. NAT keep-alive packets over a TCP 491 encapsulated IPsec connection will be sent with a length value of 1 492 byte, whose value is 0xFF [Figure 2]. 494 Note that depending on the configuration of TCP and TLS on the 495 connection, TCP keep-alives [RFC1122] and TLS keep-alives [RFC6520] 496 may be used. These MUST NOT be used as indications of IKE peer 497 liveness. 499 11. Middlebox Considerations 501 Many security networking devices such as Firewalls or Intrusion 502 Prevention Systems, network optimization/acceleration devices and 503 Network Address Translation (NAT) devices keep the state of sessions 504 that traverse through them. 506 These devices commonly track the transport layer and/or the 507 application layer data to drop traffic that is anomalous or malicious 508 in nature. 510 A network device that monitors up to the application layer will 511 commonly expect to see HTTP traffic within a TCP socket running over 512 port 80, if non-HTTP traffic is seen (such as TCP encapsulated IKE), 513 this could be dropped by the security device. 515 A network device that monitors the transport layer will track the 516 state of TCP sessions, such as TCP sequence numbers. TCP 517 encapsulation of IKE should therefore use standard TCP behaviors to 518 avoid being dropped by middleboxes. 520 12. Performance Considerations 522 Several aspects of TCP encapsulation for IKE and IPsec packets may 523 negatively impact the performance of connections within the tunnel. 524 Implementations should be aware of these and take these into 525 consideration when determining when to use TCP encapsulation. 527 12.1. TCP-in-TCP 529 If the outer connection between IKE peers is over TCP, inner TCP 530 connections may suffer effects from using TCP within TCP. In 531 particular, the inner TCP's round-trip-time estimation will be 532 affected by the burstiness of the outer TCP. This will make loss- 533 recovery of the inner TCP traffic less reactive and more prone to 534 spurious retransmission timeouts. 536 12.2. Added Reliability for Unreliable Protocols 538 Since ESP is an unreliable protocol, transmitting ESP packets over a 539 TCP connection will change the fundamental behavior of the packets. 540 Some application-level protocols that prefer packet loss to delay 541 (such as Voice over IP or other real-time protocols) may be 542 negatively impacted if their packets are retransmitted by the TCP 543 connection due to packet loss. 545 12.3. Quality of Service Markings 547 Quality of Service (QoS) markings, such as DSCP and Traffic Class, 548 should be used with care on TCP connections used for encapsulation. 549 Individual packets SHOULD NOT use different markings than the rest of 550 the connection, since packets with different priorities may be routed 551 differently and cause unnecessary delays in the connection. 553 12.4. Maximum Segment Size 555 A TCP connection used for IKE encapsulation SHOULD negotiate its 556 maximum segment size (MSS) in order to avoid unnecessary 557 fragmentation of packets. 559 13. Security Considerations 561 IKE responders that support TCP encapsulation may become vulnerable 562 to new Denial-of-Service (DoS) attacks that are specific to TCP, such 563 as SYN-flooding attacks. Responders should be aware of this 564 additional attack-surface. 566 Responders should be careful to ensure that the stream prefix 567 "IKETCP" uniquely identifies streams using the TCP encapsulation 568 protocol. The prefix was chosen to not overlap with the start of any 569 known valid protocol over TCP, but implementations should make sure 570 to validate this assumption in order to avoid unexpected processing 571 of TCP connections. 573 Attackers may be able to disrupt the TCP connection by sending 574 spurious RST packets. Due to this, implementations SHOULD make sure 575 that IKE session state persists even if the underlying TCP connection 576 is torn down. 578 If MOBIKE is being used, all of the security considerations outlined 579 for MOBIKE apply [[RFC4555]]. 581 Similarly to MOBIKE, TCP encapsulation requires a responder to handle 582 changing of source address and port due to network or connection 583 disruption. The successful delivery of valid IKE or ESP messages 584 over a new TCP connection is used by the responder to determine where 585 to send subsequent responses. If an attacker is able to send packets 586 on a new TCP connection that pass the validation checks of the 587 responder, it can influence which path future packets take. For this 588 reason, the validation of messages on the responder must include 589 decryption, authentication, and replay checks. 591 14. IANA Considerations 593 This memo includes no request to IANA. 595 TCP port 4500 is already allocated to IPsec. This port MAY be used 596 for the protocol described in this document, but implementations MAY 597 prefer to use other ports based on local policy. 599 15. Acknowledgments 601 The authors would like to acknowledge the input and advice of Stuart 602 Cheshire, Delziel Fernandes, Yoav Nir, Christoph Paasch, Yaron 603 Sheffer, David Schinazi, Graham Bartlett, Byju Pularikkal, March Wu, 604 Kingwel Xie, Valery Smyslov, Jun Hu, and Tero Kivinen. Special 605 thanks to Eric Kinnear for his implementation work. 607 16. References 609 16.1. Normative References 611 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 612 Requirement Levels", BCP 14, RFC 2119, 613 DOI 10.17487/RFC2119, March 1997, 614 . 616 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 617 Kivinen, "Internet Key Exchange Protocol Version 2 618 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 619 2014, . 621 16.2. Informative References 623 [I-D.nir-ipsecme-ike-tcp] 624 Nir, Y., "A TCP transport for the Internet Key Exchange", 625 draft-nir-ipsecme-ike-tcp-01 (work in progress), July 626 2012. 628 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 629 Communication Layers", STD 3, RFC 1122, 630 DOI 10.17487/RFC1122, October 1989, 631 . 633 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within 634 HTTP/1.1", RFC 2817, DOI 10.17487/RFC2817, May 2000, 635 . 637 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 638 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 639 RFC 3948, DOI 10.17487/RFC3948, January 2005, 640 . 642 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 643 RFC 4303, DOI 10.17487/RFC4303, December 2005, 644 . 646 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 647 (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, 648 . 650 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 651 (TLS) Protocol Version 1.2", RFC 5246, 652 DOI 10.17487/RFC5246, August 2008, 653 . 655 [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport 656 Layer Security (TLS) and Datagram Transport Layer Security 657 (DTLS) Heartbeat Extension", RFC 6520, 658 DOI 10.17487/RFC6520, February 2012, 659 . 661 [RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 662 (IKEv2) Message Fragmentation", RFC 7383, 663 DOI 10.17487/RFC7383, November 2014, 664 . 666 Appendix A. Using TCP encapsulation with TLS 668 This section provides recommendations on the support of TLS with the 669 TCP encapsulation. 671 When using TCP encapsulation, implementations may choose to use TLS 672 [RFC5246], to be able to traverse middle-boxes, which may block non 673 HTTP traffic. 675 If a web proxy is applied to the ports for the TCP connection, and 676 TLS is being used, the initiator can send an HTTP CONNECT message to 677 establish a tunnel through the proxy [RFC2817]. 679 The use of TLS should be configurable on the peers. The responder 680 may expect to read encapsulated IKE and ESP packets directly from the 681 TCP connection, or it may expect to read them from a stream of TLS 682 data packets. The initiator should be pre-configured to use TLS or 683 not when communicating with a given port on the responder. 685 When new TCP connections are re-established due to a broken 686 connection, TLS must be re-negotiated. TLS Session Resumption is 687 recommended to improve efficiency in this case. 689 The security of the IKE session is entirely derived from the IKE 690 negotiation and key establishment and not from the TLS session (which 691 in this context is only used for encapsulation purposes), therefore 692 when TLS is used on the TCP connection, both the initiator and 693 responder SHOULD allow the NULL cipher to be selected for performance 694 reasons. 696 Implementations should be aware that the use of TLS introduces 697 another layer of overhead requiring more bytes to transmit a given 698 IKE and IPsec packet. For this reason, direct ESP, UDP 699 encapsulation, or TCP encapsulation without TLS should be preferred 700 in situations in which TLS is not required in order to traverse 701 middle-boxes. 703 Appendix B. Example exchanges of TCP Encapsulation with TLS 705 B.1. Establishing an IKE session 707 Client Server 708 ---------- ---------- 709 1) -------------------- TCP Connection ------------------- 710 (IP_I:Port_I -> IP_R:TCP443 or TCP4500) 711 TcpSyn ----------> 712 <---------- TcpSyn,Ack 713 TcpAck ----------> 715 2) --------------------- TLS Session --------------------- 716 ClientHello ----------> 717 ServerHello 718 Certificate* 719 ServerKeyExchange* 720 <---------- ServerHelloDone 721 ClientKeyExchange 722 CertificateVerify* 723 [ChangeCipherSpec] 724 Finished ----------> 725 [ChangeCipherSpec] 726 <---------- Finished 728 3) ---------------------- Stream Prefix -------------------- 729 "IKETCP" ----------> 730 4) ----------------------- IKE Session --------------------- 731 Length + Non-ESP Marker ----------> 732 IKE_SA_INIT 733 HDR, SAi1, KEi, Ni, 734 [N(NAT_DETECTION_*_IP)] 735 <------ Length + Non-ESP Marker 736 IKE_SA_INIT 737 HDR, SAr1, KEr, Nr, 738 [N(NAT_DETECTION_*_IP)] 739 Length + Non-ESP Marker ----------> 740 first IKE_AUTH 741 HDR, SK {IDi, [CERTREQ] 742 CP(CFG_REQUEST), IDr, 743 SAi2, TSi, TSr, ...} 744 <------ Length + Non-ESP Marker 745 first IKE_AUTH 746 HDR, SK {IDr, [CERT], AUTH, 747 EAP, SAr2, TSi, TSr} 748 Length + Non-ESP Marker ----------> 749 IKE_AUTH + EAP 750 repeat 1..N times 751 <------ Length + Non-ESP Marker 752 IKE_AUTH + EAP 753 Length + Non-ESP Marker ----------> 754 final IKE_AUTH 755 HDR, SK {AUTH} 756 <------ Length + Non-ESP Marker 757 final IKE_AUTH 758 HDR, SK {AUTH, CP(CFG_REPLY), 759 SA, TSi, TSr, ...} 760 ----------------- IKE Tunnel Established ---------------- 761 Length + ESP frame ----------> 762 Figure 4 764 1. Client establishes a TCP connection with the server on port 443 765 or 4500. 767 2. Client initiates TLS handshake. During TLS handshake, the 768 server SHOULD NOT request the client's' certificate, since 769 authentication is handled as part of IKE negotiation. 771 3. Client send the Stream Prefix for TCP encapsulated IKE 772 [Section 4] traffic to signal the beginning of IKE negotation. 774 4. Client and server establish an IKE connection. This example 775 shows EAP-based authentication, although any authentication 776 type may be used. 778 B.2. Deleting an IKE session 780 Client Server 781 ---------- ---------- 782 1) ----------------------- IKE Session --------------------- 783 Length + Non-ESP Marker ----------> 784 INFORMATIONAL 785 HDR, SK {[N,] [D,] 786 [CP,] ...} 787 <------ Length + Non-ESP Marker 788 INFORMATIONAL 789 HDR, SK {[N,] [D,] 790 [CP], ...} 792 2) --------------------- TLS Session --------------------- 793 close_notify ----------> 794 <---------- close_notify 795 3) -------------------- TCP Connection ------------------- 796 TcpFin ----------> 797 <---------- Ack 798 <---------- TcpFin 799 Ack ----------> 800 --------------------- Tunnel Deleted ------------------- 802 Figure 5 804 1. Client and server exchange INFORMATIONAL messages to notify IKE 805 SA deletion. 807 2. Client and server negotiate TLS session deletion using TLS 808 CLOSE_NOTIFY. 810 3. The TCP connection is torn down. 812 The deletion of the IKE SA should lead to the disposal of the 813 underlying TLS and TCP state. 815 B.3. Re-establishing an IKE session 817 Client Server 818 ---------- ---------- 819 1) -------------------- TCP Connection ------------------- 820 (IP_I:Port_I -> IP_R:TCP443 or TCP4500) 821 TcpSyn ----------> 822 <---------- TcpSyn,Ack 823 TcpAck ----------> 824 2) --------------------- TLS Session --------------------- 825 ClientHello ----------> 826 <---------- ServerHello 827 [ChangeCipherSpec] 828 Finished 829 [ChangeCipherSpec] ----------> 830 Finished 831 3) ---------------------- Stream Prefix -------------------- 832 "IKETCP" ----------> 833 4) <---------------------> IKE/ESP flow <------------------> 834 Length + ESP frame ----------> 836 Figure 6 838 1. If a previous TCP connection was broken (for example, due to a 839 RST), the client is responsible for re-initiating the TCP 840 connection. The initiator's address and port (IP_I and Port_I) 841 may be different from the previous connection's address and 842 port. 844 2. In ClientHello TLS message, the client SHOULD send the Session 845 ID it received in the previous TLS handshake if available. It 846 is up to the server to perform either an abbreviated handshake 847 or full handshake based on the session ID match. 849 3. After TCP and TLS are complete, the client sends the Stream 850 Prefix for TCP encapsulated IKE traffic [Section 4]. 852 4. The IKE and ESP packet flow can resume. If MOBIKE is being 853 used, the initiator SHOULD send UPDATE_SA_ADDRESSES. 855 B.4. Using MOBIKE between UDP and TCP Encapsulation 857 Client Server 858 ---------- ---------- 859 (IP_I1:UDP500 -> IP_R:UDP500) 860 1) ----------------- IKE_SA_INIT Exchange ----------------- 861 (IP_I1:UDP4500 -> IP_R:UDP4500) 862 Non-ESP Marker -----------> 863 Intial IKE_AUTH 864 HDR, SK { IDi, CERT, AUTH, 865 CP(CFG_REQUEST), 866 SAi2, TSi, TSr, 867 N(MOBIKE_SUPPORTED) } 868 <----------- Non-ESP Marker 869 Initial IKE_AUTH 870 HDR, SK { IDr, CERT, AUTH, 871 EAP, SAr2, TSi, TSr, 872 N(MOBIKE_SUPPORTED) } 873 <---------------- IKE tunnel establishment -------------> 875 2) ------------ MOBIKE Attempt on new network -------------- 876 (IP_I2:UDP4500 -> IP_R:UDP4500) 877 Non-ESP Marker -----------> 878 INFORMATIONAL 879 HDR, SK { N(UPDATE_SA_ADDRESSES), 880 N(NAT_DETECTION_SOURCE_IP), 881 N(NAT_DETECTION_DESTINATION_IP) } 883 3) -------------------- TCP Connection ------------------- 884 (IP_I2:PORT_I -> IP_R:TCP443 or TCP4500) 885 TcpSyn -----------> 886 <----------- TcpSyn,Ack 887 TcpAck -----------> 889 4) --------------------- TLS Session --------------------- 890 ClientHello -----------> 891 ServerHello 892 Certificate* 893 ServerKeyExchange* 894 <----------- ServerHelloDone 895 ClientKeyExchange 896 CertificateVerify* 897 [ChangeCipherSpec] 898 Finished -----------> 899 [ChangeCipherSpec] 900 <----------- Finished 902 5) ---------------------- Stream Prefix -------------------- 903 "IKETCP" ----------> 905 6) ----------------------- IKE Session --------------------- 906 Length + Non-ESP Marker -----------> 907 INFORMATIONAL (Same as step 2) 908 HDR, SK { N(UPDATE_SA_ADDRESSES), 909 N(NAT_DETECTION_SOURCE_IP), 910 N(NAT_DETECTION_DESTINATION_IP) } 912 <------- Length + Non-ESP Marker 913 HDR, SK { N(NAT_DETECTION_SOURCE_IP), 914 N(NAT_DETECTION_DESTINATION_IP) } 915 7) <----------------- IKE/ESP data flow -------------------> 917 Figure 7 919 1. During the IKE_SA_INIT exchange, the client and server exchange 920 MOBIKE_SUPPORTED notify payloads to indicate support for 921 MOBIKE. 923 2. The client changes its point of attachment to the network, and 924 receives a new IP address. The client attempts to re-establish 925 the IKE session using the UPDATE_SA_ADDRESSES notify payload, 926 but the server does not respond because the network blocks UDP 927 traffic. 929 3. The client brings up a TCP connection to the server in order to 930 use TCP encapsulation. 932 4. The client initiates and TLS handshake with the server. 934 5. The client sends the Stream Prefix for TCP encapsulated IKE 935 traffic [Section 4]. 937 6. The client sends the UPDATE_SA_ADDRESSES notify payload on the 938 TCP encapsulated connection. Note that this IKE message is the 939 same as the one sent over UDP in step 2, and should have the 940 same message ID and contents. 942 7. The IKE and ESP packet flow can resume. 944 Authors' Addresses 945 Tommy Pauly 946 Apple Inc. 947 1 Infinite Loop 948 Cupertino, California 95014 949 US 951 Email: tpauly@apple.com 953 Samy Touati 954 Ericsson 955 300 Holger Way 956 San Jose, California 95134 957 US 959 Email: samy.touati@ericsson.com 961 Ravi Mantha 962 Cisco Systems 963 SEZ, Embassy Tech Village 964 Panathur, Bangalore 560 037 965 India 967 Email: ramantha@cisco.com