One document matched: draft-nir-ipsecme-ike-tcp-00.xml
<?xml version="1.0"?>
<?xml-stylesheet type='text/xsl' href='./rfc2629.xslt' ?>
<?rfc toc="no"?>
<?rfc symrefs="no"?>
<?rfc compact="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc strict="yes" ?>
<?rfc linkmailto="yes" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" >
<?xml-stylesheet type='text/xsl' href='./rfc2629.xslt' ?>
<?rfc toc="no"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="yes" ?>
<?rfc sortrefs="yes" ?>
<rfc ipr="trust200902" docName="draft-nir-ipsecme-ike-tcp-00" category="std">
<front>
<title abbrev="IKE over TCP">A TCP transport for the Internet Key Exchange</title>
<author initials="Y." surname="Nir" fullname="Yoav Nir">
<organization abbrev="Check Point">Check Point Software Technologies Ltd.</organization>
<address>
<postal>
<street>5 Hasolelim st.</street>
<city>Tel Aviv</city>
<code>67897</code>
<country>Israel</country>
</postal>
<email>ynir@checkpoint.com</email>
</address>
</author>
<date year="2012"/>
<area>Security Area</area>
<keyword>Internet-Draft</keyword>
<abstract>
<t> This document describes using TCP for IKE messages. This facilitates the transport of
large messages over paths where fragments are dropped.</t>
</abstract>
</front>
<middle>
<!-- ====================================================================== -->
<section anchor="introduction" title="Introduction">
<t> The Internet Key Exchange (IKE) specified in <xref target="RFC2407" /> and
<xref target="RFC2408" />, and IKEv2 as specified in <xref target="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.</t>
<t> 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.</t>
<t> The BEHAVE working group has an Internet Draft describing required behavior of CGNs
(<xref target="CGN-reqs"/>). It requires CGNs to comply with <xref target="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, and where CGNs are not required, we have to make IKE work today.</t>
<t> The solution described in this document is to transport the IKE messages over a TCP
(<xref target="RFC793"/>) 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.</t>
<section anchor="nongoals" title="Non-Goals of this Specification">
<t> 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. SSL VPNs tunnel IP packets over TLS, but
the latest firewalls are also TLS proxies, and are able to defeat this as well.</t>
<t> 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.</t>
</section>
<section anchor="mustshouldmay" title="Conventions Used in This Document">
<t>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 <xref target="RFC2119"/>.</t>
</section>
</section>
<section anchor="proto" title="The Protocol">
<section anchor="init" title="Initiator">
<t> An Initiator MAY try IKE using TCP. 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.</t>
<t> 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.</t>
</section>
<section anchor="resp" title="Responder">
<t> 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.</t>
<t> 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 following Quick Mode request might
come over UDP port 4500 (because NAT has been detected).</t>
<t> 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.</t>
<t> 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.</t>
<t> This specification makes no recommendation as to how long such a timeout should be, but
a few seconds should be enough.</t>
</section>
<section anchor="trans" title="Transmitter">
<t> 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.</t>
</section>
<section anchor="recv" title="Receiver">
<t> The IKE header is copied from RFC 5996 below for reference:</t>
<figure>
<artwork><![CDATA[
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
]]></artwork>
</figure>
<t> 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.</t>
</section>
</section>
<section anchor="ops" title="Operational Considerations">
<t> Most IKE is relatively short messages. Quick Mode in IKEv1, and in IKEv2 all but the
IKE_AUTH exchange are short. It is only the IKE_AUTH exchange in IKEv2. UDP has advantages
in lower latency and lower resource consumption, so it makes sense to use UDP whenever TCP
is not required.</t>
<t> The requirements in <xref target="resp"/> 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 the way TCP works means that client (or initiator) will
wait for an ACK before transmitting the second segment of the IKE request.</t>
<t> 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.</t>
<t> 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.</t>
</section>
<section anchor="security" title="Security Considerations">
<t> Most of the security considerations for IKE over TCP are the same as those for UDP as in
RFC 5996.</t>
<t> 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.</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t> No IANA action is required for this specification, as TCP port 500 is already allocated
to "ISAKMP".</t>
</section>
</middle>
<!-- ====================================================================== -->
<back>
<references title="Normative References">
<reference anchor='RFC2119'>
<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<date year='1997' month='March' />
<area>General</area>
<keyword>keyword</keyword>
</front>
<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723' target='ftp://ftp.isi.edu/in-notes/rfc2119.txt' />
<format type='HTML' octets='16553' target='http://tools.ietf.org/html/rfc2119' />
</reference>
<reference anchor='RFC5996'>
<front>
<title>Internet Key Exchange Protocol: IKEv2</title>
<author initials='C' surname='Kaufman' fullname='Charlie Kaufman'>
<organization>Microsoft</organization>
</author>
<author initials='P' surname='Hoffman' fullname='Paul Hoffman'>
<organization>VPN Consortium</organization>
</author>
<author initials='Y' surname='Nir' fullname='Yoav Nir'>
<organization>Check Point</organization>
</author>
<author initials='P' surname='Eronen' fullname='Pasi Eronen'>
<organization>Nokia</organization>
</author>
<date month='September' year='2010' />
</front>
<seriesInfo name='RFC' value='5996' />
<format type='TXT' target='http://www.ietf.org/rfc/rfc5996.txt' />
<format type='HTML' target='http://xml.resource.org/public/rfc/html/rfc5996.html' />
<format type='XML' target='http://xml.resource.org/public/rfc/xml/rfc5996.xml' />
</reference>
<reference anchor='RFC2407'>
<front>
<title>The Internet IP Security Domain of Interpretation for ISAKMP</title>
<author initials='D' surname='Piper' fullname='Darrell Piper'>
<organization>Network Alchemy</organization>
</author>
<date month='November' year='1998' />
</front>
<seriesInfo name='RFC' value='2407' />
<format type='TXT' target='http://www.ietf.org/rfc/rfc2407.txt' />
<format type='HTML' target='http://xml.resource.org/public/rfc/html/rfc2407.html' />
</reference>
<reference anchor='RFC2408'>
<front>
<title>The Internet IP Security Domain of Interpretation for ISAKMP</title>
<author initials='D' surname='Maughan' fullname='Douglas Maughan'>
<organization>National Security Agency</organization>
</author>
<author initials='M' surname='Schertler' fullname='Mark Schertler'>
<organization>Securify, Inc.</organization>
</author>
<author initials='M' surname='Schneider' fullname='Mark Schneider'>
<organization>National Security Agency</organization>
</author>
<author initials='J' surname='Turner' fullname='Jeff Turner'>
<organization>RABA Technologies, Inc.</organization>
</author>
<date month='November' year='1998' />
</front>
<seriesInfo name='RFC' value='2408' />
<format type='TXT' target='http://www.ietf.org/rfc/rfc2408.txt' />
<format type='HTML' target='http://xml.resource.org/public/rfc/html/rfc2408.html' />
</reference>
</references>
<references title="Informative References">
<reference anchor='RFC793'>
<front>
<title>Transmission Control Protocol</title>
<author initials='J' surname='Postel' fullname='John Postel'>
<organization>DARPA</organization>
</author>
<date month='September' year='1981' />
</front>
<seriesInfo name='RFC' value='793' />
<seriesInfo name='STD' value='7' />
<format type='TXT' target='http://www.ietf.org/rfc/rfc793.txt' />
<format type='HTML' target='http://xml.resource.org/public/rfc/html/rfc793.html' />
</reference>
<reference anchor='RFC4787'>
<front>
<title>Network Address Translation (NAT) Behavioral Requirements for Unicast UDP</title>
<author initials='F' surname='Audet' fullname='Francois Audet'>
<organization>Nortel Networks</organization>
</author>
<author initials='C' surname='Jennings' fullname='Cullen Jennings'>
<organization>Cisco Systems</organization>
</author>
<date month='January' year='2007' />
</front>
<seriesInfo name='RFC' value='4787' />
<format type='TXT' target='http://www.ietf.org/rfc/rfc4787.txt' />
<format type='HTML' target='http://xml.resource.org/public/rfc/html/rfc4787.html' />
</reference>
<reference anchor='CGN-reqs'>
<front>
<title>Common requirements for Carrier Grade NATs (CGNs)</title>
<author initials='S' surname='Perreault' fullname='Simon Perreault'><organization>Viagenie</organization></author>
<author initials='I' surname='Yamagata' fullname='Ikuhei Yamagata'><organization>NTT Communications</organization></author>
<author initials='S' surname='Miyakawa' fullname='Shin Miyakawa'><organization>NTT Communications</organization></author>
<author initials='A' surname='Nakagawa' fullname='Akira Nakagawa'><organization>Japan Internet Exchange (JPIX)</organization></author>
<author initials='H' surname='Ashida' fullname='Hiroyuki Ashida'><organization>IS Consulting G.K.</organization></author>
<date year='2012' month='May' />
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-behave-lsn-requirements' />
<format type='TXT'
target='http://tools.ietf.org/id/draft-ietf-behave-lsn-requirements' />
<format type='HTML'
target='http://tools.ietf.org/html/draft-ietf-behave-lsn-requirements' />
</reference>
</references>
<!-- ====================================================================== -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 03:31:08 |