draft-ietf-ipsecme-ike-tcp-00.txt   draft-ietf-ipsecme-ike-tcp-01.txt 
Network Working Group Y. Nir Network Working Group Y. Nir
Internet-Draft Check Point Internet-Draft Check Point
Intended status: Standards Track August 28, 2012 Intended status: Standards Track December 4, 2012
Expires: March 1, 2013 Expires: June 7, 2013
A TCP transport for the Internet Key Exchange A TCP transport for the Internet Key Exchange
draft-ietf-ipsecme-ike-tcp-00 draft-ietf-ipsecme-ike-tcp-01
Abstract Abstract
This document describes using TCP for IKE messages. This facilitates This document describes using TCP for IKE messages. This facilitates
the transport of large messages over paths where fragments are either the transport of large messages over paths where fragments are either
dropped, or where packet loss makes the use of large UDP packets dropped, or where packet loss makes the use of large UDP packets
unreliable. unreliable.
Status of this Memo Status of this Memo
skipping to change at page 1, line 33 skipping to change at page 1, line 33
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 35 skipping to change at page 3, line 35
it MAY wait until the last response has been received. When all it MAY wait until the last response has been received. When all
responses have been received, the Initiator MUST close the responses have been received, the Initiator MUST close the
connection. If the peer has closed the connection before all connection. If the peer has closed the connection before all
requests have been transmitted or responded to, the Initiator SHOULD requests have been transmitted or responded to, the Initiator SHOULD
either open a new TCP connection or transmit them over UDP again. either open a new TCP connection or transmit them over UDP again.
An initiator MUST accept responses sent over IKE within the same An initiator MUST accept responses sent over IKE within the same
connection, but MUST also accept responses over other transports, if connection, but MUST also accept responses over other transports, if
the request had been sent over them as well. 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 2.2. Responder
A Responder MAY accept TCP connections to port 500, and if it does, A Responder MAY accept TCP connections to port 500, and if it does,
it MUST accept IKE requests over this connection. Responses to it MUST accept IKE requests over this connection. Responses to
requests received over this connection MUST also go over this requests received over this connection MUST also go over this
connection. If the connection has closed before the Responder has connection. If the connection has closed before the Responder has
had a chance to respond, it MUST NOT respond over UDP, but MUST had a chance to respond, it MUST NOT respond over UDP, but MUST
instead wait for a retransmission over UDP or over another TCP instead wait for a retransmission over UDP or over another TCP
connection. connection.
skipping to change at page 4, line 15 skipping to change at page 4, line 26
A responder that is configured to support IKE over TCP and receives A responder that is configured to support IKE over TCP and receives
an IKEv2 Initial request over any other transport MUST send an an IKEv2 Initial request over any other transport MUST send an
IKE_TCP_SUPPORTED notification (Section 2.5) in the Initial response. IKE_TCP_SUPPORTED notification (Section 2.5) in the Initial response.
the responder MAY send this notification even if the Initial request the responder MAY send this notification even if the Initial request
was received over TCP. was received over TCP.
If the responder has some requests of its own to send, it MUST NOT 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 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 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 The normal flow of things is that the Initiator opens a connection
and closes its side first. The responder closes after sending the and closes its side first. The responder closes after sending the
last response where the initiator has already half-closed the last response where the initiator has already half-closed the
connection. If, however, a significant amount of time has passed, connection. If, however, a significant amount of time has passed,
and neither new requests arrive nor the connection is closed by the and neither new requests arrive nor the connection is closed by the
initiator, the Responder MAY close or even reset the connection. initiator, the Responder MAY close or even reset the connection.
This specification makes no recommendation as to how long such a This specification makes no recommendation as to how long such a
timeout should be, but a few seconds should be enough. 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 2.3. Transmitter
The transmitter, whether an initiator transmitting a request or a The transmitter, whether an initiator transmitting a request or a
responder transmitting a response MUST NOT retransmit over the same responder transmitting a response MUST NOT retransmit over the same
connection. TCP takes care of that. It SHOULD send the IKE header connection. TCP takes care of that. It SHOULD send the IKE header
and the IKE payloads with a single command or in rapid succession, and the IKE payloads with a single command or in rapid succession,
because the receiver might block on reading from the socket. because the receiver might block on reading from the socket.
2.4. Receiver 2.4. Receiver
skipping to change at page 5, line 48 skipping to change at page 6, line 12
The Notify payload is formatted as follows: The Notify payload is formatted as follows:
1 2 3 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 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 ! ! Next Payload !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Protocol ID ! SPI Size !IKE_TCP_SUPPORTED Message Type ! ! Protocol ID ! SPI Size !IKE_TCP_SUPPORTED Message Type !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Protocol ID (1 octet) MUST be 0. o Protocol ID (1 octet) MUST be 0.
o SPI Size (1 octet) MUST be zero, in conformance with section 3.10 o SPI Size (1 octet) MUST be zero, in conformance with section 3.10
of RFC 5996. of RFC 5996.
o IKE_TCP_SUPPORTED Notify Message Type (2 octets) - MUST be xxxxx, o IKE_TCP_SUPPORTED Notify Message Type (2 octets) - MUST be xxxxx,
the value assigned for IKE_TCP_SUPPORTED. TBA by IANA. 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 3. Operational Considerations
Most IKE messages are relatively short. All but the IKE_AUTH Most IKE messages are relatively short. All but the IKE_AUTH
exchange in IKEv2 are comprised of short messages that fit in a exchange in IKEv2 are comprised of short messages that fit in a
single packet on most networks. The Informational exchange could be single packet on most networks. The Informational exchange could be
an exception, as it may contain arbitrary-length CFG payloads, but in 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 practice this is not done. It is only the IKE_AUTH exchange that has
long messages. UDP has advantages in lower latency and lower long messages. UDP has advantages in lower latency and lower
resource consumption, so it makes sense to use UDP whenever TCP is resource consumption, so it makes sense to use UDP whenever TCP is
skipping to change at page 7, line 16 skipping to change at page 7, line 30
The TCP connections described in this document are short-lived. We 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 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. 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 Because of this, they are not well-suited for the transport of short
requests such as those for liveness check. requests such as those for liveness check.
Although liveness checks MAY be sent over TCP, this is not Although liveness checks MAY be sent over TCP, this is not
recommended. 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 4. Security Considerations
Most of the security considerations for IKE over TCP are the same as Most of the security considerations for IKE over TCP are the same as
those for UDP as in RFC 5996. those for UDP as in RFC 5996.
For the Responder, listening to TCP port 500 involves all the risks For the Responder, listening to TCP port 500 involves all the risks
of maintaining any TCP server. Precautions against DoS attacks, such of maintaining any TCP server. Precautions against DoS attacks, such
as SYN cookies are RECOMMENDED. see [RFC4987] for details. as SYN cookies are RECOMMENDED. see [RFC4987] for details.
5. IANA Considerations 5. IANA Considerations
 End of changes. 10 change blocks. 
6 lines changed or deleted 58 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/