TCP Encapsulation of IKE and IPsec Packets
draft-ietf-ipsecme-tcp-encaps-05
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 8229.
|
|
|---|---|---|---|
| Authors | Tommy Pauly , Samy Touati , Ravi Mantha | ||
| Last updated | 2017-01-23 | ||
| Replaces | draft-pauly-ipsecme-tcp-encaps | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews |
TSVART Last Call review
(of
-09)
by Wesley Eddy
On the Right Track
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | In WG Last Call | |
| Document shepherd | Tero Kivinen | ||
| IESG | IESG state | Became RFC 8229 (Proposed Standard) | |
| Consensus boilerplate | Yes | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | "Tero Kivinen" <kivinen@iki.fi> |
draft-ietf-ipsecme-tcp-encaps-05
lt;------------------>
Length + ESP frame ---------->
Figure 6
1. If a previous TCP connection was broken (for example, due to a
RST), the client is responsible for re-initiating the TCP
connection. The initiator's address and port (IP_I and Port_I)
may be different from the previous connection's address and
port.
2. In ClientHello TLS message, the client SHOULD send the Session
ID it received in the previous TLS handshake if available. It
is up to the server to perform either an abbreviated handshake
or full handshake based on the session ID match.
3. After TCP and TLS are complete, the client sends the Stream
Prefix for TCP encapsulated IKE traffic [Section 4].
4. The IKE and ESP packet flow can resume. If MOBIKE is being
used, the initiator SHOULD send UPDATE_SA_ADDRESSES.
Pauly, et al. Expires July 27, 2017 [Page 18]
Internet-Draft TCP Encapsulation of IKE and IPsec Packets January 2017
B.4. Using MOBIKE between UDP and TCP Encapsulation
Client Server
---------- ----------
(IP_I1:UDP500 -> IP_R:UDP500)
1) ----------------- IKE_SA_INIT Exchange -----------------
(IP_I1:UDP4500 -> IP_R:UDP4500)
Non-ESP Marker ----------->
Intial IKE_AUTH
HDR, SK { IDi, CERT, AUTH,
CP(CFG_REQUEST),
SAi2, TSi, TSr,
N(MOBIKE_SUPPORTED) }
<----------- Non-ESP Marker
Initial IKE_AUTH
HDR, SK { IDr, CERT, AUTH,
EAP, SAr2, TSi, TSr,
N(MOBIKE_SUPPORTED) }
<---------------- IKE tunnel establishment ------------->
2) ------------ MOBIKE Attempt on new network --------------
(IP_I2:UDP4500 -> IP_R:UDP4500)
Non-ESP Marker ----------->
INFORMATIONAL
HDR, SK { N(UPDATE_SA_ADDRESSES),
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) }
3) -------------------- TCP Connection -------------------
(IP_I2:PORT_I -> IP_R:TCP443 or TCP4500)
TcpSyn ----------->
<----------- TcpSyn,Ack
TcpAck ----------->
4) --------------------- TLS Session ---------------------
ClientHello ----------->
ServerHello
Certificate*
ServerKeyExchange*
<----------- ServerHelloDone
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished ----------->
[ChangeCipherSpec]
<----------- Finished
Pauly, et al. Expires July 27, 2017 [Page 19]
Internet-Draft TCP Encapsulation of IKE and IPsec Packets January 2017
5) ---------------------- Stream Prefix --------------------
"IKETCP" ---------->
6) ----------------------- IKE Session ---------------------
Length + Non-ESP Marker ----------->
INFORMATIONAL (Same as step 2)
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) }
7) <----------------- IKE/ESP data flow ------------------->
Figure 7
1. During the IKE_SA_INIT exchange, the client and server exchange
MOBIKE_SUPPORTED notify payloads to indicate support for
MOBIKE.
2. The client changes its point of attachment to the network, and
receives a new IP address. The client attempts to re-establish
the IKE session using the UPDATE_SA_ADDRESSES notify payload,
but the server does not respond because the network blocks UDP
traffic.
3. The client brings up a TCP connection to the server in order to
use TCP encapsulation.
4. The client initiates and TLS handshake with the server.
5. The client sends the Stream Prefix for TCP encapsulated IKE
traffic [Section 4].
6. The client sends the UPDATE_SA_ADDRESSES notify payload on the
TCP encapsulated connection. Note that this IKE message is the
same as the one sent over UDP in step 2, and should have the
same message ID and contents.
7. The IKE and ESP packet flow can resume.
Authors' Addresses
Pauly, et al. Expires July 27, 2017 [Page 20]
Internet-Draft TCP Encapsulation of IKE and IPsec Packets January 2017
Tommy Pauly
Apple Inc.
1 Infinite Loop
Cupertino, California 95014
US
Email: tpauly@apple.com
Samy Touati
Ericsson
300 Holger Way
San Jose, California 95134
US
Email: samy.touati@ericsson.com
Ravi Mantha
Cisco Systems
SEZ, Embassy Tech Village
Panathur, Bangalore 560 037
India
Email: ramantha@cisco.com
Pauly, et al. Expires July 27, 2017 [Page 21]