< draft-ietf-ipsecme-tcp-encaps-07.txt   draft-ietf-ipsecme-tcp-encaps-08.txt >
Network T. Pauly Network T. Pauly
Internet-Draft Apple Inc. Internet-Draft Apple Inc.
Intended status: Standards Track S. Touati Intended status: Standards Track S. Touati
Expires: August 13, 2017 Ericsson Expires: August 31, 2017 Ericsson
R. Mantha R. Mantha
Cisco Systems Cisco Systems
February 9, 2017 February 27, 2017
TCP Encapsulation of IKE and IPsec Packets TCP Encapsulation of IKE and IPsec Packets
draft-ietf-ipsecme-tcp-encaps-07 draft-ietf-ipsecme-tcp-encaps-08
Abstract Abstract
This document describes a method to transport IKE and IPsec packets This document describes a method to transport IKE and IPsec packets
over a TCP connection for traversing network middleboxes that may over a TCP connection for traversing network middleboxes that may
block IKE negotiation over UDP. This method, referred to as TCP block IKE negotiation over UDP. This method, referred to as TCP
encapsulation, involves sending both IKE packets for Security encapsulation, involves sending both IKE packets for Security
Association establishment and ESP packets over a TCP connection. Association establishment and ESP packets over a TCP connection.
This method is intended to be used as a fallback option when IKE This method is intended to be used as a fallback option when IKE
cannot be negotiated over UDP. cannot be negotiated over UDP.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 August 13, 2017. This Internet-Draft will expire on August 31, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 5, line 11 skipping to change at page 5, line 11
TCP encapsulation is not specifically negotiated in the IKE exchange. TCP encapsulation is not specifically negotiated in the IKE exchange.
Instead, support for TCP encapsulation must be pre-configured on both Instead, support for TCP encapsulation must be pre-configured on both
the TCP Originator and the TCP Responder. the TCP Originator and the TCP Responder.
The configuration defined on each peer should include the following The configuration defined on each peer should include the following
parameters: parameters:
o One or more TCP ports on which the TCP Responder will listen for o One or more TCP ports on which the TCP Responder will listen for
incoming connections. Note that the TCP Originator may initiate incoming connections. Note that the TCP Originator may initiate
TCP connections to the TCP Responder from any local port. The TCP connections to the TCP Responder from any local port. The
ports on which the TCP Responder listens will likey be based on ports on which the TCP Responder listens will likely be based on
the ports commonly allowed on restricted networks. the ports commonly allowed on restricted networks.
o Optionally, an extra framing protocol to use on top of TCP to o Optionally, an extra framing protocol to use on top of TCP to
further encapsulate the stream of IKE and IPsec packets. See further encapsulate the stream of IKE and IPsec packets. See
Appendix A for a detailed discussion. Appendix A for a detailed discussion.
This document leaves the selection of TCP ports up to This document leaves the selection of TCP ports up to
implementations. It is suggested to use TCP port 4500, which is implementations. It is suggested to use TCP port 4500, which is
allocated for IPsec NAT Traversal. allocated for IPsec NAT Traversal.
skipping to change at page 9, line 29 skipping to change at page 9, line 29
from an encapsulated IKE message or the ESP SPI from an encapsulated from an encapsulated IKE message or the ESP SPI from an encapsulated
ESP message. If the session had been fully established previously, ESP message. If the session had been fully established previously,
it is suggested that the TCP Originator send an UPDATE_SA_ADDRESSES it is suggested that the TCP Originator send an UPDATE_SA_ADDRESSES
message if MOBIKE is supported, or an INFORMATIONAL message (a message if MOBIKE is supported, or an INFORMATIONAL message (a
keepalive) otherwise. If either TCP Originator or TCP Responder keepalive) otherwise. If either TCP Originator or TCP Responder
receives a stream that cannot be parsed correctly (for example, if receives a stream that cannot be parsed correctly (for example, if
the TCP Originator stream is missing the stream prefix, or message the TCP Originator stream is missing the stream prefix, or message
frames are not parsable as IKE or ESP messages), it MUST close the frames are not parsable as IKE or ESP messages), it MUST close the
TCP connection. If there is instead a syntax issue within an IKE TCP connection. If there is instead a syntax issue within an IKE
message, an implementation MUST send the INVALID_SYNTAX notify message, an implementation MUST send the INVALID_SYNTAX notify
payload and tear down the IKE SA as ususal, rather than tearing down payload and tear down the IKE SA as usual, rather than tearing down
the TCP connection directly. the TCP connection directly.
An TCP Originator SHOULD only open one TCP connection per IKE SA, An TCP Originator SHOULD only open one TCP connection per IKE SA,
over which it sends all of the corresponding IKE and ESP messages. over which it sends all of the corresponding IKE and ESP messages.
This helps ensure that any firewall or NAT mappings allocated for the This helps ensure that any firewall or NAT mappings allocated for the
TCP connection apply to all of the traffic associated with the IKE SA TCP connection apply to all of the traffic associated with the IKE SA
equally. equally.
Similarly, a TCP Responder SHOULD at any given time send packets for Similarly, a TCP Responder SHOULD at any given time send packets for
an IKE SA and its Child SAs over only one TCP connection. It SHOULD an IKE SA and its Child SAs over only one TCP connection. It SHOULD
skipping to change at page 11, line 13 skipping to change at page 11, line 13
if a connection on a previous network did not use TCP encapsulation. if a connection on a previous network did not use TCP encapsulation.
9. Using IKE Message Fragmentation with TCP encapsulation 9. Using IKE Message Fragmentation with TCP encapsulation
IKE Message Fragmentation [RFC7383] is not required when using TCP IKE Message Fragmentation [RFC7383] is not required when using TCP
encapsulation, since a TCP stream already handles the fragmentation encapsulation, since a TCP stream already handles the fragmentation
of its contents across packets. Since fragmentation is redundant in of its contents across packets. Since fragmentation is redundant in
this case, implementations might choose to not negotiate IKE this case, implementations might choose to not negotiate IKE
fragmentation. Even if fragmentation is negotiated, an fragmentation. Even if fragmentation is negotiated, an
implementation SHOULD NOT send fragments when going over a TCP implementation SHOULD NOT send fragments when going over a TCP
connection, although it MUST support receiving fragements. connection, although it MUST support receiving fragments.
If an implementation supports both MOBIKE and IKE fragmentation, it If an implementation supports both MOBIKE and IKE fragmentation, it
SHOULD negotiate IKE fragmentation over a TCP encapsulated session in SHOULD negotiate IKE fragmentation over a TCP encapsulated session in
case the session switches to UDP encapsulation on another network. case the session switches to UDP encapsulation on another network.
10. Considerations for Keep-alives and DPD 10. Considerations for Keep-alives and DPD
Encapsulating IKE and IPsec inside of a TCP connection can impact the Encapsulating IKE and IPsec inside of a TCP connection can impact the
strategy that implementations use to detect peer liveness and to strategy that implementations use to detect peer liveness and to
maintain middlebox port mappings. Peer liveness should be checked maintain middlebox port mappings. Peer liveness should be checked
using IKE Informational packets [RFC7296]. using IKE Informational packets [RFC7296].
In general, TCP port mappings are maintained by NATs longers than UDP In general, TCP port mappings are maintained by NATs longer than UDP
port mappings, so IPsec ESP NAT keep-alives [RFC3948] SHOULD NOT be port mappings, so IPsec ESP NAT keep-alives [RFC3948] SHOULD NOT be
sent when using TCP encapsulation. Any implementation using TCP sent when using TCP encapsulation. Any implementation using TCP
encapsulation MUST silently drop incoming NAT keep-alive packets, and encapsulation MUST silently drop incoming NAT keep-alive packets, and
not treat them as errors. NAT keep-alive packets over a TCP not treat them as errors. NAT keep-alive packets over a TCP
encapsulated IPsec connection will be sent with a length value of 1 encapsulated IPsec connection will be sent with a length value of 1
byte, whose value is 0xFF [Figure 2]. byte, whose value is 0xFF [Figure 2].
Note that depending on the configuration of TCP and TLS on the Note that depending on the configuration of TCP and TLS on the
connection, TCP keep-alives [RFC1122] and TLS keep-alives [RFC6520] connection, TCP keep-alives [RFC1122] and TLS keep-alives [RFC6520]
may be used. These MUST NOT be used as indications of IKE peer may be used. These MUST NOT be used as indications of IKE peer
skipping to change at page 13, line 25 skipping to change at page 13, line 25
known valid protocol over TCP, but implementations should make sure known valid protocol over TCP, but implementations should make sure
to validate this assumption in order to avoid unexpected processing to validate this assumption in order to avoid unexpected processing
of TCP connections. of TCP connections.
Attackers may be able to disrupt the TCP connection by sending Attackers may be able to disrupt the TCP connection by sending
spurious RST packets. Due to this, implementations SHOULD make sure spurious RST packets. Due to this, implementations SHOULD make sure
that IKE session state persists even if the underlying TCP connection that IKE session state persists even if the underlying TCP connection
is torn down. is torn down.
If MOBIKE is being used, all of the security considerations outlined If MOBIKE is being used, all of the security considerations outlined
for MOBIKE apply [[RFC4555]]. for MOBIKE apply [RFC4555].
Similarly to MOBIKE, TCP encapsulation requires a TCP Responder to Similarly to MOBIKE, TCP encapsulation requires a TCP Responder to
handle changing of source address and port due to network or handle changing of source address and port due to network or
connection disruption. The successful delivery of valid IKE or ESP connection disruption. The successful delivery of valid IKE or ESP
messages over a new TCP connection is used by the TCP Responder to messages over a new TCP connection is used by the TCP Responder to
determine where to send subsequent responses. If an attacker is able determine where to send subsequent responses. If an attacker is able
to send packets on a new TCP connection that pass the validation to send packets on a new TCP connection that pass the validation
checks of the TCP Responder, it can influence which path future checks of the TCP Responder, it can influence which path future
packets take. For this reason, the validation of messages on the TCP packets take. For this reason, the validation of messages on the TCP
Responder must include decryption, authentication, and replay checks. Responder must include decryption, authentication, and replay checks.
skipping to change at page 14, line 22 skipping to change at page 14, line 22
16. References 16. References
16.1. Normative References 16.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets",
RFC 3948, DOI 10.17487/RFC3948, January 2005,
<http://www.rfc-editor.org/info/rfc3948>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<http://www.rfc-editor.org/info/rfc4303>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2 Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <http://www.rfc-editor.org/info/rfc7296>. 2014, <http://www.rfc-editor.org/info/rfc7296>.
16.2. Informative References 16.2. Informative References
[I-D.nir-ipsecme-ike-tcp] [I-D.nir-ipsecme-ike-tcp]
Nir, Y., "A TCP transport for the Internet Key Exchange", Nir, Y., "A TCP transport for the Internet Key Exchange",
draft-nir-ipsecme-ike-tcp-01 (work in progress), July draft-nir-ipsecme-ike-tcp-01 (work in progress), July
skipping to change at page 14, line 43 skipping to change at page 15, line 5
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989, DOI 10.17487/RFC1122, October 1989,
<http://www.rfc-editor.org/info/rfc1122>. <http://www.rfc-editor.org/info/rfc1122>.
[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within
HTTP/1.1", RFC 2817, DOI 10.17487/RFC2817, May 2000, HTTP/1.1", RFC 2817, DOI 10.17487/RFC2817, May 2000,
<http://www.rfc-editor.org/info/rfc2817>. <http://www.rfc-editor.org/info/rfc2817>.
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets",
RFC 3948, DOI 10.17487/RFC3948, January 2005,
<http://www.rfc-editor.org/info/rfc3948>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<http://www.rfc-editor.org/info/rfc4303>.
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006,
<http://www.rfc-editor.org/info/rfc4555>. <http://www.rfc-editor.org/info/rfc4555>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>. <http://www.rfc-editor.org/info/rfc5246>.
[RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport
skipping to change at page 17, line 36 skipping to change at page 17, line 36
Figure 4 Figure 4
1. Client establishes a TCP connection with the server on port 443 1. Client establishes a TCP connection with the server on port 443
or 4500. or 4500.
2. Client initiates TLS handshake. During TLS handshake, the 2. Client initiates TLS handshake. During TLS handshake, the
server SHOULD NOT request the client's' certificate, since server SHOULD NOT request the client's' certificate, since
authentication is handled as part of IKE negotiation. authentication is handled as part of IKE negotiation.
3. Client send the Stream Prefix for TCP encapsulated IKE 3. Client send the Stream Prefix for TCP encapsulated IKE
[Section 4] traffic to signal the beginning of IKE negotation. [Section 4] traffic to signal the beginning of IKE negotiation.
4. Client and server establish an IKE connection. This example 4. Client and server establish an IKE connection. This example
shows EAP-based authentication, although any authentication shows EAP-based authentication, although any authentication
type may be used. type may be used.
B.2. Deleting an IKE session B.2. Deleting an IKE session
Client Server Client Server
---------- ---------- ---------- ----------
1) ----------------------- IKE Session --------------------- 1) ----------------------- IKE Session ---------------------
Length + Non-ESP Marker ----------> Length + Non-ESP Marker ---------->
skipping to change at page 20, line 4 skipping to change at page 20, line 4
used, the Initiator SHOULD send UPDATE_SA_ADDRESSES. used, the Initiator SHOULD send UPDATE_SA_ADDRESSES.
B.4. Using MOBIKE between UDP and TCP Encapsulation B.4. Using MOBIKE between UDP and TCP Encapsulation
Client Server Client Server
---------- ---------- ---------- ----------
(IP_I1:UDP500 -> IP_R:UDP500) (IP_I1:UDP500 -> IP_R:UDP500)
1) ----------------- IKE_SA_INIT Exchange ----------------- 1) ----------------- IKE_SA_INIT Exchange -----------------
(IP_I1:UDP4500 -> IP_R:UDP4500) (IP_I1:UDP4500 -> IP_R:UDP4500)
Non-ESP Marker -----------> Non-ESP Marker ----------->
Intial IKE_AUTH Initial IKE_AUTH
HDR, SK { IDi, CERT, AUTH, HDR, SK { IDi, CERT, AUTH,
CP(CFG_REQUEST), CP(CFG_REQUEST),
SAi2, TSi, TSr, SAi2, TSi, TSr,
N(MOBIKE_SUPPORTED) } N(MOBIKE_SUPPORTED) }
<----------- Non-ESP Marker <----------- Non-ESP Marker
Initial IKE_AUTH Initial IKE_AUTH
HDR, SK { IDr, CERT, AUTH, HDR, SK { IDr, CERT, AUTH,
EAP, SAr2, TSi, TSr, EAP, SAr2, TSi, TSr,
N(MOBIKE_SUPPORTED) } N(MOBIKE_SUPPORTED) }
<------------------ IKE SA establishment ---------------> <------------------ IKE SA establishment --------------->
skipping to change at page 22, line 6 skipping to change at page 22, line 6
Tommy Pauly Tommy Pauly
Apple Inc. Apple Inc.
1 Infinite Loop 1 Infinite Loop
Cupertino, California 95014 Cupertino, California 95014
US US
Email: tpauly@apple.com Email: tpauly@apple.com
Samy Touati Samy Touati
Ericsson Ericsson
300 Holger Way 2755 Augustine
San Jose, California 95134 Santa Clara, California 95054
US US
Email: samy.touati@ericsson.com Email: samy.touati@ericsson.com
Ravi Mantha Ravi Mantha
Cisco Systems Cisco Systems
SEZ, Embassy Tech Village SEZ, Embassy Tech Village
Panathur, Bangalore 560 037 Panathur, Bangalore 560 037
India India
 End of changes. 14 change blocks. 
22 lines changed or deleted 22 lines changed or added

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