Internet DRAFT - draft-nir-ipsecme-ike-tcp
draft-nir-ipsecme-ike-tcp
Network Working Group Y. Nir
Internet-Draft Check Point
Intended status: Standards Track July 16, 2012
Expires: January 17, 2013
A TCP transport for the Internet Key Exchange
draft-nir-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 packet loss makes them unreliable.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
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 January 17, 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
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Nir Expires January 17, 2013 [Page 1]
Internet-Draft IKE over TCP July 2012
1. Introduction
The Internet Key Exchange (IKE) specified in [RFC2407] and [RFC2408],
and IKEv2 as specified in [RFC5996] uses UDP to transport the
exchange messages. Some of those messages may be fairly large.
Specifically, the 5th and 6th messages of IKEv1 Main Mode, the first
and second messages of IKEv1 Aggressive Mode, and the messages of
IKEv2 IKE_AUTH exchange can become quite large, as they may contain a
chain of certificates, a signature payload (called "Auth" in IKEv2),
CRLs, and in the case of IKEv2, some configuration information that
is carried in the CFG payload.
When such UDP packets exceed the path MTU, they get fragmented. This
increases the probability of packets getting dropped, but the
retransmission mechanisms in IKE (as described in section 2.1 of RFC
5996) takes care of that. More recently we have seen a number of
service providers dropping fragmented packets. Firewalls and NAT
devices need to keep state for each packet where some but not all of
the fragments have been received. This creates a burden in terms of
memory, especially for high capacity devices such as Carrier-Grade
NAT (CGN) or high capacity firewalls.
The BEHAVE working group has an Internet Draft describing required
behavior of CGNs ([I-D.ietf-behave-lsn-requirements]). It requires
CGNs to comply with [RFC4787], which in section 11 requires NAT
devices to support fragments. However, some people deploying IKE
have found that some ISPs have begun to drop fragments in preparation
for deploying CGNs. While we all hope for a future where all devices
comply with the emerging standards, or even a future where CGNs are
not required, we have to make IKE work today.
The solution described in this document is to transport the IKE
messages over a TCP ([RFC0793]) rather than over UDP. IKE packets
(both versions) describe their own length, so they are well-suited
for transport over a stream-based connection such as TCP. The
Initiator opens a TCP connection to the Responder's port 500, sends
the requests and receives the responses, and then closes the
connection. TCP can handle arbitrary-length messages, works well
with any sized data, and is well supported by all ISP infrastructure.
1.1. Non-Goals of this Specification
Firewall traversal is not a goal of this specification. If a
firewall has a policy to block IKE and/or IPsec, hiding the IKE
exchange in TCP is not expected to help. Some implementations hide
both IKE and IPsec in a TCP connection, usually pretending to be
HTTPS by using port 443. This has a significant impact on bandwidth
and gateway capacity, and even this is defeated by better firewalls.
Nir Expires January 17, 2013 [Page 2]
Internet-Draft IKE over TCP July 2012
SSL VPNs tunnel IP packets over TLS, but the latest firewalls are
also TLS proxies, and are able to defeat this as well.
This document is not part of that arms race. It is only meant to
allow IKE to work When faced with broken infrastructure that drops
large IP packets.
1.2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. The Protocol
2.1. Initiator
An Initiator MAY try IKE using TCP for any request. It opens a TCP
connection from an arbitrary port to port 500 of the Responder. When
the three-way handshake completes, the Initiator MUST send the
request. If the Initiator knows that this request is the last
request needed at this time, it SHOULD half-close the TCP connection,
although it MAY wait until the last response is 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.
It 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.
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 had
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.
The responder MUST accept different requests on different transports.
Specifically, the Responder MUST NOT rely on subsequent requests
coming over the same transport. For example, it is entirely
acceptable to have the first two requests on IKE Main Mode come over
UDP port 500, while the last request comes over TCP, and the
Nir Expires January 17, 2013 [Page 3]
Internet-Draft IKE over TCP July 2012
following Quick Mode request might come over UDP port 4500 (because
NAT has been detected).
A responder that 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.
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.
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
The IKE header is copied from RFC 5996 below for reference:
Nir Expires January 17, 2013 [Page 4]
Internet-Draft IKE over TCP July 2012
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IKE SA Initiator's SPI |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IKE SA Responder's SPI |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload | MjVer | MnVer | Exchange Type | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: IKE Header Format
The receiver MUST first read in the 28 bytes that make up the IKE
header. The Responder then subtracts 28 from the length field, and
reads the resulting number of bytes. The combined message, comprised
on 28 header bytes and whatever number of payload bytes is processed
the same way as regular UDP messages. That includes retransmission
detection, with one slight difference: if a retransmitted request is
detected, the response is retransmitted as well, but using the
current TCP connection rather than whatever other transport had been
used for the original transmission of the request.
2.5. IKE_TCP_SUPPORTED Notification
This notification is sent by a responder over non-TCP transports to
inform the initiator that this specification is supported.
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Protocol ID (1 octet) MUST be 0.
o SPI Size (1 octet) MUST be zero, in conformance with section 3.10
of [RFC5996].
Nir Expires January 17, 2013 [Page 5]
Internet-Draft IKE over TCP July 2012
o IKE_TCP_SUPPORTED Notify Message Type (2 octets) - MUST be xxxxx,
the value assigned for IKE_TCP_SUPPORTED. TBA by IANA.
3. Operational Considerations
Most IKE messages are relatively short. Quick Mode in IKEv1, and all
but the IKE_AUTH exchange in IKEv2 are comprised of short messages
that fit in a single packet on most networks. It is only the
IKE_AUTH exchange in IKEv2, and the two last messages of Main Mode
that are long. UDP has advantages in lower latency and lower
resource consumption, so it makes sense to use UDP whenever TCP is
not required.
The requirements in Section 2.2 mean that different requests may be
sent over different transports. So the initiator can choose the
transport on a per-request basis. So one obvious policy would be to
do everything over UDP except the specific requests that tend to
become too big. This way the first messages use UDP, and the
Initiator can set up the TCP connection at the same time, eliminating
the latency penalty of using TCP. This may not always be the most
efficient policy, though. It means that the first messages sent over
TCP are relatively large ones, and TCP slow start may cause an extra
roundtrip, because the message may exceed the transmission window.
An initiator using this policy MUST NOT go to TCP if the responder
has not indicated support by sending the IKE_TCP_SUPPORTED
notification (Section 2.5) in the Initial response.
An alternative method, that is probably easier for the Initiator to
implement, is to do an entire "mission" using the same transport. So
if TCP is needed and an IKE SA has not yet been created, the
Initiator will open a TCP connection, and perform all 2-4 requests
needed to set up a child SA over the same connection.
Yet another policy would be to begin by using UDP, and at the same
time set up the TCP connection. If at any point the TCP handshake
completes, the next requests go over that connection. This method
can be used to auto-discover support of TCP on the responder. This
is easier for the user than configuring which peers support TCP, but
has the potential of wasting resources, as TCP connections may finish
the three-way handshake just when IKE over UDP has finished. The
requirements from the responder ensure that all these policies will
work.
3.1. Liveness Check
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
Nir Expires January 17, 2013 [Page 6]
Internet-Draft IKE over TCP July 2012
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.
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.
5. IANA Considerations
IANA is requested to assign a notify message type from the status
types range (16418-40959) of the "IKEv2 Notify Message Types"
registry with name "IKE_TCP_SUPPORTED"
No IANA action is required for the TCP port, as TCP port 500 is
already allocated to "ISAKMP".
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2407] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC2408] Maughan, D., Schneider, M., and M. Schertler, "Internet
Security Association and Key Management Protocol
(ISAKMP)", RFC 2408, November 1998.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, September 2010.
Nir Expires January 17, 2013 [Page 7]
Internet-Draft IKE over TCP July 2012
6.2. Informative References
[I-D.ietf-behave-lsn-requirements]
Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A.,
and H. Ashida, "Common requirements for Carrier Grade NATs
(CGNs)", draft-ietf-behave-lsn-requirements-08 (work in
progress), July 2012.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007.
Author's Address
Yoav Nir
Check Point Software Technologies Ltd.
5 Hasolelim st.
Tel Aviv 67897
Israel
Email: ynir@checkpoint.com
Nir Expires January 17, 2013 [Page 8]
