< draft-ietf-ipsecme-rfc8229bis-02.txt   draft-ietf-ipsecme-rfc8229bis-03.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: July 23, 2022 January 19, 2022 Expires: September 23, 2022 March 22, 2022
TCP Encapsulation of IKE and IPsec Packets TCP Encapsulation of IKE and IPsec Packets
draft-ietf-ipsecme-rfc8229bis-02 draft-ietf-ipsecme-rfc8229bis-03
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 RFC 8229. This
document updates the 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 obsoletes RFC 8229.
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 July 23, 2022. This Internet-Draft will expire on September 23, 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/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
skipping to change at page 2, line 31 skipping to change at page 2, line 31
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 . . . 12 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 . . . . . . . . . . . . . . . . . 13
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 14
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 . . . . . . . . . . . . . . . . 16
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 . . . . . . . . . . . . . . . . . . . 17
skipping to change at page 3, line 5 skipping to change at page 3, line 5
10.1. TCP-in-TCP . . . . . . . . . . . . . . . . . . . . . . . 18 10.1. TCP-in-TCP . . . . . . . . . . . . . . . . . . . . . . . 18
10.2. Added Reliability for Unreliable Protocols . . . . . . . 19 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 . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . 20
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
13.1. Normative References . . . . . . . . . . . . . . . . . . 21 13.1. Normative References . . . . . . . . . . . . . . . . . . 21
13.2. Informative References . . . . . . . . . . . . . . . . . 22 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 . . . . . . . . . . . . . . . . . 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 . . . . . 28 B.4. Using MOBIKE between UDP and TCP Encapsulation . . . . . 27
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 29 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 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
skipping to change at page 5, line 5 skipping to change at page 4, line 48
deployed that send IPsec traffic over TCP or TCP-like packets. deployed that send IPsec traffic over TCP or TCP-like packets.
Secure Sockets Layer (SSL) VPNs Secure Sockets Layer (SSL) VPNs
Many proprietary VPN solutions use a combination of TLS and IPsec Many proprietary VPN solutions use a combination of TLS and IPsec
in order to provide reliability. These often run on TCP port 443. in order to provide reliability. These often run on TCP port 443.
IKEv2 over TCP IKEv2 over TCP
IKEv2 over TCP as described in [I-D.ietf-ipsecme-ike-tcp] is used IKEv2 over TCP as described in [I-D.ietf-ipsecme-ike-tcp] is used
to avoid UDP fragmentation. to avoid UDP fragmentation.
TCP encapsulation for IKE and IPsec was defined in [RFC8229]. This
document updates the specification for TCP encapsulation by including
additional clarifications obtained during implementation and
deployment of this method.
2. Terminology and Notation 2. Terminology and Notation
This document distinguishes between the IKE peer that initiates TCP This document distinguishes between the IKE peer that initiates TCP
connections to be used for TCP encapsulation and the roles of connections to be used for TCP encapsulation and the roles of
Initiator and Responder for particular IKE messages. During the Initiator and Responder for particular IKE messages. During the
course of IKE exchanges, the role of IKE Initiator and Responder may course of IKE exchanges, the role of IKE Initiator and Responder may
swap for a given SA (as with IKE SA rekeys), while the Initiator of swap for a given SA (as with IKE SA rekeys), while the Initiator of
the TCP connection is still responsible for tearing down the TCP the TCP connection is still responsible for tearing down the TCP
connection and re-establishing it if necessary. For this reason, connection and re-establishing it if necessary. For this reason,
this document will use the term "TCP Originator" to indicate the IKE this document will use the term "TCP Originator" to indicate the IKE
skipping to change at page 11, line 25 skipping to change at page 11, line 25
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 o 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 TCP connection is broken and reestablished while the exchange o If a new TCP connection for the IKE SA is established while the
Initiator is waiting for a response, the Initiator MUST retransmit exchange Initiator is waiting for a response, the Initiator MUST
its request and continue to wait for a response. retransmit its request over this connection and continue to wait
for a response.
o the exchange Responder does not change its behavior, but acts as o 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 14, line 4 skipping to change at page 14, line 8
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.
If a NAT is detected due to the SHA-1 digests not matching the If a NAT is detected due to the SHA-1 digests not matching the
expected values, no change should be made for encapsulation of expected values, no change should be made for encapsulation of
subsequent IKE or ESP packets, since TCP encapsulation inherently subsequent IKE or ESP packets, since TCP encapsulation inherently
supports NAT traversal. Implementations MAY use the information that supports NAT traversal. However, for the transport mode IPsec SAs,
a NAT is present to influence keep-alive timer values. implementations need to handle TCP and UDP packet checksum fixup
during decapsulation, as defined for UDP encapsulation in [RFC3948].
If a NAT is detected, implementations need to handle transport mode Implementations MAY use the information that a NAT is present to
TCP and UDP packet checksum fixup as defined for UDP encapsulation in influence keep-alive timer values.
[RFC3948].
7.6. Keep-Alives and Dead Peer Detection 7.6. Keep-Alives and Dead Peer Detection
Encapsulating IKE and IPsec inside of a TCP connection can impact the Encapsulating IKE and IPsec inside of a TCP connection can impact the
strategy that implementations use to detect peer liveness and to strategy that implementations use to detect peer liveness and to
maintain middlebox port mappings. Peer liveness should be checked maintain middlebox port mappings. Peer liveness should be checked
using IKE informational packets [RFC7296]. using IKE informational packets [RFC7296].
In general, TCP port mappings are maintained by NATs longer than UDP In general, TCP port mappings are maintained by NATs longer than UDP
port mappings, so IPsec ESP NAT keep-alives [RFC3948] SHOULD NOT be port mappings, so IPsec ESP NAT keep-alives [RFC3948] SHOULD NOT be
skipping to change at page 15, line 6 skipping to change at page 15, line 8
2. The other feature that is less applicable with TCP encapsulation 2. The other feature that is less applicable with TCP encapsulation
is an ability to split traffic of different QoS classes into is an ability to split traffic of different QoS classes into
different IPsec SAs, created by a single IKE SA. In this case different IPsec SAs, created by a single IKE SA. In this case
the Differentiated Services Code Point (DSCP) field is usually the Differentiated Services Code Point (DSCP) field is usually
copied from the inner IP header to the outer (tunnel) one, copied from the inner IP header to the outer (tunnel) one,
ensuring that IPsec traffic of each SA receives the corresponding ensuring that IPsec traffic of each SA receives the corresponding
level of service. With TCP encapsulation all IPsec SAs created level of service. With TCP encapsulation all IPsec SAs created
by a single IKE SA will share a single TCP connection and thus by a single IKE SA will share a single TCP connection and thus
will receive the same level of service (see Section 10.3). If will receive the same level of service (see Section 10.3). If
this functionality is needed, implementations should create this functionality is needed, implementations should create
several IKE SAs over TCP and assign a corresponding DSCP value to several IKE SAs each over separate TCP connection and assign a
each of them. corresponding DSCP value to 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
The MOBIKE protocol, which allows SAs to migrate between IP The MOBIKE protocol, which allows SAs to migrate between IP
skipping to change at page 15, line 42 skipping to change at page 15, line 44
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. A 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.
If the TCP transport was used for the previous network connection,
the old TCP connection SHOULD be closed by the Initiator once MOBIKE
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. This should the peer may incorrectly detect the presence of a NAT. Section 3.5
not cause functional issues since all messages will be encapsulated of [RFC4555] requires that a new INFORMATIONAL exchange with the
in TCP anyway, and TCP encapsulation does not change based on the UPDATE_SA_ADDRESSES notify be initiated in case the address (or
presence of NATs. transport) is changed while waiting for a response.
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
skipping to change at page 21, line 8 skipping to change at page 21, line 8
handle changes to source address and port due to network or handle changes to source address and port due to network or
connection disruption. The successful delivery of valid IKE or ESP connection disruption. The successful delivery of valid IKE or ESP
messages over a new TCP connection is used by the TCP Responder to messages over a new TCP connection is used by the TCP Responder to
determine where to send subsequent responses. If an attacker is able determine where to send subsequent responses. If an attacker is able
to send packets on a new TCP connection that pass the validation to send packets on a new TCP connection that pass the validation
checks of the TCP Responder, it can influence which path future checks of the TCP Responder, it can influence which path future
packets will take. For this reason, the validation of messages on packets will take. For this reason, the validation of messages on
the TCP Responder must include decryption, authentication, and replay the TCP Responder must include decryption, authentication, and replay
checks. checks.
Since TCP provides reliable, in-order delivery of ESP messages, the
ESP anti-replay window size SHOULD be set to 1. See [RFC4303] for a
complete description of the ESP anti-replay window. This increases
the protection of implementations against replay attacks.
12. IANA Considerations 12. IANA Considerations
TCP port 4500 is already allocated to IPsec for NAT traversal. This TCP port 4500 is already allocated to IPsec for NAT traversal. This
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
skipping to change at page 27, line 31 skipping to change at page 27, line 28
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 <------------------>
Length + ESP Frame ---------->
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
skipping to change at page 28, line 51 skipping to change at page 28, line 43
ServerHello ServerHello
{EncryptedExtensions} {EncryptedExtensions}
{Certificate*} {Certificate*}
{CertificateVerify*} {CertificateVerify*}
<---------- {Finished} <---------- {Finished}
{Finished} ----------> {Finished} ---------->
5) ---------------------- Stream Prefix -------------------- 5) ---------------------- Stream Prefix --------------------
"IKETCP" ----------> "IKETCP" ---------->
6) ----------------------- IKE Session --------------------- 6) ------------ Retransmit Message from step 2 -------------
Length + Non-ESP Marker -----------> Length + Non-ESP Marker ----------->
INFORMATIONAL (Same as step 2) INFORMATIONAL
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) }
7) <----------------- IKE/ESP Data Flow ------------------->
7) ---- New Exchange with recalculated NAT_DETECTION_* ----
Length + Non-ESP Marker ----------->
INFORMATIONAL
HDR, SK { N(UPDATE_SA_ADDRESSES),
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) }
<------- Length + Non-ESP Marker
HDR, SK { N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) }
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
skipping to change at page 29, line 38 skipping to change at page 29, line 43
4. The client initiates a TLS handshake with the server. 4. The client initiates a TLS handshake with the server.
5. The client sends the stream prefix for TCP-encapsulated IKE 5. The client sends the stream prefix for TCP-encapsulated IKE
traffic (Section 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. The IKE and ESP packet flow can resume. 7. Once the client receives a response on the TCP-encapsulated
connection, it immediately start new INFORMATIONAL exchange with
UPDATE_SA_ADDRESSES notify payload and recalculated
NAT_DETECTION_* notify payloads to get correct information about
the precense of NAT.
8. The IKE and ESP packet flow can resume.
Acknowledgments Acknowledgments
Thanks to the original authors of RFC8229, 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
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.
 End of changes. 23 change blocks. 
37 lines changed or deleted 58 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/