< draft-ietf-ipsecme-rfc8229bis-01.txt   draft-ietf-ipsecme-rfc8229bis-02.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: April 28, 2022 October 25, 2021 Expires: July 23, 2022 January 19, 2022
TCP Encapsulation of IKE and IPsec Packets TCP Encapsulation of IKE and IPsec Packets
draft-ietf-ipsecme-rfc8229bis-01 draft-ietf-ipsecme-rfc8229bis-02
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
negotiated over UDP. negotiated over UDP.
TCP encapsulation for IKE and IPsec was defined in [RFC8229]. This TCP encapsulation for IKE and IPsec was defined in [RFC8229]. This
document updates specification for TCP encapsulation by including document updates the specification for TCP encapsulation by including
additional clarifications obtained during implementation and additional clarifications obtained during implementation and
deployment of this method. This documents makes RFC8229 obsolete. deployment of this method. This documents makes RFC8229 obsolete.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 April 28, 2022. This Internet-Draft will expire on July 23, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 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/license-info) in effect on the date of (https://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified 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 . . . . . . . . . . . . . . . . . . 4 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.4. Error Handling in IKE_SA_INIT . . . . . . . . . . . . . . 12 7.3.1. Statelessness versus Delay of SA Establishment . . . 12
7.4. Error Handling in IKE_SA_INIT . . . . . . . . . . . . . . 13
7.5. NAT Detection Payloads . . . . . . . . . . . . . . . . . 13 7.5. NAT Detection Payloads . . . . . . . . . . . . . . . . . 13
7.6. Keep-Alives and Dead Peer Detection . . . . . . . . . . . 13 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 14
8. Interaction with IKEv2 Extensions . . . . . . . . . . . . . . 14 8. Interaction with IKEv2 Extensions . . . . . . . . . . . . . . 15
8.1. MOBIKE Protocol . . . . . . . . . . . . . . . . . . . . . 14 8.1. MOBIKE Protocol . . . . . . . . . . . . . . . . . . . . . 15
8.2. IKE Redirect . . . . . . . . . . . . . . . . . . . . . . 15 8.2. IKE Redirect . . . . . . . . . . . . . . . . . . . . . . 16
8.3. IKEv2 Session Resumption . . . . . . . . . . . . . . . . 16 8.3. IKEv2 Session Resumption . . . . . . . . . . . . . . . . 16
8.4. IKEv2 Protocol Support for High Availability . . . . . . 16 8.4. IKEv2 Protocol Support for High Availability . . . . . . 17
8.5. IKEv2 Fragmentation . . . . . . . . . . . . . . . . . . . 17 8.5. IKEv2 Fragmentation . . . . . . . . . . . . . . . . . . . 17
9. Middlebox Considerations . . . . . . . . . . . . . . . . . . 17 9. Middlebox Considerations . . . . . . . . . . . . . . . . . . 18
10. Performance Considerations . . . . . . . . . . . . . . . . . 17 10. Performance Considerations . . . . . . . . . . . . . . . . . 18
10.1. TCP-in-TCP . . . . . . . . . . . . . . . . . . . . . . . 17 10.1. TCP-in-TCP . . . . . . . . . . . . . . . . . . . . . . . 18
10.2. Added Reliability for Unreliable Protocols . . . . . . . 18 10.2. Added Reliability for Unreliable Protocols . . . . . . . 19
10.3. Quality-of-Service Markings . . . . . . . . . . . . . . 19 10.3. Quality-of-Service Markings . . . . . . . . . . . . . . 19
10.4. Maximum Segment Size . . . . . . . . . . . . . . . . . . 19 10.4. Maximum Segment Size . . . . . . . . . . . . . . . . . . 20
10.5. Tunneling ECN in TCP . . . . . . . . . . . . . . . . . . 19 10.5. Tunneling ECN in TCP . . . . . . . . . . . . . . . . . . 20
11. Security Considerations . . . . . . . . . . . . . . . . . . . 19 11. Security Considerations . . . . . . . . . . . . . . . . . . . 20
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
13.1. Normative References . . . . . . . . . . . . . . . . . . 20 13.1. Normative References . . . . . . . . . . . . . . . . . . 21
13.2. Informative References . . . . . . . . . . . . . . . . . 21 13.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. Using TCP Encapsulation with TLS . . . . . . . . . . 24
Appendix A. Using TCP Encapsulation with TLS . . . . . . . . . . 23
Appendix B. Example Exchanges of TCP Encapsulation with TLS 1.3 24 Appendix B. Example Exchanges of TCP Encapsulation with TLS 1.3 24
B.1. Establishing an IKE Session . . . . . . . . . . . . . . . 24 B.1. Establishing an IKE Session . . . . . . . . . . . . . . . 24
B.2. Deleting an IKE Session . . . . . . . . . . . . . . . . . 25 B.2. Deleting an IKE Session . . . . . . . . . . . . . . . . . 26
B.3. Re-establishing an IKE Session . . . . . . . . . . . . . 26 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 . . . . . . . . . . . . . . . . . . . . . . . . . 29 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
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 12, line 21 skipping to change at page 12, line 22
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 o 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 o 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, so that the request message was received over SHOULD be closed after the
Responder remains stateless at least until the Cookie (or Puzzle Responder sends its reply and no repeated requests are received
Solution) is returned. Note that if this TCP connection is within some short period of time to keep the Responder stateless
closed, the Responder MUST NOT include the Initiator's TCP port (see Section 7.3.1). Note that the Responder MUST NOT include the
into the Cookie calculation (*), since the Cookie will be returned Initiator's TCP port into the Cookie calculation (*), since the
over a new TCP connection with a different port. Cookie can be returned over a new TCP connection with a different
port.
o the exchange Initiator acts as described in Section 2.6 of o 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.
In general this address may change between two initial requests (with In general this address may change between two initial requests (with
and without Cookies). This may happen due to NATs, since NATs have and without Cookies). This may happen due to NATs, since NATs have
more freedom to change change source IP addresses for new TCP more freedom to change change source IP addresses for new TCP
connections than for UDP. In such cases cookie verification might connections than for UDP. In such cases cookie verification might
fail. fail.
7.3.1. Statelessness versus Delay of SA Establishment
There is a trade-off in choosing the period of time after which TCP
connection is closed. If it is too short, then the proper Initiator
which repeats its request would need to re-establish the TCP
connection introducing additional delay. On the other hand, if it is
too long, then the Responder's resources would be wasted in case the
Initiator never comes back. This document doesn't specify the
duration of time, because it doesn't affect interoperability, but it
is believed that 5-10 seconds is a good compromise. Note also, that
if the Responder requests the Initiator to solve a puzzle, then the
Responder can estimate how long it would take the Initiator to find a
solution and adjust the time interval accordingly.
7.4. Error Handling in IKE_SA_INIT 7.4. Error Handling in IKE_SA_INIT
Section 2.21.1 of [RFC7296] describes how error notifications are Section 2.21.1 of [RFC7296] describes how error notifications are
handled in the IKE_SA_INIT exchange. In particular, it is advised handled in the IKE_SA_INIT exchange. In particular, it is advised
that the Initiator should not act immediately after receiving error that the Initiator should not act immediately after receiving error
notification and should instead wait some time for valid response, notification and should instead wait some time for valid response,
since the IKE_SA_INIT messages are completely unauthenticated. This since the IKE_SA_INIT messages are completely unauthenticated. This
advice does not apply equally in case of TCP encapsulation. If the advice does not apply equally in case of TCP encapsulation. If the
Initiator receives a response message over TCP, then either this Initiator receives a response message over TCP, then either this
message is genuine and was sent by the peer, or the TCP session was message is genuine and was sent by the peer, or the TCP session was
hijacked and the message is forged. In this latter case, no genuine hijacked and the message is forged. In this latter case, no genuine
messages from the Responder will be received. messages from the Responder will be received.
Thus, in case of TCP encapsulation, an Initiator SHOULD NOT wait for Thus, in case of TCP encapsulation, an Initiator SHOULD NOT wait for
additional messages in case it receives error notification from the additional messages in case it receives error notification from the
Responder in the IKE_SA_INIT exchange. Responder in the IKE_SA_INIT exchange.
If in the IKE_SA_INIT exchange the Responder returns an error
notification that implies a recovery action from the Initiator (such
as INVALID_KE_PAYLOAD or INVALID_MAJOR_VERSION, see Section 2.21.1 of
[RFC7296]) then the Responder SHOULD NOT close the TCP connection
immediately, in anticipation that the Initiator will repeat the
request with corrected parameters. See also Section 7.3.
7.5. NAT Detection Payloads 7.5. 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 as defined in [RFC7296]. IKE_SA_INIT packets sent on a TCP ports as defined in [RFC7296]. IKE_SA_INIT packets sent on a TCP
connection SHOULD include these payloads with the same content as connection SHOULD include these payloads with the same content as
when sending over UDP and SHOULD use the applicable TCP ports when when sending over UDP and SHOULD use the applicable TCP ports when
creating and checking the SHA-1 digests. creating and checking the SHA-1 digests.
skipping to change at page 14, line 5 skipping to change at page 14, line 29
port mappings, so IPsec ESP NAT keep-alives [RFC3948] SHOULD NOT be port mappings, so IPsec ESP NAT keep-alives [RFC3948] SHOULD NOT be
sent when using TCP encapsulation. Any implementation using TCP sent when using TCP encapsulation. Any implementation using TCP
encapsulation MUST silently drop incoming NAT keep-alive packets and encapsulation MUST silently drop incoming NAT keep-alive packets and
not treat them as errors. NAT keep-alive packets over a TCP- not treat them as errors. NAT keep-alive packets over a TCP-
encapsulated IPsec connection will be sent as an ESP message with a encapsulated IPsec connection will be sent as an ESP message with a
one-octet-long payload with the value 0xFF. one-octet-long payload with the value 0xFF.
Note that, depending on the configuration of TCP and TLS on the Note that, depending on the configuration of TCP and TLS on the
connection, TCP keep-alives [RFC1122] and TLS keep-alives [RFC6520] connection, TCP keep-alives [RFC1122] and TLS keep-alives [RFC6520]
may be used. These MUST NOT be used as indications of IKE peer may be used. These MUST NOT be used as indications of IKE peer
liveness. liveness, for which purpose the standard IKEv2 mechanism of
exchanging empty INFORMATIONAL messages is used (see Section 1.4 of
[RFC7296]).
7.7. Implications of TCP Encapsulation on IPsec SA Processing 7.7. Implications of TCP Encapsulation on IPsec SA Processing
Using TCP encapsulation affects some aspects of IPsec SA processing. Using TCP encapsulation affects some aspects of IPsec SA processing.
1. Section 8.1 of [RFC4301] requires all tunnel mode IPsec SAs to be 1. Section 8.1 of [RFC4301] requires all tunnel mode IPsec SAs to be
able to copy the Don't Fragment (DF) bit from inner IP header to able to copy the Don't Fragment (DF) bit from inner IP header to
the outer (tunnel) one. With TCP encapsulation this is generally the outer (tunnel) one. With TCP encapsulation this is generally
not possible, because TCP/IP stack manages DF bit in the outer IP not possible, because TCP/IP stack manages DF bit in the outer IP
header, and usually the stack ensures that the DF bit is set for header, and usually the stack ensures that the DF bit is set for
skipping to change at page 14, line 39 skipping to change at page 15, line 17
each of them. each of them.
Besides, TCP encapsulation of IPsec packets may have implications on Besides, TCP encapsulation of IPsec packets may have implications on
performance of the encapsulated traffic. Performance considerations performance of the encapsulated traffic. Performance considerations
are discussed in Section 10. are discussed in Section 10.
8. Interaction with IKEv2 Extensions 8. Interaction with IKEv2 Extensions
8.1. MOBIKE Protocol 8.1. MOBIKE Protocol
MOBIKE protocol, that allows IKEv2 SA to migrate between IP The MOBIKE protocol, which allows SAs to migrate between IP
addresses, is defined in [RFC4555], and [RFC4621] further clarifies addresses, is defined in [RFC4555], and [RFC4621] further clarifies
the details of the protocol. When an IKE session that has negotiated the details of the protocol. When an IKE session that has negotiated
MOBIKE is transitioning between networks, the Initiator of the MOBIKE is transitioning between networks, the Initiator of the
transition may switch between using TCP encapsulation, UDP transition may switch between using TCP encapsulation, UDP
encapsulation, or no encapsulation. Implementations that implement encapsulation, or no encapsulation. Implementations that implement
both MOBIKE and TCP encapsulation MUST support dynamically enabling both MOBIKE and TCP encapsulation within the same connection
and disabling TCP encapsulation as interfaces change. configuration MUST support dynamically enabling and disabling TCP
encapsulation as interfaces change.
When a MOBIKE-enabled Initiator changes networks, the INFORMATIONAL When a MOBIKE-enabled Initiator changes networks, the INFORMATIONAL
exchange with the UPDATE_SA_ADDRESSES notification SHOULD be exchange with the UPDATE_SA_ADDRESSES notification SHOULD be
initiated first over UDP before attempting over TCP. If there is a initiated first over UDP before attempting over TCP. If there is a
response to the request sent over UDP, then the ESP packets should be response to the request sent over UDP, then the ESP packets should be
sent directly over IP or over UDP port 4500 (depending on if a NAT sent directly over IP or over UDP port 4500 (depending on if a NAT
was detected), regardless of if a connection on a previous network was detected), regardless of if a connection on a previous network
was using TCP encapsulation. If no response is received within a was using TCP encapsulation. If no response is received within a
certain period of time after several retransmissions, the Initiator certain period of time after several retransmissions, the Initiator
ought to change its transport for this exchange from UDP to TCP and ought to change its transport for this exchange from UDP to TCP and
resend the request message. New INFORMATIONAL exchange MUST NOT be resend the request message. A new INFORMATIONAL exchange MUST NOT be
started in this situation. If the Responder only responds to the started in this situation. If the Responder only responds to the
request sent over TCP, then the ESP packets should be sent over the request sent over TCP, then the ESP packets should be sent over the
TCP connection, regardless of if a connection on a previous network TCP connection, regardless of if a connection on a previous network
did not use TCP encapsulation. did not use TCP encapsulation.
Since switching from UDP to TCP happens can occur 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. This should the peer may incorrectly detect the presence of a NAT. This should
not cause functional issues since all messages will be encapsulated not cause functional issues since all messages will be encapsulated
in TCP anyway, and TCP encapsulation does not change based on the in TCP anyway, and TCP encapsulation does not change based on the
presence of NATs. presence of NATs.
MOBIKE protocol defined the NO_NATS_ALLOWED notification that can be The MOBIKE protocol defines the NO_NATS_ALLOWED notification that can
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
encapsulation this check has little value, since TCP handshake proves encapsulation this check has little value, since TCP handshake proves
routability of the TCP Originator's address. So, in case of TCP routability of the TCP Originator's address. So, in case of TCP
skipping to change at page 16, line 14 skipping to change at page 16, line 41
8.3. IKEv2 Session Resumption 8.3. IKEv2 Session Resumption
Session resumption for IKEv2 is defined in [RFC5723]. Once an IKE SA Session resumption for IKEv2 is defined in [RFC5723]. Once an IKE SA
is established, the server creates a resumption ticket where is established, the server creates a resumption ticket where
information about this SA is stored, and transfers this ticket to the information about this SA is stored, and transfers this ticket to the
client. The ticket may be later used to resume the IKE SA after it client. The ticket may be later used to resume the IKE SA after it
is deleted. In the event of resumption the client presents the is deleted. In the event of resumption the client presents the
ticket in a new exchange, called IKE_SESSION_RESUME. Some parameters ticket in a new exchange, called IKE_SESSION_RESUME. Some parameters
in the new SA are retrieved from the ticket and others are re- in the new SA are retrieved from the ticket and others are re-
negotiated (more details are given in Section 5 of [RFC5723]). If negotiated (more details are given in Section 5 of [RFC5723]).
TCP encapsulation was used in an old SA, then the client SHOULD
resume this SA using TCP, without first trying to connect over UDP. Since network conditions may change while the client is incative, the
fact that TCP encapsulation was used in an old SA SHOULD NOT affect
which transport is used during session resumption. In other words,
the transport should be selected as if the IKE SA is being created
from scratch.
8.4. IKEv2 Protocol Support for High Availability 8.4. IKEv2 Protocol Support for High Availability
[RFC6311] defines a support for High Availability in IKEv2. In case [RFC6311] defines a support for High Availability in IKEv2. In case
of cluster failover, a new active node must immediately initiate a of cluster failover, a new active node must immediately initiate a
special INFORMATION exchange containing the IKEV2_MESSAGE_ID_SYNC special INFORMATION exchange containing the IKEV2_MESSAGE_ID_SYNC
notification, which instructs the client to skip some number of notification, which instructs the client to skip some number of
Message IDs that might not be synchronized yet between nodes at the Message IDs that might not be synchronized yet between nodes at the
time of failover. time of failover.
skipping to change at page 29, line 31 skipping to change at page 29, line 42
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. The IKE and ESP packet flow can resume. 7. The IKE and ESP packet flow can resume.
Acknowledgments Acknowledgments
Thanks to the original authors of RFC8229, Tommy Pauly, Samy Touati,
and Ravi Mantha. Since this document updates and obsoletes RFC 8229,
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
preparing RFC8229: Stuart Cheshire, Delziel Fernandes, Yoav Nir, preparing RFC8229: Stuart Cheshire, Delziel Fernandes, Yoav Nir,
Christoph Paasch, Yaron Sheffer, David Schinazi, Graham Bartlett, Christoph Paasch, Yaron Sheffer, David Schinazi, Graham Bartlett,
Byju Pularikkal, March Wu, Kingwel Xie, Valery Smyslov, Jun Hu, and Byju Pularikkal, March Wu, Kingwel Xie, Valery Smyslov, Jun Hu, and
Tero Kivinen. Special thanks to Eric Kinnear for his implementation Tero Kivinen. Special thanks to Eric Kinnear for his implementation
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.
 End of changes. 25 change blocks. 
46 lines changed or deleted 79 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/