draft-ietf-ipsecme-tcp-encaps-03.txt   draft-ietf-ipsecme-tcp-encaps-04.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: May 4, 2017 Ericsson Expires: June 6, 2017 Ericsson
R. Mantha R. Mantha
Cisco Systems Cisco Systems
October 31, 2016 December 3, 2016
TCP Encapsulation of IKE and IPsec Packets TCP Encapsulation of IKE and IPsec Packets
draft-ietf-ipsecme-tcp-encaps-03 draft-ietf-ipsecme-tcp-encaps-04
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 tunnel encapsulation, involves sending both IKE packets for tunnel
establishment as well as tunneled packets using ESP over a TCP establishment as well as tunneled packets using ESP over a TCP
connection. This method is intended to be used as a fallback option connection. This method is intended to be used as a fallback option
when IKE cannot be negotiated over UDP. when IKE 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 May 4, 2017. This Internet-Draft will expire on June 6, 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 32 skipping to change at page 2, line 32
6. Connection Establishment and Teardown . . . . . . . . . . . . 8 6. Connection Establishment and Teardown . . . . . . . . . . . . 8
7. Interaction with NAT Detection Payloads . . . . . . . . . . . 9 7. Interaction with NAT Detection Payloads . . . . . . . . . . . 9
8. Using MOBIKE with TCP encapsulation . . . . . . . . . . . . . 9 8. Using MOBIKE with TCP encapsulation . . . . . . . . . . . . . 9
9. Using IKE Message Fragmentation with TCP encapsulation . . . 10 9. Using IKE Message Fragmentation with TCP encapsulation . . . 10
10. Considerations for Keep-alives and DPD . . . . . . . . . . . 10 10. Considerations for Keep-alives and DPD . . . . . . . . . . . 10
11. Middlebox Considerations . . . . . . . . . . . . . . . . . . 10 11. Middlebox Considerations . . . . . . . . . . . . . . . . . . 10
12. Performance Considerations . . . . . . . . . . . . . . . . . 11 12. Performance Considerations . . . . . . . . . . . . . . . . . 11
12.1. TCP-in-TCP . . . . . . . . . . . . . . . . . . . . . . . 11 12.1. TCP-in-TCP . . . . . . . . . . . . . . . . . . . . . . . 11
12.2. Added Reliability for Unreliable Protocols . . . . . . . 11 12.2. Added Reliability for Unreliable Protocols . . . . . . . 11
12.3. Quality of Service Markings . . . . . . . . . . . . . . 11 12.3. Quality of Service Markings . . . . . . . . . . . . . . 11
12.4. Maximum Segment Size . . . . . . . . . . . . . . . . . . 11 12.4. Maximum Segment Size . . . . . . . . . . . . . . . . . . 12
13. Security Considerations . . . . . . . . . . . . . . . . . . . 12 13. Security Considerations . . . . . . . . . . . . . . . . . . . 12
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
16.1. Normative References . . . . . . . . . . . . . . . . . . 12 16.1. Normative References . . . . . . . . . . . . . . . . . . 12
16.2. Informative References . . . . . . . . . . . . . . . . . 13 16.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Using TCP encapsulation with TLS . . . . . . . . . . 14 Appendix A. Using TCP encapsulation with TLS . . . . . . . . . . 14
Appendix B. Example exchanges of TCP Encapsulation with TLS . . 14 Appendix B. Example exchanges of TCP Encapsulation with TLS . . 15
B.1. Establishing an IKE session . . . . . . . . . . . . . . . 14 B.1. Establishing an IKE session . . . . . . . . . . . . . . . 15
B.2. Deleting an IKE session . . . . . . . . . . . . . . . . . 16 B.2. Deleting an IKE session . . . . . . . . . . . . . . . . . 17
B.3. Re-establishing an IKE session . . . . . . . . . . . . . 17 B.3. Re-establishing an IKE session . . . . . . . . . . . . . 18
B.4. Using MOBIKE between UDP and TCP Encapsulation . . . . . 18 B.4. Using MOBIKE between UDP and TCP Encapsulation . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
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 tunneled data traffic. Many Security Payload (ESP) messages for tunneled data traffic. Many
network middleboxes that filter traffic on public hotspots block all network middleboxes that filter traffic on public hotspots block all
UDP traffic, including IKE and IPsec, but allow TCP connections UDP traffic, including IKE and IPsec, but allow TCP connections
through since they appear to be web traffic. Devices on these through since they appear to be web traffic. Devices on these
networks that need to use IPsec (to access private enterprise networks that need to use IPsec (to access private enterprise
skipping to change at page 9, line 5 skipping to change at page 9, line 5
complete message, which is either an encapsulated IKE or ESP message. complete message, which is either an encapsulated IKE or ESP message.
If the connection is being used to resume a previous IKE session, the If the connection is being used to resume a previous IKE session, the
responder can recognize the session using either the IKE SPI from an responder can recognize the session using either the IKE SPI from an
encapsulated IKE message or the ESP SPI from an encapsulated ESP encapsulated IKE message or the ESP SPI from an encapsulated ESP
message. If the session had been fully established previously, it is message. If the session had been fully established previously, it is
suggested that the initiator send an UPDATE_SA_ADDRESSES message if suggested that the initiator send an UPDATE_SA_ADDRESSES message if
MOBIKE is supported, or an INFORMATIONAL message (a keepalive) MOBIKE is supported, or an INFORMATIONAL message (a keepalive)
otherwise. If either initiator or responder receives a stream that otherwise. If either initiator or responder receives a stream that
cannot be parsed correctly, it MUST close the TCP connection. cannot be parsed correctly, it MUST close the TCP connection.
Multiple TCP connections between the initiator and the responder are An initiator SHOULD only open one TCP connection per IKE SA, over
allowed, but their use must take into account the initiator which it sends all of the corresponding IKE and ESP messages. This
capabilities and the deployment model such as to connect to multiple helps ensure that any firewall or NAT mappings allocated for the TCP
gateways handling different ESP SAs when deployed in a high connection apply to all of the traffic associated with the IKE SA
availability model. If multiple TCP connections are used, equally.
implementations SHOULD allow receiving any IKE or ESP SA over any of
the TCP connections, not enforcing any strict mapping. It is also
possible to negotiate multiple IKE SAs over the same TCP connection
in order to reduce the number of connections between the two peers.
The processing of the TCP-encapsulated IKE and ESP packets is the A responder SHOULD at any given time send packets for an IKE SA and
same when using either a single TCP connection or multiple TCP its Child SAs over only one TCP connection. It should choose the TCP
connections. connection on which it last received a valid and decryptable IKE or
ESP message. Since a connection may be broken and a new connection
re-established by the initiator without the responder being aware, a
responder SHOULD accept receiving IKE and ESP messages on a new
connection. It will then use that connection for all subsequent
responses. A responder MAY close a TCP connection that it perceives
as idle and extraneous (one previously used for IKE and ESP messages
that has been replaced by a new connection).
Multiple IKE SAs SHOULD NOT share a single TCP connection.
7. Interaction with NAT Detection Payloads 7. Interaction with NAT Detection Payloads
When negotiating over UDP port 500, IKE_SA_INIT packets include When negotiating over UDP port 500, IKE_SA_INIT packets include
NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP payloads to NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP payloads to
determine if UDP encapsulation of IPsec packets should be used. determine if UDP encapsulation of IPsec packets should be used.
These payloads contain SHA-1 digests of the SPIs, IP addresses, and These payloads contain SHA-1 digests of the SPIs, IP addresses, and
ports. IKE_SA_INIT packets sent on a TCP connection SHOULD include ports. IKE_SA_INIT packets sent on a TCP connection SHOULD include
these payloads, and SHOULD use the applicable TCP ports when creating these payloads, and SHOULD use the applicable TCP ports when creating
and checking the SHA-1 digests. and checking the SHA-1 digests.
skipping to change at page 17, line 5 skipping to change at page 17, line 51
Figure 5 Figure 5
1. Client and server exchange INFORMATIONAL messages to notify IKE 1. Client and server exchange INFORMATIONAL messages to notify IKE
SA deletion. SA deletion.
2. Client and server negotiate TLS session deletion using TLS 2. Client and server negotiate TLS session deletion using TLS
CLOSE_NOTIFY. CLOSE_NOTIFY.
3. The TCP connection is torn down. 3. The TCP connection is torn down.
Unless the TCP connection and/or TLS session are being used for The deletion of the IKE SA should lead to the disposal of the
multiple IKE SAs, the deletion of the IKE SA should lead to the underlying TLS and TCP state.
disposal of the underlying TLS and TCP state.
B.3. Re-establishing an IKE session B.3. Re-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
TcpAck ----------> TcpAck ---------->
 End of changes. 10 change blocks. 
25 lines changed or deleted 29 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/