draft-ietf-ipsecme-tcp-encaps-00.txt   draft-ietf-ipsecme-tcp-encaps-01.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: December 26, 2016 Ericsson Expires: January 8, 2017 Ericsson
R. Mantha R. Mantha
Cisco Systems Cisco Systems
June 24, 2016 July 7, 2016
TCP Encapsulation of IKE and IPSec Packets TCP Encapsulation of IKE and IPSec Packets
draft-ietf-ipsecme-tcp-encaps-00 draft-ietf-ipsecme-tcp-encaps-01
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 all packets for tunnel establishment encapsulation, involves sending all packets for tunnel establishment
as well as tunneled packets over a TCP connection. This method is as well as tunneled packets over a TCP connection. This method is
intended to be used as a fallback option when IKE cannot be intended to be used as a fallback option when IKE cannot be
negotiated over UDP. 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 December 26, 2016. This Internet-Draft will expire on January 8, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 2, line 20 skipping to change at page 2, line 20
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Prior Work and Motivation . . . . . . . . . . . . . . . . 3 1.1. Prior Work and Motivation . . . . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 4
3. TCP-Encapsulated Header Formats . . . . . . . . . . . . . . . 5 3. TCP-Encapsulated Header Formats . . . . . . . . . . . . . . . 5
3.1. TCP-Encapsulated IKE Header Format . . . . . . . . . . . 5 3.1. TCP-Encapsulated IKE Header Format . . . . . . . . . . . 5
3.2. TCP-Encapsulated ESP Header Format . . . . . . . . . . . 6 3.2. TCP-Encapsulated ESP Header Format . . . . . . . . . . . 6
4. TCP-Encapsulated Stream Prefix . . . . . . . . . . . . . . . 6 4. TCP-Encapsulated Stream Prefix . . . . . . . . . . . . . . . 6
5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Connection Establishment and Teardown . . . . . . . . . . . . 7 6. Connection Establishment and Teardown . . . . . . . . . . . . 7
7. Interaction with NAT Detection Payloads . . . . . . . . . . . 8 7. Interaction with NAT Detection Payloads . . . . . . . . . . . 8
8. Using MOBIKE with TCP encapsulation . . . . . . . . . . . . . 8 8. Using MOBIKE with TCP encapsulation . . . . . . . . . . . . . 9
9. Using IKE Message Fragmentation with TCP encapsulation . . . 9 9. Using IKE Message Fragmentation with TCP encapsulation . . . 9
10. Considerations for Keep-alives and DPD . . . . . . . . . . . 9 10. Considerations for Keep-alives and DPD . . . . . . . . . . . 9
11. Middlebox Considerations . . . . . . . . . . . . . . . . . . 9 11. Middlebox Considerations . . . . . . . . . . . . . . . . . . 10
12. Performance Considerations . . . . . . . . . . . . . . . . . 10 12. Performance Considerations . . . . . . . . . . . . . . . . . 10
12.1. TCP-in-TCP . . . . . . . . . . . . . . . . . . . . . . . 10 12.1. TCP-in-TCP . . . . . . . . . . . . . . . . . . . . . . . 10
12.2. Added Reliability for Unreliable Protocols . . . . . . . 10 12.2. Added Reliability for Unreliable Protocols . . . . . . . 11
12.3. Quality of Service Markings . . . . . . . . . . . . . . 10 12.3. Quality of Service Markings . . . . . . . . . . . . . . 11
12.4. Maximum Segment Size . . . . . . . . . . . . . . . . . . 11 12.4. Maximum Segment Size . . . . . . . . . . . . . . . . . . 11
13. Security Considerations . . . . . . . . . . . . . . . . . . . 11 13. Security Considerations . . . . . . . . . . . . . . . . . . . 11
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
16.1. Normative References . . . . . . . . . . . . . . . . . . 11 16.1. Normative References . . . . . . . . . . . . . . . . . . 12
16.2. Informative References . . . . . . . . . . . . . . . . . 12 16.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Using TCP encapsulation with TLS . . . . . . . . . . 13 Appendix A. Using TCP encapsulation with TLS . . . . . . . . . . 13
Appendix B. Example exchanges of TCP Encapsulation with TLS . . 13 Appendix B. Example exchanges of TCP Encapsulation with TLS . . 14
B.1. Establishing an IKE session . . . . . . . . . . . . . . . 13 B.1. Establishing an IKE session . . . . . . . . . . . . . . . 14
B.2. Deleting an IKE session . . . . . . . . . . . . . . . . . 15 B.2. Deleting an IKE session . . . . . . . . . . . . . . . . . 16
B.3. Re-establishing an IKE session . . . . . . . . . . . . . 16 B.3. Re-establishing an IKE session . . . . . . . . . . . . . 17
B.4. Using MOBIKE between UDP and TCP Encapsulation . . . . . 17 B.4. Using MOBIKE between UDP and TCP Encapsulation . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
IKEv2 [RFC7296] is a protocol for establishing IPSec tunnels, using IKEv2 [RFC7296] is a protocol for establishing IPSec tunnels, using
IKE messages over UDP for control traffic, and using Encapsulating IKE messages over UDP for control traffic, and using Encapsulating
Security Payload (ESP) messages for its data traffic. Many network Security Payload (ESP) messages for tunneled data traffic. Many
middleboxes that filter traffic on public hotspots block all UDP network middleboxes that filter traffic on public hotspots block all
traffic, including IKE and IPSec, but allow TCP connections through UDP traffic, including IKE and IPSec, but allow TCP connections
since they appear to be web traffic. Devices on these networks that through since they appear to be web traffic. Devices on these
need to use IPSec (to access private enterprise networks, to route networks that need to use IPSec (to access private enterprise
voice-over-IP calls to carrier networks, or because of security networks, to route voice-over-IP calls to carrier networks, or
policies) are unable to establish IPSec tunnels. This document because of security policies) are unable to establish IPSec tunnels.
defines a method for encapsulating both the IKE control messages as This document defines a method for encapsulating both the IKE control
well as the IPSec data messages within a TCP connection. messages as well as the IPSec data messages within a TCP connection.
Using TCP as a transport for IPSec packets adds a third option to the Using TCP as a transport for IPSec packets adds a third option to the
list of traditional IPSec transports: list of traditional IPSec transports:
1. Direct. Currently, IKE negotiations begin over UDP port 500. 1. Direct. Currently, IKE negotiations begin over UDP port 500.
If no NAT is detected between the initiator and the receiver, If no NAT is detected between the initiator and the receiver,
then subsequent IKE packets are sent over UDP port 500 and then subsequent IKE packets are sent over UDP port 500 and
IPSec data packets are sent using ESP [RFC4303]. IPSec data packets are sent using ESP [RFC4303].
2. UDP Encapsulation [RFC3948]. If a NAT is detected between the 2. UDP Encapsulation [RFC3948]. If a NAT is detected between the
skipping to change at page 4, line 47 skipping to change at page 4, line 47
o One or more TCP ports on which the responder will listen for o One or more TCP ports on which the responder will listen for
incoming connections. Note that the initiator may initiate TCP incoming connections. Note that the initiator may initiate TCP
connections to the responder from any local port. connections to the responder from any local port.
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's 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.
Since TCP encapsulation of IKE and IPSec packets adds overhead and Since TCP encapsulation of IKE and IPSec packets adds overhead and
has potential performance trade-offs compared to direct or UDP- has potential performance trade-offs compared to direct or UDP-
encapsulated tunnels (as described in Performance Considerations, encapsulated tunnels (as described in Performance Considerations,
Section 12), when possible, implementations SHOULD prefer ESP direct Section 12), implementations SHOULD prefer ESP direct or UDP
or UDP encapsulated tunnels over TCP encapsulated tunnels. encapsulated tunnels over TCP encapsulated tunnels when possible.
3. TCP-Encapsulated Header Formats 3. TCP-Encapsulated Header Formats
In order to encapsulate IKE and ESP messages within a TCP stream, a In order to encapsulate IKE and ESP messages within a TCP stream, a
16-bit length field precedes every message. If the first 32-bits of 16-bit length field precedes every message. If the first 32-bits of
the message are zeros (a Non-ESP Marker), then the contents comprise the message are zeros (a Non-ESP Marker), then the contents comprise
an IKE message. Otherwise, the contents comprise an ESP message. an IKE message. Otherwise, the contents comprise an ESP message.
Authentication Header (AH) messages are not supported for TCP Authentication Header (AH) messages are not supported for TCP
encapsulation. encapsulation.
skipping to change at page 6, line 30 skipping to change at page 6, line 30
order that specifies the length of the ESP packet within the TCP order that specifies the length of the ESP packet within the TCP
stream. stream.
The SPI field in the ESP header MUST NOT be a zero value. The SPI field in the ESP header MUST NOT be a zero value.
o Length (2 octets, unsigned integer) - Length of the ESP packet o Length (2 octets, unsigned integer) - Length of the ESP packet
including the Length Field. including the Length Field.
4. TCP-Encapsulated Stream Prefix 4. TCP-Encapsulated Stream Prefix
Each TCP stream used for IKE and IPSec encapsulation MUST begin with Each stream of bytes used for IKE and IPSec encapsulation MUST begin
a fixed sequence of five bytes as a magic value, containing the with a fixed sequence of six bytes as a magic value, containing the
characters "IKETCP" as ASCII values. This allows peers to characters "IKETCP" as ASCII values. This allows peers to
differentiate this protocol from other protocols that may be run over differentiate this protocol from other protocols that may be run over
TCP streams, since the value does not overlap with the valid start of TCP streams, since the bytes do not overlap with the valid start of
any other known stream protocol. This value is only sent once, by any other known stream protocol. This value is only sent once, by
the Initiator only, at the beginning of any TCP stream. If other the Initiator only, at the beginning of any stream of IKE and ESP
framing protocols are used within TCP to further encapsulate or messages.
encrypt the stream of IKE and ESP messages, the Stream Prefix must
still precede any IKE or ESP messages. If other framing protocols are used within TCP to further encapsulate
or encrypt the stream of IKE and ESP messages, the Stream Prefix must
be at the start of the Initiator's IKE and ESP message stream within
the added protocol layer [Appendix A].
0 1 2 3 4 5 0 1 2 3 4 5
+------+------+------+------+------+------+ +------+------+------+------+------+------+
| 0x49 | 0x4b | 0x45 | 0x54 | 0x43 | 0x50 | | 0x49 | 0x4b | 0x45 | 0x54 | 0x43 | 0x50 |
+------+------+------+------+------+------+ +------+------+------+------+------+------+
Figure 3 Figure 3
5. Applicability 5. Applicability
TCP encapsulation is applicable only when it has been configured to TCP encapsulation is applicable only when it has been configured to
be used with specific IKE peers. If a responder is configured to use be used with specific IKE peers. If a responder is configured to use
TCP encapsulation, it MUST listen on the configured port(s) in case TCP encapsulation, it MUST listen on the configured port(s) in case
any peers will initiate new IKE sessions. Initiators MAY use TCP any peers will initiate new IKE sessions. Initiators MAY use TCP
encapsulation for any IKE session to a peer that is configured to encapsulation for any IKE session to a peer that is configured to
support TCP encapsulation, although it is recommended that initiators support TCP encapsulation, although it is recommended that initiators
should only use TCP encapsulation when traffic over UDP is blocked. should only use TCP encapsulation when traffic over UDP is blocked.
Since the support of TCP encapsulation is a configured property, not
a negotiated one, it is recommended that if there are multiple IKE
endpoints representing a single peer (such as multiple machines with
different IP addresses when connecting by Fully-Qualified Domain
Name, or endpoints used with IKE redirection), all of the endpoints
equally support TCP encapsulation.
If TCP encapsulation is being used for a specific IKE SA, all If TCP encapsulation is being used for a specific IKE SA, all
messages for that IKE SA and its Child SAs MUST be sent over a TCP messages for that IKE SA and its Child SAs MUST be sent over a TCP
connection until the SA is deleted or MOBIKE is used to change the SA connection until the SA is deleted or MOBIKE is used to change the SA
endpoints and/or encapsulation protocol. No packets should be sent endpoints and/or encapsulation protocol. No packets should be sent
over UDP or direct ESP for the IKE SA or its Child SAs while using over UDP or direct ESP for the IKE SA or its Child SAs while using
TCP encapsulation. TCP encapsulation.
6. Connection Establishment and Teardown 6. Connection Establishment and Teardown
When the IKE initiator uses TCP encapsulation for its negotiation, it When the IKE initiator uses TCP encapsulation for its negotiation, it
skipping to change at page 13, line 28 skipping to change at page 13, line 44
The use of TLS should be configurable on the peers. The responder The use of TLS should be configurable on the peers. The responder
may expect to read encapsulated IKE and ESP packets directly from the may expect to read encapsulated IKE and ESP packets directly from the
TCP connection, or it may expect to read them from a stream of TLS TCP connection, or it may expect to read them from a stream of TLS
data packets. The initiator should be pre-configured to use TLS or data packets. The initiator should be pre-configured to use TLS or
not when communicating with a given port on the responder. not when communicating with a given port on the responder.
When new TCP connections are re-established due to a broken When new TCP connections are re-established due to a broken
connection, TLS must be re-negotiated. TLS Session Resumption is connection, TLS must be re-negotiated. TLS Session Resumption is
recommended to improve efficiency in this case. recommended to improve efficiency in this case.
The security of the IKE session is entirely derived from the IKVEv2 The security of the IKE session is entirely derived from the IKE
negotiation and key establishment, therefore When TLS is used on the negotiation and key establishment and not from the TLS session (which
TCP connection, both the initiator and responder MUST allow for the in this context is only used for encapsulation purposes), therefore
NULL cipher to be selected. when TLS is used on the TCP connection, both the initiator and
responder SHOULD allow the NULL cipher to be selected for performance
reasons.
Implementations must be aware that the use of TLS introduces another Implementations should be aware that the use of TLS introduces
layer of overhead requiring more bytes to transmit a given IKE and another layer of overhead requiring more bytes to transmit a given
IPSec packet. IKE and IPSec packet. For this reason, direct ESP, UDP
encapsulation, or TCP encapsulation without TLS should be preferred
in situations in which TLS is not required in order to traverse
middle-boxes.
Appendix B. Example exchanges of TCP Encapsulation with TLS Appendix B. Example exchanges of TCP Encapsulation with TLS
B.1. Establishing an IKE session B.1. Establishing an IKE session
Client Server Client Server
---------- ---------- ---------- ----------
1) -------------------- TCP Connection ------------------- 1) -------------------- TCP Connection -------------------
(IP_I:Port_I -> IP_R:TCP443 or TCP4500) (IP_I:Port_I -> IP_R:TCP443 or TCP4500)
TcpSyn ----------> TcpSyn ---------->
<---------- TcpSyn,Ack <---------- TcpSyn,Ack
skipping to change at page 18, line 28 skipping to change at page 19, line 28
1. During the IKE_SA_INIT exchange, the client and server exchange 1. During the IKE_SA_INIT exchange, the client and server exchange
MOBIKE_SUPPORTED notify payloads to indicate support for MOBIKE_SUPPORTED notify payloads to indicate support for
MOBIKE. MOBIKE.
2. The client changes its point of attachment to the network, and 2. The client changes its point of attachment to the network, and
receives a new IP address. The client attempts to re-establish receives a new IP address. The client attempts to re-establish
the IKE session using the UPDATE_SA_ADDRESSES notify payload, the IKE session using the UPDATE_SA_ADDRESSES notify payload,
but the server does not respond because the network blocks UDP but the server does not respond because the network blocks UDP
traffic. traffic.
3. The client beings up a TCP connection to the server in order to 3. The client brings up a TCP connection to the server in order to
use TCP encapsulation. use TCP encapsulation.
4. The client initiates and TLS handshake with the server. 4. The client initiates and TLS handshake with the server.
5. The client sends the Stream Prefix for TCP encapsulated IKE 5. The client sends the Stream Prefix for TCP encapsulated IKE
traffic [Section 4]. traffic [Section 4].
6. The client sends the UPDATE_SA_ADDRESSES notify payload on the 6. The client sends the UPDATE_SA_ADDRESSES notify payload on the
TCP encapsulated connection. TCP encapsulated connection.
 End of changes. 20 change blocks. 
44 lines changed or deleted 59 lines changed or added

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