< draft-ietf-ipsecme-tcp-encaps-02.txt   draft-ietf-ipsecme-tcp-encaps-03.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: February 18, 2017 Ericsson Expires: May 4, 2017 Ericsson
R. Mantha R. Mantha
Cisco Systems Cisco Systems
August 17, 2016 October 31, 2016
TCP Encapsulation of IKE and IPsec Packets TCP Encapsulation of IKE and IPsec Packets
draft-ietf-ipsecme-tcp-encaps-02 draft-ietf-ipsecme-tcp-encaps-03
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 February 18, 2017. This Internet-Draft will expire on May 4, 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 21 skipping to change at page 2, line 21
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 . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Connection Establishment and Teardown . . . . . . . . . . . . 7 5.1. Recommended Fallback from UDP . . . . . . . . . . . . . . 7
7. Interaction with NAT Detection Payloads . . . . . . . . . . . 8 6. Connection Establishment and Teardown . . . . . . . . . . . . 8
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 . . . 9 9. Using IKE Message Fragmentation with TCP encapsulation . . . 10
10. Considerations for Keep-alives and DPD . . . . . . . . . . . 9 10. Considerations for Keep-alives and DPD . . . . . . . . . . . 10
11. Middlebox Considerations . . . . . . . . . . . . . . . . . . 10 11. Middlebox Considerations . . . . . . . . . . . . . . . . . . 10
12. Performance Considerations . . . . . . . . . . . . . . . . . 10 12. Performance Considerations . . . . . . . . . . . . . . . . . 11
12.1. TCP-in-TCP . . . . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . 11
13. Security Considerations . . . . . . . . . . . . . . . . . . . 11 13. Security Considerations . . . . . . . . . . . . . . . . . . . 12
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . 12 16.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Using TCP encapsulation with TLS . . . . . . . . . . 13 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 . . 14
B.1. Establishing an IKE session . . . . . . . . . . . . . . . 14 B.1. Establishing an IKE session . . . . . . . . . . . . . . . 14
B.2. Deleting an IKE session . . . . . . . . . . . . . . . . . 16 B.2. Deleting an IKE session . . . . . . . . . . . . . . . . . 16
B.3. Re-establishing an IKE session . . . . . . . . . . . . . 17 B.3. Re-establishing an IKE session . . . . . . . . . . . . . 17
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 . . . . . . . . . . . . . . . . . . . . . . . 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
skipping to change at page 5, line 34 skipping to change at page 5, line 34
Authentication Header (AH) messages are not supported for TCP Authentication Header (AH) messages are not supported for TCP
encapsulation. encapsulation.
Although a TCP stream may be able to send very long messages, Although a TCP stream may be able to send very long messages,
implementations SHOULD limit message lengths to typical UDP datagram implementations SHOULD limit message lengths to typical UDP datagram
ESP payload lengths. The maximum message length is used as the ESP payload lengths. The maximum message length is used as the
effective MTU for connections that are being encrypted using ESP, so effective MTU for connections that are being encrypted using ESP, so
the maximum message length will influence characteristics of inner the maximum message length will influence characteristics of inner
connections, such as the TCP Maximum Segment Size (MSS). connections, such as the TCP Maximum Segment Size (MSS).
Note that this method of encapsulation will also work for placing IKE
and ESP messages within any protocol that presents a stream
abstraction, beyond TCP.
3.1. TCP-Encapsulated IKE Header Format 3.1. TCP-Encapsulated IKE Header Format
1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Non-ESP Marker | | Non-ESP Marker |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 7, line 37 skipping to change at page 7, line 40
different IP addresses when connecting by Fully-Qualified Domain different IP addresses when connecting by Fully-Qualified Domain
Name, or endpoints used with IKE redirection), all of the endpoints Name, or endpoints used with IKE redirection), all of the endpoints
equally support TCP encapsulation. 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. See Section 8 for more endpoints and/or encapsulation protocol. See Section 8 for more
details on using MOBIKE to transition between encapsulation modes. details on using MOBIKE to transition between encapsulation modes.
5.1. Recommended Fallback from UDP
Since UDP is the preferred method of transport for IKE messages,
implementations that use TCP encapsulation should have an algorithm
for deciding when to use TCP after determining that UDP is unusable.
If an initiator implementation has no prior knowledge about the
network it is on and the status of UDP on that network, it SHOULD
always attempt negotiate IKE over UDP first. IKEv2 defines how to
use retransmission timers with IKE messages, and IKE_SA_INIT messages
specifically [RFC7296]. Generally, this means that the
implementation will define a frequency of retransmission, and the
maximum number of retransmissions allowed before marking the IKE SA
as failed. An implementation can attempt negotiation over TCP once
it has hit the maximum retransmissions over UDP, or slightly before
to reduce connection setup delays. It is recommended that the
initial message over UDP is retransmitted at least once before
falling back to TCP, unless the initiator knows beforehand that the
network is likely to block UDP.
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
will initiate a TCP connection to the responder using the configured will initiate a TCP connection to the responder using the configured
TCP port. The first bytes sent on the stream MUST be the stream TCP port. The first bytes sent on the stream MUST be the stream
prefix value [Section 4]. After this prefix, encapsulated IKE prefix value [Section 4]. After this prefix, encapsulated IKE
messages will negotiate the IKE SA and initial Child SA [RFC7296]. messages will negotiate the IKE SA and initial Child SA [RFC7296].
After this point, both encapsulated IKE Figure 1 and ESP Figure 2 After this point, both encapsulated IKE Figure 1 and ESP Figure 2
messages will be sent over the TCP connection. messages will be sent over the TCP connection.
skipping to change at page 8, line 35 skipping to change at page 9, line 9
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 Multiple TCP connections between the initiator and the responder are
allowed, but their use must take into account the initiator allowed, but their use must take into account the initiator
capabilities and the deployment model such as to connect to multiple capabilities and the deployment model such as to connect to multiple
gateways handling different ESP SAs when deployed in a high gateways handling different ESP SAs when deployed in a high
availability model. It is also possible to negotiate multiple IKE availability model. If multiple TCP connections are used,
SAs over the same TCP connection. 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 packets is the same whether its within a The processing of the TCP-encapsulated IKE and ESP packets is the
single or multiple TCP connections. same when using either a single TCP connection or multiple TCP
connections.
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.
 End of changes. 13 change blocks. 
18 lines changed or deleted 46 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/