draft-ietf-ipsecme-tcp-encaps-06.txt   draft-ietf-ipsecme-tcp-encaps-07.txt 
Network T. Pauly Network T. Pauly
Internet-Draft Apple Inc. Internet-Draft Apple Inc.
Intended status: Standards Track S. Touati Intended status: Standards Track S. Touati
Expires: August 7, 2017 Ericsson Expires: August 13, 2017 Ericsson
R. Mantha R. Mantha
Cisco Systems Cisco Systems
February 3, 2017 February 9, 2017
TCP Encapsulation of IKE and IPsec Packets TCP Encapsulation of IKE and IPsec Packets
draft-ietf-ipsecme-tcp-encaps-06 draft-ietf-ipsecme-tcp-encaps-07
Abstract Abstract
This document describes a method to transport IKE and IPsec packets This document describes a method to transport IKE and IPsec packets
over a TCP connection for traversing network middleboxes that may over a TCP connection for traversing network middleboxes that may
block IKE negotiation over UDP. This method, referred to as TCP block IKE negotiation over UDP. This method, referred to as TCP
encapsulation, involves sending both IKE packets for Security encapsulation, involves sending both IKE packets for Security
Association establishment as well as ESP packets over a TCP Association establishment and ESP packets over a TCP connection.
connection. This method is intended to be used as a fallback option This method is intended to be used as a fallback option when IKE
when IKE cannot be negotiated over UDP. cannot be negotiated over UDP.
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 7, 2017. This Internet-Draft will expire on August 13, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 35 skipping to change at page 4, line 35
1.2. Terminology and Notation 1.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 the this document will use the term "TCP Originator" to indicate the IKE
IKE peer that initiates TCP connections. The peer that receives TCP peer that initiates TCP connections. The peer that receives TCP
connections will be referred to as the "TCP Responder". The TCP connections will be referred to as the "TCP Responder". If an IKE SA
Originator MUST be the same as the "Original Initiator", or the is rekeyed one or more times, the TCP Originator MUST remain the peer
Initiator of the first IKE SA exchange for a given IKE session. that originally initiated the first IKE SA.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Configuration 2. Configuration
One of the main reasons to use TCP encapsulation is that UDP traffic One of the main reasons to use TCP encapsulation is that UDP traffic
may be entirely blocked on a network. Because of this, support for may be entirely blocked on a network. Because of this, support for
TCP encapsulation is not specifically negotiated in the IKE exchange. TCP encapsulation is not specifically negotiated in the IKE exchange.
skipping to change at page 8, line 40 skipping to change at page 8, line 40
bytes sent on the stream MUST be the stream prefix value [Section 4]. bytes sent on the stream MUST be the stream prefix value [Section 4].
After this prefix, encapsulated IKE messages will negotiate the IKE After this prefix, encapsulated IKE messages will negotiate the IKE
SA and initial Child SA [RFC7296]. After this point, both SA and initial Child SA [RFC7296]. After this point, both
encapsulated IKE Figure 1 and ESP Figure 2 messages will be sent over encapsulated IKE Figure 1 and ESP Figure 2 messages will be sent over
the TCP connection. The TCP Responder MUST wait for the entire the TCP connection. The TCP Responder MUST wait for the entire
stream prefix to be received on the stream before trying to parse out stream prefix to be received on the stream before trying to parse out
any IKE or ESP messages. The stream prefix is sent only once, and any IKE or ESP messages. The stream prefix is sent only once, and
only by the TCP Originator. only by the TCP Originator.
In order to close an IKE session, either the Initiator or Responder In order to close an IKE session, either the Initiator or Responder
SHOULD gracefully tear down IKE SAs with DELETE payloads. Once all SHOULD gracefully tear down IKE SAs with DELETE payloads. Once the
the SA has been deleted, the TCP Originator SHOULD close the TCP SA has been deleted, the TCP Originator SHOULD close the TCP
connection if it does not intend to use the connection for another connection if it does not intend to use the connection for another
IKE session to the TCP Responder. If the connection is left idle, IKE session to the TCP Responder. If the connection is left idle,
and the TCP Responder needs to clean up resources, the TCP Responder and the TCP Responder needs to clean up resources, the TCP Responder
MAY close the TCP connection. MAY close the TCP connection.
An unexpected FIN or a RST on the TCP connection may indicate either An unexpected FIN or a RST on the TCP connection may indicate either
a loss of connectivity, an attack, or some other error. If a DELETE a loss of connectivity, an attack, or some other error. If a DELETE
payload has not been sent, both sides SHOULD maintain the state for payload has not been sent, both sides SHOULD maintain the state for
their SAs for the standard lifetime or time-out period. The TCP their SAs for the standard lifetime or time-out period. The TCP
Originator is responsible for re-establishing the TCP connection if Originator is responsible for re-establishing the TCP connection if
skipping to change at page 9, line 29 skipping to change at page 9, line 29
from an encapsulated IKE message or the ESP SPI from an encapsulated from an encapsulated IKE message or the ESP SPI from an encapsulated
ESP message. If the session had been fully established previously, ESP message. If the session had been fully established previously,
it is suggested that the TCP Originator send an UPDATE_SA_ADDRESSES it is suggested that the TCP Originator send an UPDATE_SA_ADDRESSES
message if MOBIKE is supported, or an INFORMATIONAL message (a message if MOBIKE is supported, or an INFORMATIONAL message (a
keepalive) otherwise. If either TCP Originator or TCP Responder keepalive) otherwise. If either TCP Originator or TCP Responder
receives a stream that cannot be parsed correctly (for example, if receives a stream that cannot be parsed correctly (for example, if
the TCP Originator stream is missing the stream prefix, or message the TCP Originator stream is missing the stream prefix, or message
frames are not parsable as IKE or ESP messages), it MUST close the frames are not parsable as IKE or ESP messages), it MUST close the
TCP connection. If there is instead a syntax issue within an IKE TCP connection. If there is instead a syntax issue within an IKE
message, an implementation MUST send the INVALID_SYNTAX notify message, an implementation MUST send the INVALID_SYNTAX notify
payload and tear down the IKE session as ususal, rather than tearing payload and tear down the IKE SA as ususal, rather than tearing down
down the TCP connection directly. the TCP connection directly.
An TCP Originator SHOULD only open one TCP connection per IKE SA, An TCP Originator SHOULD only open one TCP connection per IKE SA,
over which it sends all of the corresponding IKE and ESP messages. over which it sends all of the corresponding IKE and ESP messages.
This helps ensure that any firewall or NAT mappings allocated for the This helps ensure that any firewall or NAT mappings allocated for the
TCP connection apply to all of the traffic associated with the IKE SA TCP connection apply to all of the traffic associated with the IKE SA
equally. equally.
Similarly, a TCP Responder SHOULD at any given time send packets for Similarly, a TCP Responder SHOULD at any given time send packets for
an IKE SA and its Child SAs over only one TCP connection. It SHOULD an IKE SA and its Child SAs over only one TCP connection. It SHOULD
choose the TCP connection on which it last received a valid and choose the TCP connection on which it last received a valid and
 End of changes. 8 change blocks. 
16 lines changed or deleted 16 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/