--- 1/draft-ietf-ipsecme-ike-tcp-00.txt 2012-12-04 00:17:47.497343780 +0100 +++ 2/draft-ietf-ipsecme-ike-tcp-01.txt 2012-12-04 00:17:47.513343620 +0100 @@ -1,18 +1,18 @@ Network Working Group Y. Nir Internet-Draft Check Point -Intended status: Standards Track August 28, 2012 -Expires: March 1, 2013 +Intended status: Standards Track December 4, 2012 +Expires: June 7, 2013 A TCP transport for the Internet Key Exchange - draft-ietf-ipsecme-ike-tcp-00 + draft-ietf-ipsecme-ike-tcp-01 Abstract This document describes using TCP for IKE messages. This facilitates the transport of large messages over paths where fragments are either dropped, or where packet loss makes the use of large UDP packets unreliable. Status of this Memo @@ -22,21 +22,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on March 1, 2013. + This Internet-Draft will expire on June 7, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -118,20 +118,31 @@ it MAY wait until the last response has been received. When all responses have been received, the Initiator MUST close the connection. If the peer has closed the connection before all requests have been transmitted or responded to, the Initiator SHOULD either open a new TCP connection or transmit them over UDP again. An initiator MUST accept responses sent over IKE within the same connection, but MUST also accept responses over other transports, if the request had been sent over them as well. + An initiator that is configured to respond to IKE over TCP on some + port, and is not prevented from receiving TCP connections by network + address translation (see Section 3.2), MUST send an IKE_TCP_SUPPORTED + notification (Section 2.5) in the Initial request. + + Note that stateless cookies may be dependent on some of the + parameters of the connection, so retransmitting the IKE_INITIAL + request with a stateless cookie over a different transport may cause + the cookie to be invalid. For this reason, retransmissions with a + cookie SHOULD be sent over the same transport. + 2.2. Responder A Responder MAY accept TCP connections to port 500, and if it does, it MUST accept IKE requests over this connection. Responses to requests received over this connection MUST also go over this connection. If the connection has closed before the Responder has had a chance to respond, it MUST NOT respond over UDP, but MUST instead wait for a retransmission over UDP or over another TCP connection. @@ -145,32 +156,41 @@ A responder that is configured to support IKE over TCP and receives an IKEv2 Initial request over any other transport MUST send an IKE_TCP_SUPPORTED notification (Section 2.5) in the Initial response. the responder MAY send this notification even if the Initial request was received over TCP. If the responder has some requests of its own to send, it MUST NOT use a connection that has been opened by a peer. Instead, it MUST either use UDP or else open a new TCP connection to the original - Initiator's TCP port 500. + Initiator's TCP port, specified in the IKE_TCP_SUPPORTED notification + in the Initial request. If the Initial request did not include this + notification, the original Responder MUST NOT initiate IKE over TCP + to the original Initiator. The normal flow of things is that the Initiator opens a connection and closes its side first. The responder closes after sending the last response where the initiator has already half-closed the connection. If, however, a significant amount of time has passed, and neither new requests arrive nor the connection is closed by the initiator, the Responder MAY close or even reset the connection. This specification makes no recommendation as to how long such a timeout should be, but a few seconds should be enough. + The stateless cookie mechanism in IKEv2 only assures that the + initiator is able to respond to the address and port of the request. + TCP already provides this with the three-way handshake. If the + IKE_INITIAL exchange is transmitted over TCP, the stateless cookie + mechanism SHOULD NOT be used. + 2.3. Transmitter The transmitter, whether an initiator transmitting a request or a responder transmitting a response MUST NOT retransmit over the same connection. TCP takes care of that. It SHOULD send the IKE header and the IKE payloads with a single command or in rapid succession, because the receiver might block on reading from the socket. 2.4. Receiver @@ -212,27 +232,33 @@ The Notify payload is formatted as follows: 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload !C! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Protocol ID ! SPI Size !IKE_TCP_SUPPORTED Message Type ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | TCP Port | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Protocol ID (1 octet) MUST be 0. o SPI Size (1 octet) MUST be zero, in conformance with section 3.10 of RFC 5996. - o IKE_TCP_SUPPORTED Notify Message Type (2 octets) - MUST be xxxxx, the value assigned for IKE_TCP_SUPPORTED. TBA by IANA. + o TCP port (2 octets) - The TCP port to which the recipient should + open TCP connections. This is not necessarily the same port that + the IKE gateway is listening to. See Section 3.2. If the sender + is not subject to network address translation, the port SHOULD be + 500. 3. Operational Considerations Most IKE messages are relatively short. All but the IKE_AUTH exchange in IKEv2 are comprised of short messages that fit in a single packet on most networks. The Informational exchange could be an exception, as it may contain arbitrary-length CFG payloads, but in practice this is not done. It is only the IKE_AUTH exchange that has long messages. UDP has advantages in lower latency and lower resource consumption, so it makes sense to use UDP whenever TCP is @@ -272,20 +298,46 @@ The TCP connections described in this document are short-lived. We do not expect them to stay for the lifetime of the SA, but to get torn down by either side within seconds of the SA being set up. Because of this, they are not well-suited for the transport of short requests such as those for liveness check. Although liveness checks MAY be sent over TCP, this is not recommended. + On the other hand, see Section 3.2 for when liveness check should be + used. + +3.2. Network Address Translation + + If the IKE gateway is subject to network address translation (NAT), + TCP ports may be translated, so that one port on the NAT device gets + translated to some other port on the gateway. In this case, the + gateway MUST advertise the NAT device port in the IKE_TCP_SUPPORTED + notification. + + In some cases, the NAT or some other box prevents incoming TCP + connections to the IKE peer behind it. In these cases, the IKE peer + MUST NOT advertise support using the IKE_TCP_SUPPORTED notification. + + When IKE peers detect the presence of a NAT device during the IKE + exchange, they typically switch to working over UDP port 4500. + Sending the IKE_AUTH messages over this UDP port creates a port + mapping entry on the NAT device, and this mapping can then be used + for bidirectional traffic between the peers. When using IKE over + TCP, this mapping is not created, so traffic can only flow from the + initiator to the responder. To make a bidirectional mapping, it is + RECOMMENDED that when NAT is detected, initiators initiate a liveness + check using UDP 4500 to the responders immediately following the + successful IKE_AUTH exchange. + 4. Security Considerations Most of the security considerations for IKE over TCP are the same as those for UDP as in RFC 5996. For the Responder, listening to TCP port 500 involves all the risks of maintaining any TCP server. Precautions against DoS attacks, such as SYN cookies are RECOMMENDED. see [RFC4987] for details. 5. IANA Considerations