< draft-ietf-ipsecme-rfc8229bis-03.txt   draft-ietf-ipsecme-rfc8229bis-04.txt >
Network Working Group V. Smyslov Network Working Group V. Smyslov
Internet-Draft ELVIS-PLUS Internet-Draft ELVIS-PLUS
Obsoletes: 8229 (if approved) T. Pauly Obsoletes: 8229 (if approved) T. Pauly
Intended status: Standards Track Apple Inc. Intended status: Standards Track Apple Inc.
Expires: September 23, 2022 March 22, 2022 Expires: 24 September 2022 23 March 2022
TCP Encapsulation of IKE and IPsec Packets TCP Encapsulation of IKE and IPsec Packets
draft-ietf-ipsecme-rfc8229bis-03 draft-ietf-ipsecme-rfc8229bis-04
Abstract Abstract
This document describes a method to transport Internet Key Exchange This document describes a method to transport Internet Key Exchange
Protocol (IKE) and IPsec packets over a TCP connection for traversing Protocol (IKE) and IPsec packets over a TCP connection for traversing
network middleboxes that may block IKE negotiation over UDP. This network middleboxes that may block IKE negotiation over UDP. This
method, referred to as "TCP encapsulation", involves sending both IKE method, referred to as "TCP encapsulation", involves sending both IKE
packets for Security Association establishment and Encapsulating packets for Security Association establishment and Encapsulating
Security Payload (ESP) packets over a TCP connection. This method is Security Payload (ESP) 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
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 September 23, 2022. This Internet-Draft will expire on 24 September 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 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 (https://trustee.ietf.org/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Revised BSD License text as
include Simplified BSD License text as described in Section 4.e of described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Revised BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Prior Work and Motivation . . . . . . . . . . . . . . . . 4 1.1. Prior Work and Motivation . . . . . . . . . . . . . . . . 4
2. Terminology and Notation . . . . . . . . . . . . . . . . . . 5 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 5
3. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 5
4. TCP-Encapsulated Header Formats . . . . . . . . . . . . . . . 6 4. TCP-Encapsulated Header Formats . . . . . . . . . . . . . . . 6
4.1. TCP-Encapsulated IKE Header Format . . . . . . . . . . . 6 4.1. TCP-Encapsulated IKE Header Format . . . . . . . . . . . 6
4.2. TCP-Encapsulated ESP Header Format . . . . . . . . . . . 7 4.2. TCP-Encapsulated ESP Header Format . . . . . . . . . . . 7
5. TCP-Encapsulated Stream Prefix . . . . . . . . . . . . . . . 7 5. TCP-Encapsulated Stream Prefix . . . . . . . . . . . . . . . 7
6. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Recommended Fallback from UDP . . . . . . . . . . . . . . 8 6.1. Recommended Fallback from UDP . . . . . . . . . . . . . . 8
7. Using TCP Encapsulation . . . . . . . . . . . . . . . . . . . 9 7. Using TCP Encapsulation . . . . . . . . . . . . . . . . . . . 9
7.1. Connection Establishment and Teardown . . . . . . . . . . 9 7.1. Connection Establishment and Teardown . . . . . . . . . . 9
7.2. Retransmissions . . . . . . . . . . . . . . . . . . . . . 11 7.2. Retransmissions . . . . . . . . . . . . . . . . . . . . . 11
7.3. Cookies and Puzzles . . . . . . . . . . . . . . . . . . . 11 7.3. Cookies and Puzzles . . . . . . . . . . . . . . . . . . . 11
7.3.1. Statelessness versus Delay of SA Establishment . . . 13 7.3.1. Statelessness versus Delay of SA Establishment . . . 13
7.4. Error Handling in IKE_SA_INIT . . . . . . . . . . . . . . 13 7.4. Error Handling in IKE_SA_INIT . . . . . . . . . . . . . . 13
7.5. NAT Detection Payloads . . . . . . . . . . . . . . . . . 13 7.5. NAT Detection Payloads . . . . . . . . . . . . . . . . . 14
7.6. Keep-Alives and Dead Peer Detection . . . . . . . . . . . 14 7.6. Keep-Alives and Dead Peer Detection . . . . . . . . . . . 14
7.7. Implications of TCP Encapsulation on IPsec SA Processing 14 7.7. Implications of TCP Encapsulation on IPsec SA
Processing . . . . . . . . . . . . . . . . . . . . . . . 15
8. Interaction with IKEv2 Extensions . . . . . . . . . . . . . . 15 8. Interaction with IKEv2 Extensions . . . . . . . . . . . . . . 15
8.1. MOBIKE Protocol . . . . . . . . . . . . . . . . . . . . . 15 8.1. MOBIKE Protocol . . . . . . . . . . . . . . . . . . . . . 15
8.2. IKE Redirect . . . . . . . . . . . . . . . . . . . . . . 16 8.2. IKE Redirect . . . . . . . . . . . . . . . . . . . . . . 16
8.3. IKEv2 Session Resumption . . . . . . . . . . . . . . . . 16 8.3. IKEv2 Session Resumption . . . . . . . . . . . . . . . . 17
8.4. IKEv2 Protocol Support for High Availability . . . . . . 17 8.4. IKEv2 Protocol Support for High Availability . . . . . . 17
8.5. IKEv2 Fragmentation . . . . . . . . . . . . . . . . . . . 17 8.5. IKEv2 Fragmentation . . . . . . . . . . . . . . . . . . . 18
9. Middlebox Considerations . . . . . . . . . . . . . . . . . . 18 9. Middlebox Considerations . . . . . . . . . . . . . . . . . . 18
10. Performance Considerations . . . . . . . . . . . . . . . . . 18 10. Performance Considerations . . . . . . . . . . . . . . . . . 19
10.1. TCP-in-TCP . . . . . . . . . . . . . . . . . . . . . . . 18 10.1. TCP-in-TCP . . . . . . . . . . . . . . . . . . . . . . . 19
10.2. Added Reliability for Unreliable Protocols . . . . . . . 19 10.2. Added Reliability for Unreliable Protocols . . . . . . . 20
10.3. Quality-of-Service Markings . . . . . . . . . . . . . . 19 10.3. Quality-of-Service Markings . . . . . . . . . . . . . . 20
10.4. Maximum Segment Size . . . . . . . . . . . . . . . . . . 20 10.4. Maximum Segment Size . . . . . . . . . . . . . . . . . . 20
10.5. Tunneling ECN in TCP . . . . . . . . . . . . . . . . . . 20 10.5. Tunneling ECN in TCP . . . . . . . . . . . . . . . . . . 20
11. Security Considerations . . . . . . . . . . . . . . . . . . . 20 11. Security Considerations . . . . . . . . . . . . . . . . . . . 21
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
13.1. Normative References . . . . . . . . . . . . . . . . . . 21 13.1. Normative References . . . . . . . . . . . . . . . . . . 22
13.2. Informative References . . . . . . . . . . . . . . . . . 22 13.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. Using TCP Encapsulation with TLS . . . . . . . . . . 23 Appendix A. Using TCP Encapsulation with TLS . . . . . . . . . . 24
Appendix B. Example Exchanges of TCP Encapsulation with TLS 1.3 24 Appendix B. Example Exchanges of TCP Encapsulation with TLS
B.1. Establishing an IKE Session . . . . . . . . . . . . . . . 24 1.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
B.1. Establishing an IKE Session . . . . . . . . . . . . . . . 25
B.2. Deleting an IKE Session . . . . . . . . . . . . . . . . . 26 B.2. Deleting an IKE Session . . . . . . . . . . . . . . . . . 26
B.3. Re-establishing an IKE Session . . . . . . . . . . . . . 27 B.3. Re-establishing an IKE Session . . . . . . . . . . . . . 27
B.4. Using MOBIKE between UDP and TCP Encapsulation . . . . . 27 B.4. Using MOBIKE between UDP and TCP Encapsulation . . . . . 28
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 30 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
The Internet Key Exchange Protocol version 2 (IKEv2) [RFC7296] is a The Internet Key Exchange Protocol version 2 (IKEv2) [RFC7296] is a
protocol for establishing IPsec Security Associations (SAs), using protocol for establishing IPsec Security Associations (SAs), using
IKE messages over UDP for control traffic, and using Encapsulating IKE messages over UDP for control traffic, and using Encapsulating
Security Payload (ESP) [RFC4303] messages for encrypted data traffic. Security Payload (ESP) [RFC4303] messages for encrypted data traffic.
Many network middleboxes that filter traffic on public hotspots block Many network middleboxes that filter traffic on public hotspots block
all UDP traffic, including IKE and IPsec, but allow TCP connections all UDP traffic, including IKE and IPsec, but allow TCP connections
through because they appear to be web traffic. Devices on these through because they appear to be web traffic. Devices on these
skipping to change at page 4, line 15 skipping to change at page 4, line 18
encapsulation only on networks where negotiation over UDP has been encapsulation only on networks where negotiation over UDP has been
attempted without receiving responses from the peer or if a network attempted without receiving responses from the peer or if a network
is known to not support UDP. is known to not support UDP.
1.1. Prior Work and Motivation 1.1. Prior Work and Motivation
Encapsulating IKE connections within TCP streams is a common approach Encapsulating IKE connections within TCP streams is a common approach
to solve the problem of UDP packets being blocked by network to solve the problem of UDP packets being blocked by network
middleboxes. The specific goals of this document are as follows: middleboxes. The specific goals of this document are as follows:
o To promote interoperability by defining a standard method of * To promote interoperability by defining a standard method of
framing IKE and ESP messages within TCP streams. framing IKE and ESP messages within TCP streams.
o To be compatible with the current IKEv2 standard without requiring * To be compatible with the current IKEv2 standard without requiring
modifications or extensions. modifications or extensions.
o To use IKE over UDP by default to avoid the overhead of other * To use IKE over UDP by default to avoid the overhead of other
alternatives that always rely on TCP or Transport Layer Security alternatives that always rely on TCP or Transport Layer Security
(TLS) [RFC5246][RFC8446]. (TLS) [RFC5246][RFC8446].
Some previous alternatives include: Some previous alternatives include:
Cellular Network Access Cellular Network Access
Interworking Wireless LAN (IWLAN) uses IKEv2 to create secure Interworking Wireless LAN (IWLAN) uses IKEv2 to create secure
connections to cellular carrier networks for making voice calls connections to cellular carrier networks for making voice calls
and accessing other network services over Wi-Fi networks. 3GPP has and accessing other network services over Wi-Fi networks. 3GPP has
recommended that IKEv2 and ESP packets be sent within a TLS recommended that IKEv2 and ESP packets be sent within a TLS
skipping to change at page 5, line 41 skipping to change at page 5, line 46
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.
Implementations MUST support TCP encapsulation on TCP port 4500, Implementations MUST support TCP encapsulation on TCP port 4500,
which is reserved for IPsec NAT traversal. which is reserved for IPsec NAT traversal.
Beyond a flag indicating support for TCP encapsulation, the Beyond a flag indicating support for TCP encapsulation, the
configuration for each peer can include the following optional configuration for each peer can include the following optional
parameters: parameters:
o Alternate TCP ports on which the specific TCP Responder listens * Alternate TCP ports on which the specific TCP Responder listens
for incoming connections. Note that the TCP Originator may for incoming connections. Note that the TCP Originator may
initiate TCP connections to the TCP Responder from any local port. initiate TCP connections to the TCP Responder from any local port.
o An extra framing protocol to use on top of TCP to further * An extra framing protocol to use on top of TCP to further
encapsulate the stream of IKE and IPsec packets. See Appendix B encapsulate the stream of IKE and IPsec packets. See Appendix B
for a detailed discussion. for a detailed discussion.
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 SAs (as described in Section 10), implementations SHOULD encapsulated SAs (as described in Section 10), implementations SHOULD
prefer ESP direct or UDP-encapsulated SAs over TCP-encapsulated SAs prefer ESP direct or UDP-encapsulated SAs over TCP-encapsulated SAs
when possible. when possible.
4. TCP-Encapsulated Header Formats 4. TCP-Encapsulated Header Formats
skipping to change at page 6, line 45 skipping to change at page 6, line 49
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Non-ESP Marker | | Non-ESP Marker |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ IKE header [RFC7296] ~ ~ IKE header [RFC7296] ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 Figure 1
The IKE header is preceded by a 16-bit Length field in network byte The IKE header is preceded by a 16-bit Length field in network byte
order that specifies the length of the IKE message (including the order that specifies the length of the IKE message (including the
non-ESP marker) within the TCP stream. As with IKE over UDP port non-ESP marker) within the TCP stream. As with IKE over UDP port
4500, a zeroed 32-bit non-ESP marker is inserted before the start of 4500, a zeroed 32-bit non-ESP marker is inserted before the start of
the IKE header in order to differentiate the traffic from ESP traffic the IKE header in order to differentiate the traffic from ESP traffic
between the same addresses and ports. between the same addresses and ports.
o Length (2 octets, unsigned integer) - Length of the IKE packet, * Length (2 octets, unsigned integer) - Length of the IKE packet,
including the Length field and non-ESP marker. The value in the including the Length field and non-ESP marker. The value in the
Length field MUST NOT be 0 or 1. The receiver MUST treat these Length field MUST NOT be 0 or 1. The receiver MUST treat these
values as fatal errors and MUST close TCP connection. values as fatal errors and MUST close TCP connection.
4.2. TCP-Encapsulated ESP Header Format 4.2. TCP-Encapsulated ESP 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ ESP header [RFC4303] ~ ~ ESP header [RFC4303] ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 Figure 2
The ESP header is preceded by a 16-bit Length field in network byte The ESP header is preceded by a 16-bit Length field in network byte
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 Security Parameter Index (SPI) field [RFC7296] in the ESP header The Security Parameter Index (SPI) field [RFC7296] in the ESP header
MUST NOT be a zero value. MUST NOT be a zero value.
o Length (2 octets, unsigned integer) - Length of the ESP packet, * Length (2 octets, unsigned integer) - Length of the ESP packet,
including the Length field. The value in the Length field MUST including the Length field. The value in the Length field MUST
NOT be 0 or 1. The receiver MUST treat these values as fatal NOT be 0 or 1. The receiver MUST treat these values as fatal
errors and MUST close TCP connection. errors and MUST close TCP connection.
5. TCP-Encapsulated Stream Prefix 5. TCP-Encapsulated Stream Prefix
Each stream of bytes used for IKE and IPsec encapsulation MUST begin Each stream of bytes used for IKE and IPsec encapsulation MUST begin
with a fixed sequence of six 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 value is intended to characters "IKETCP" as ASCII values. This value is intended to
identify and validate that the TCP connection is being used for TCP identify and validate that the TCP connection is being used for TCP
skipping to change at page 8, line 14 skipping to change at page 8, line 18
within the added protocol layer (Appendix B). Although some framing within the added protocol layer (Appendix B). Although some framing
protocols do support negotiating inner protocols, the stream prefix protocols do support negotiating inner protocols, the stream prefix
should always be used in order for implementations to be as generic should always be used in order for implementations to be as generic
as possible and not rely on other framing protocols on top of TCP. as possible and not rely on other framing protocols on top of TCP.
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
6. Applicability 6. 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.
skipping to change at page 11, line 25 skipping to change at page 11, line 30
unreliability of the UDP protocol. In brief, the exchange Initiator unreliability of the UDP protocol. In brief, the exchange Initiator
is responsible for retransmissions and must retransmit requests is responsible for retransmissions and must retransmit requests
message until response message is received. If no reply is received message until response message is received. If no reply is received
after several retransmissions, the SA is deleted. The Responder after several retransmissions, the SA is deleted. The Responder
never initiates retransmission, but must send a response message never initiates retransmission, but must send a response message
again in case it receives a retransmitted request. again in case it receives a retransmitted request.
When IKEv2 uses a reliable transport protocol, like TCP, the When IKEv2 uses a reliable transport protocol, like TCP, the
retransmission rules are as follows: retransmission rules are as follows:
o The exchange Initiator SHOULD NOT retransmit request message; if * The exchange Initiator SHOULD NOT retransmit request message; if
no response is received within some reasonable period of time, the no response is received within some reasonable period of time, the
IKE SA is deleted. IKE SA is deleted.
o If a new TCP connection for the IKE SA is established while the * If a new TCP connection for the IKE SA is established while the
exchange Initiator is waiting for a response, the Initiator MUST exchange Initiator is waiting for a response, the Initiator MUST
retransmit its request over this connection and continue to wait retransmit its request over this connection and continue to wait
for a response. for a response.
o The exchange Responder does not change its behavior, but acts as * The exchange Responder does not change its behavior, but acts as
described in Section 2.1 of [RFC7296]. described in Section 2.1 of [RFC7296].
7.3. Cookies and Puzzles 7.3. Cookies and Puzzles
IKEv2 provides a DoS attack protection mechanism through Cookies, IKEv2 provides a DoS attack protection mechanism through Cookies,
which is described in Section 2.6 of [RFC7296]. [RFC8019] extends which is described in Section 2.6 of [RFC7296]. [RFC8019] extends
this mechanism for protection against DDoS attacks by means of Client this mechanism for protection against DDoS attacks by means of Client
Puzzles. Both mechanisms allow the Responder to avoid keeping state Puzzles. Both mechanisms allow the Responder to avoid keeping state
until the Initiator proves its IP address is legitimate (and after until the Initiator proves its IP address is legitimate (and after
solving a puzzle if required). solving a puzzle if required).
skipping to change at page 12, line 17 skipping to change at page 12, line 24
attack which an IKEv2 Responder cannot prevent using stateless IKEv2 attack which an IKEv2 Responder cannot prevent using stateless IKEv2
Cookies. Thus, when using TCP encapsulation, it makes little sense Cookies. Thus, when using TCP encapsulation, it makes little sense
to send Cookie requests without Puzzles unless the Responder is to send Cookie requests without Puzzles unless the Responder is
concerned with a possibility of TCP Sequence Number attacks (see concerned with a possibility of TCP Sequence Number attacks (see
[RFC6528] for details). Puzzles, on the other hand, still remain [RFC6528] for details). Puzzles, on the other hand, still remain
useful (and their use requires using Cookies). useful (and their use requires using Cookies).
The following considerations are applicable for using Cookie and The following considerations are applicable for using Cookie and
Puzzle mechanisms in case of TCP encapsulation: Puzzle mechanisms in case of TCP encapsulation:
o the exchange Responder SHOULD NOT request a Cookie, with the * the exchange Responder SHOULD NOT request a Cookie, with the
exception of Puzzles or in rare cases like preventing TCP Sequence exception of Puzzles or in rare cases like preventing TCP Sequence
Number attacks. Number attacks.
o if the Responder chooses to send Cookie request (possibly along * if the Responder chooses to send Cookie request (possibly along
with Puzzle request), then the TCP connection that the IKE_SA_INIT with Puzzle request), then the TCP connection that the IKE_SA_INIT
request message was received over SHOULD be closed after the request message was received over SHOULD be closed after the
Responder sends its reply and no repeated requests are received Responder sends its reply and no repeated requests are received
within some short period of time to keep the Responder stateless within some short period of time to keep the Responder stateless
(see Section 7.3.1). Note that the Responder MUST NOT include the (see Section 7.3.1). Note that the Responder MUST NOT include the
Initiator's TCP port into the Cookie calculation (*), since the Initiator's TCP port into the Cookie calculation (*), since the
Cookie can be returned over a new TCP connection with a different Cookie can be returned over a new TCP connection with a different
port. port.
o the exchange Initiator acts as described in Section 2.6 of * the exchange Initiator acts as described in Section 2.6 of
[RFC7296] and Section 7 of [RFC8019], i.e. using TCP encapsulation [RFC7296] and Section 7 of [RFC8019], i.e. using TCP encapsulation
doesn't change the Initiator's behavior. doesn't change the Initiator's behavior.
(*) Examples of Cookie calculation methods are given in Section 2.6 (*) Examples of Cookie calculation methods are given in Section 2.6
of [RFC7296] and in Section 7.1.1.3 of [RFC8019] and they don't of [RFC7296] and in Section 7.1.1.3 of [RFC8019] and they don't
include transport protocol ports. However these examples are given include transport protocol ports. However these examples are given
for illustrative purposes, since Cookie generation algorithm is a for illustrative purposes, since Cookie generation algorithm is a
local matter and some implementations might include port numbers, local matter and some implementations might include port numbers,
that won't work with TCP encapsulation. Note also that these that won't work with TCP encapsulation. Note also that these
examples include the Initiator's IP address in Cookie calculation. examples include the Initiator's IP address in Cookie calculation.
skipping to change at page 16, line 5 skipping to change at page 16, line 22
If the TCP transport was used for the previous network connection, If the TCP transport was used for the previous network connection,
the old TCP connection SHOULD be closed by the Initiator once MOBIKE the old TCP connection SHOULD be closed by the Initiator once MOBIKE
finishes migration to a new connection (either TCP or UDP). finishes migration to a new connection (either TCP or UDP).
Since switching from UDP to TCP can happen during a single Since switching from UDP to TCP can happen during a single
INFORMATIONAL message exchange, the content of the INFORMATIONAL message exchange, the content of the
NAT_DETECTION_SOURCE_IP notification will in most cases be incorrect NAT_DETECTION_SOURCE_IP notification will in most cases be incorrect
(since UDP and TCP source ports will most likely be different), and (since UDP and TCP source ports will most likely be different), and
the peer may incorrectly detect the presence of a NAT. Section 3.5 the peer may incorrectly detect the presence of a NAT. Section 3.5
of [RFC4555] requires that a new INFORMATIONAL exchange with the of [RFC4555] states that a new INFORMATIONAL exchange with the
UPDATE_SA_ADDRESSES notify be initiated in case the address (or UPDATE_SA_ADDRESSES notify is initiated in case the address (or
transport) is changed while waiting for a response. transport) is changed while waiting for a response.
Section 3.5 of [RFC4555] also states that once an IKE SA is switched
to a new IP address, all outstanding requests in this SA are
immediately retransmitted using this address. See also Section 7.2.
The MOBIKE protocol defines the NO_NATS_ALLOWED notification that can The MOBIKE protocol defines the NO_NATS_ALLOWED notification that can
be used to detect the presence of NAT between peer and to refuse to be used to detect the presence of NAT between peer and to refuse to
communicate in this situation. In case of TCP the NO_NATS_ALLOWED communicate in this situation. In case of TCP the NO_NATS_ALLOWED
notification SHOULD be ignored because TCP generally has no problems notification SHOULD be ignored because TCP generally has no problems
with NAT boxes. with NAT boxes.
Section 3.7 of [RFC4555] describes an additional optional step in the Section 3.7 of [RFC4555] describes an additional optional step in the
process of changing IP addresses called Return Routability Check. It process of changing IP addresses called Return Routability Check. It
is performed by Responders in order to be sure that the new is performed by Responders in order to be sure that the new
initiator's address is in fact routable. In case of TCP initiator's address is in fact routable. In case of TCP
skipping to change at page 21, line 21 skipping to change at page 21, line 49
port SHOULD be used for TCP-encapsulated IKE and ESP as described in port SHOULD be used for TCP-encapsulated IKE and ESP as described in
this document. this document.
This document updates the reference for TCP port 4500 from RFC 8229 This document updates the reference for TCP port 4500 from RFC 8229
to itself: to itself:
Keyword Decimal Description Reference Keyword Decimal Description Reference
----------- -------- ------------------- --------- ----------- -------- ------------------- ---------
ipsec-nat-t 4500/tcp IPsec NAT-Traversal [RFCXXXX] ipsec-nat-t 4500/tcp IPsec NAT-Traversal [RFCXXXX]
Figure 4 Figure 4
13. References 13. References
13.1. Normative References 13.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,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets", Stenberg, "UDP Encapsulation of IPsec ESP Packets",
RFC 3948, DOI 10.17487/RFC3948, January 2005, RFC 3948, DOI 10.17487/RFC3948, January 2005,
skipping to change at page 22, line 24 skipping to change at page 22, line 47
<https://www.rfc-editor.org/info/rfc8019>. <https://www.rfc-editor.org/info/rfc8019>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
13.2. Informative References 13.2. Informative References
[I-D.ietf-ipsecme-ike-tcp] [I-D.ietf-ipsecme-ike-tcp]
Nir, Y., "A TCP transport for the Internet Key Exchange", Nir, Y., "A TCP transport for the Internet Key Exchange",
draft-ietf-ipsecme-ike-tcp-01 (work in progress), December Work in Progress, Internet-Draft, draft-ietf-ipsecme-ike-
2012. tcp-01, 3 December 2012, <https://www.ietf.org/archive/id/
draft-ietf-ipsecme-ike-tcp-01.txt>.
[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,
<https://www.rfc-editor.org/info/rfc1122>. <https://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,
<https://www.rfc-editor.org/info/rfc2817>. <https://www.rfc-editor.org/info/rfc2817>.
skipping to change at page 25, line 50 skipping to change at page 26, line 30
Length + Non-ESP Marker ----------> Length + Non-ESP Marker ---------->
final IKE_AUTH final IKE_AUTH
HDR, SK {AUTH} HDR, SK {AUTH}
<------ Length + Non-ESP Marker <------ Length + Non-ESP Marker
final IKE_AUTH final IKE_AUTH
HDR, SK {AUTH, CP(CFG_REPLY), HDR, SK {AUTH, CP(CFG_REPLY),
SA, TSi, TSr, ...} SA, TSi, TSr, ...}
-------------- IKE and IPsec SAs Established ------------ -------------- IKE and IPsec SAs Established ------------
Length + ESP Frame ----------> Length + ESP Frame ---------->
Figure 5 Figure 5
1. The client establishes a TCP connection with the server on port 1. The client establishes a TCP connection with the server on port
4500 or on an alternate pre-configured port that the server is 4500 or on an alternate pre-configured port that the server is
listening on. listening on.
2. If configured to use TLS, the client initiates a TLS handshake. 2. If configured to use TLS, the client initiates a TLS handshake.
During the TLS handshake, the server SHOULD NOT request the During the TLS handshake, the server SHOULD NOT request the
client's certificate, since authentication is handled as part of client's certificate, since authentication is handled as part of
IKE negotiation. IKE negotiation.
skipping to change at page 26, line 45 skipping to change at page 27, line 26
2) --------------------- TLS Session --------------------- 2) --------------------- TLS Session ---------------------
close_notify ----------> close_notify ---------->
<---------- close_notify <---------- close_notify
3) -------------------- TCP Connection ------------------- 3) -------------------- TCP Connection -------------------
TcpFin ----------> TcpFin ---------->
<---------- Ack <---------- Ack
<---------- TcpFin <---------- TcpFin
Ack ----------> Ack ---------->
-------------------- IKE SA Deleted ------------------- -------------------- IKE SA Deleted -------------------
Figure 6 Figure 6
1. The client and server exchange informational messages to notify 1. The client and server exchange informational messages to notify
IKE SA deletion. IKE SA deletion.
2. The client and server negotiate TLS session deletion using TLS 2. The 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.
The deletion of the IKE SA should lead to the disposal of the The deletion of the IKE SA should lead to the disposal of the
skipping to change at page 27, line 11 skipping to change at page 28, line 4
2. The client and server negotiate TLS session deletion using TLS 2. The 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.
The deletion of the IKE SA should lead to the disposal of the The deletion of the IKE SA should lead to the disposal of the
underlying TLS and TCP state. 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:Port_R) (IP_I:Port_I -> IP_R:Port_R)
TcpSyn ----------> TcpSyn ---------->
<---------- TcpSyn,Ack <---------- TcpSyn,Ack
TcpAck ----------> TcpAck ---------->
2) --------------------- TLS Session --------------------- 2) --------------------- TLS Session ---------------------
ClientHello ----------> ClientHello ---------->
ServerHello ServerHello
{EncryptedExtensions} {EncryptedExtensions}
<---------- {Finished} <---------- {Finished}
{Finished} ----------> {Finished} ---------->
3) ---------------------- Stream Prefix -------------------- 3) ---------------------- Stream Prefix --------------------
"IKETCP" ----------> "IKETCP" ---------->
4) <---------------------> IKE/ESP Flow <------------------> 4) <---------------------> IKE/ESP Flow <------------------>
Figure 7 Figure 7
1. If a previous TCP connection was broken (for example, due to a 1. If a previous TCP connection was broken (for example, due to a
TCP Reset), the client is responsible for re-initiating the TCP TCP Reset), the client is responsible for re-initiating the TCP
connection. The TCP Originator's address and port (IP_I and connection. The TCP Originator's address and port (IP_I and
Port_I) may be different from the previous connection's address Port_I) may be different from the previous connection's address
and port. and port.
2. The client SHOULD attempt TLS session resumption if it has 2. The client SHOULD attempt TLS session resumption if it has
previously established a session with the server. previously established a session with the server.
skipping to change at page 29, line 19 skipping to change at page 30, line 12
HDR, SK { N(UPDATE_SA_ADDRESSES), HDR, SK { N(UPDATE_SA_ADDRESSES),
N(NAT_DETECTION_SOURCE_IP), N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) } N(NAT_DETECTION_DESTINATION_IP) }
<------- Length + Non-ESP Marker <------- Length + Non-ESP Marker
HDR, SK { N(NAT_DETECTION_SOURCE_IP), HDR, SK { N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) } N(NAT_DETECTION_DESTINATION_IP) }
8) <---------------------> IKE/ESP Flow <------------------> 8) <---------------------> IKE/ESP Flow <------------------>
Figure 8 Figure 8
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. MOBIKE_SUPPORTED notify payloads to indicate support for 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, but the IKE session using the UPDATE_SA_ADDRESSES notify payload, but
the server does not respond because the network blocks UDP the server does not respond because the network blocks UDP
traffic. traffic.
skipping to change at page 29, line 44 skipping to change at page 30, line 37
5. The client sends the stream prefix for TCP-encapsulated IKE 5. The client sends the stream prefix for TCP-encapsulated IKE
traffic (Section 5). traffic (Section 5).
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. Note that this IKE message is the TCP-encapsulated connection. Note that this IKE message is the
same as the one sent over UDP in step 2; it should have the same same as the one sent over UDP in step 2; it should have the same
message ID and contents. message ID and contents.
7. Once the client receives a response on the TCP-encapsulated 7. Once the client receives a response on the TCP-encapsulated
connection, it immediately start new INFORMATIONAL exchange with connection, it immediately starts a new INFORMATIONAL exchange
UPDATE_SA_ADDRESSES notify payload and recalculated with an UPDATE_SA_ADDRESSES notify payload and a recalculated
NAT_DETECTION_* notify payloads to get correct information about NAT_DETECTION_SOURCE_IP notify payload in order to get correct
the precense of NAT. information about the presence of NATs.
8. The IKE and ESP packet flow can resume. 8. The IKE and ESP packet flow can resume.
Acknowledgments Acknowledgments
Thanks to the original authors of RFC 8229, Tommy Pauly, Samy Touati, Thanks to the original authors of RFC 8229, Tommy Pauly, Samy Touati,
and Ravi Mantha. Since this document updates and obsoletes RFC 8229, and Ravi Mantha. Since this document updates and obsoletes RFC 8229,
most of its text was borrowed from the original document. most of its text was borrowed from the original document.
The following people provided valuable feedback and advices while The following people provided valuable feedback and advices while
skipping to change at page 30, line 26 skipping to change at page 31, line 20
work. work.
The authors would like to thank Tero Kivinen and Paul Wouters for The authors would like to thank Tero Kivinen and Paul Wouters for
their valuable comments while preparing this document. their valuable comments while preparing this document.
Authors' Addresses Authors' Addresses
Valery Smyslov Valery Smyslov
ELVIS-PLUS ELVIS-PLUS
PO Box 81 PO Box 81
Moscow (Zelenograd) 124460 Moscow (Zelenograd)
124460
Russian Federation Russian Federation
Phone: +7 495 276 0211 Phone: +7 495 276 0211
Email: svan@elvis.ru Email: svan@elvis.ru
Tommy Pauly Tommy Pauly
Apple Inc. Apple Inc.
1 Infinite Loop 1 Infinite Loop
Cupertino, California 95014 Cupertino, California 95014,
United States of America United States of America
Email: tpauly@apple.com Email: tpauly@apple.com
 End of changes. 45 change blocks. 
61 lines changed or deleted 64 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/