One document matched: draft-ietf-btns-connection-latching-09.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml' -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc0768 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.0768.xml'>
<!ENTITY rfc0793 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.0793.xml'>
<!ENTITY rfc1034 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml'>
<!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc4301 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4301.xml'>
<!ENTITY rfc4306 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4306.xml'>
<!ENTITY rfc4960 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4960.xml'>
<!ENTITY rfc5056 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5056.xml'>
<!ENTITY rfc5061 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5061.xml'>
<!ENTITY rfc5386 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5386.xml'>
<!ENTITY rfc5387 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5387.xml'>
<!ENTITY btns-abstract-api PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-btns-abstract-api.xml'>
<!ENTITY bellovin-useipsec PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bellovin-useipsec.xml'>
<!ENTITY dondeti-useipsec PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.dondeti-useipsec-430x.xml'>
<!ENTITY ipsec-channel-binding PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.williams-ipsec-channel-binding.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc tocompact="yes" ?>
<?rfc tocindent="no" ?>
<?rfc autobreaks="no" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<rfc category="std" ipr="trust200902" docName="draft-ietf-btns-connection-latching-09.txt">
<front>
<title abbrev="IPsec Connection Latching">IPsec Channels: Connection Latching</title>
<author initials='N.' surname="Williams" fullname='Nicolas
Williams'>
<organization abbrev="Sun">Sun Microsystems</organization>
<address>
<postal>
<street>5300 Riata Trace Ct</street>
<city>Austin</city> <region>TX</region>
<code>78727</code> <country>US</country>
</postal>
<email>Nicolas.Williams@sun.com</email>
</address>
</author>
<date month="March" year="2009"/>
<area>Security</area>
<workgroup>NETWORK WORKING GROUP</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>This document specifies, abstractly, how to interface
applications and transport protocols with IPsec so as to
create "channels" by latching "connections" (packet
flows) to certain IPsec Security Association (SA)
parameters for the lifetime of the connections.
Connection latching is layered on top of IPsec and does
not modify the underlying IPsec architecture.</t>
<t>Connection latching can be used to protect applications
against accidentally exposing live packet flows to
unintended peers, whether as the result of a
reconfiguration of IPsec or as the result of using weak
peer identity to peer address associations. Weak
association of peer ID and peer addresses is at the core
of Better Than Nothing Security (BTNS), thus connection
latching can add a significant measure of protection to
BTNS IPsec nodes.</t>
<t>Finally, the availability of IPsec channels will make it
possible to use channel binding to IPsec channels.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>IPsec protects packets with little or no regard for
stateful packet flows associated with upper layer
protocols (ULPs). This exposes applications that rely
on IPsec for session protection to risks associated with
changing IPsec configurations, configurations that allow
multiple peers access to the same addresses, and/or weak
association of peer IDs and their addresses. The latter
can occur as a result of "wildcard" matching in the
IPsec Peer Authorization Database (PAD), particularly
when Better Than Nothing Security (BTNS) <xref target='RFC5387'/>
is used.</t>
<t>Applications that wish to use IPsec may have to ensure
that local policy on the various end-points is
configured appropriately <xref
target='I-D.bellovin-useipsec'/> <xref
target='I-D.dondeti-useipsec-430x'/>. There are no
standard Application Programming Interfaces (APIs) to do
this -- a major consequence of which, for example, is
that applications must still use hostnames (and, e.g.,
the Domain Name System <xref target="RFC1034"/>) and IP
addresses in existing APIs and must depend on an IPsec
configuration that they may not be able to verify. In
addition to specifying aspects of required Security
Policy Database (SPD) configuration, application
specifications must also address PAD/SPD configuration
to strongly bind individual addresses to individual
IPsec identities and credentials (certificates, public
keys, ...).</t>
<t>IPsec is, then, quite cumbersome for use by applications.
To address this we need APIs to IPsec. Not merely APIs
for configuring IPsec, but also APIs that are similar to
the existing IP APIs (e.g., "BSD sockets"), so that
typical applications making use of UDP <xref
target='RFC0768'/>, TCP <xref target='RFC0793'/> and
SCTP <xref target='RFC4960'/> can make
use of IPsec with minimal changes.</t>
<t>This document describes the foundation for IPsec APIs
that UDP and TCP applications can use: a way to bind
the traffic flows for, e.g., TCP connections to security
properties desired by the application. We call these
"connection latches" (and, in some contexts, "IPsec
channels"). The methods outlined below achieve this by
interfacing ULPs and applications to IPsec.</t>
<t>If widely adopted, connection latching could make
application use of IPsec much simpler, at least for
certain classes of applications.</t>
<t>Connection latching, as specified herein, is primarily
about watching updates to the SPD and Security
Association Database (SAD) to detect changes that are
adverse to an application's requirements for any given
packet flow, and to react accordingly (such as by
synchronously alerting the ULP and application before
packets can be sent or received under the new policy).
Under no circumstance are IPsec policy databases to be
modified by connection latching in any way that can
persist beyond the lifetime of the related packet flows,
nor reboots. Under no circumstance is the PAD to be
modified at all by connection latching. If all optional
features of connection latching are excluded then
connection latching can be implemented as a monitor of
SPD and SAD changes that intrudes in their workings no
more than is needed to provide synchronous alerts to
ULPs and applications.</t>
<t>We assume the reader is familiar with the IPsec
architecture <xref target='RFC4301'/> and IKEv2 <xref
target='RFC4306'/>.</t>
<t>Note: the terms "connection latch" and "IPsec channel"
are used interchangeably below. The latter term relates
to "channel binding" <xref target="RFC5056"/>.
Connection latching is suitable for use in channel
binding applications, or will be, at any rate, when the
channel bindings for IPsec channels are defined (the
specification of IPsec channel bindings is out of scope
for this document).</t>
<t>Note: where this document mentions IPsec peer "ID" it
refers to the Internet Key Exchange (IKE) peer ID (e.g.,
the ID derived from a peer's cert, as well as the cert),
not the peer's IP address.</t>
<section anchor='conventions' title="Conventions used in this document">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as
described in <xref target="RFC2119"/>.</t>
<t>Abstract function names are all capitalized and
denoted by a pair of parenthesis. In their
descriptions the arguments appear within the
parenthesis, with optional argument surrounded by
square brackets. Return values, if any, are
indicated by following the function argument list
with "->" and a description of the return value.
For example, "FOO(3-tuple, [message])" would be a
function named "FOO" with two arguments, one of them
optional, and returning nothing, whereas
"FOOBAR(handle) -> state" would be a function with a
single, required argument that returns a value. The
values' types are described in the surrounding
text.</t>
</section>
</section>
<section anchor='connection_latching' title="Connection Latching">
<t>An "IPsec channel" is a packet flow associated with a ULP
control block, such as a TCP connection, where all the
packets are protected by IPsec SAs such that:
<list style='symbols'>
<t>the peer's identity is the same for the lifetime
of the packet flow</t>
<t>the quality of IPsec protection used for the
packet flow's individual packets is the same for
all of them for the lifetime of the packet
flow</t>
</list>
</t>
<t>An IPsec channel is created when the associated packet
flow is created. This can be the result of a local
operation (e.g., a connect()) that causes the initial
outgoing packet for that flow to be sent, or it can be
the result of receiving the first/initiating packet for
that flow (e.g., a TCP SYN packet).</t>
<t>An IPsec channel is destroyed when the associated packet
flow ends. An IPsec channel can also be "broken" when
the connection latch cannot be maintained for some
reason (see below), in which case the ULP and
application are informed.</t>
<t>IPsec channels are created by "latching" various
parameters listed below to a ULP connection when the
connections are created. The REQUIRED set of parameters
bound in IPsec channels is:
<list style='symbols'>
<t>Type of protection: confidentiality and/or
integrity protection;</t>
<t>Transport mode vs. tunnel mode;</t>
<t>Quality of protection: cryptographic algorithm
suites, key lengths, and replay protection;</t>
<t>Local identity: the local ID asserted to the
peer, as per the IPsec processing model <xref
target='RFC4301'/> and BTNS <xref
target='RFC5386'/>;</t>
<t>Peer identity: the peer's asserted and
authorized IDs, as per the IPsec processing
model <xref target='RFC4301'/> and BTNS <xref
target='RFC5386'/>.</t>
</list>
</t>
<t>The SAs that protect a given IPsec channel's packets may
change over time in that they may expire and be replaced
with equivalent SAs, or may be re-keyed. The set of SAs
that protect an IPsec channel's packets need not be
related by anything other than the fact that they must
be congruent to the channel (i.e, the SAs' parameters
must match those that are latched into the channel). In
particular, it is desirable that IPsec channels survive
the expiration of IKE_SAs and child SAs because
operational considerations of the various key exchange
protocols then cannot affect the design and features of
connection latching.</t>
<t>When a situation arises in which the SPD is modified, or
an SA is added to the SAD, such that the new policy or
SA are not congruent to an established channel (see
previous paragraph) then we consider this a conflict.
Conflict resolution is addressed below.</t>
<t>Requirements and recommendations:
<list style='symbols'>
<t>If an IPsec channel is desired then packets for a
given connection MUST NOT be sent until the
channel is established.</t>
<t>If an IPsec channel is desired then inbound
packets for a given connection MUST NOT be
accepted until the channel is established.
I.e., inbound packets for a given connection
arriving prior to the establishment of the
corresponding IPsec channel must be dropped or
the channel establishment must fail.</t>
<t>Once an IPsec channel is established, packets for
the latched connection MUST NOT be sent
unprotected nor protected by an SA that does not
match the latched parameters.</t>
<t>Once an IPsec channel is established packets for
the latched connection MUST NOT be accepted
unprotected nor protected by an SA that does not
match the latched parameters. I.e., such
packets either must be dropped or must cause the
channel to be terminated and the application to
be informed before data from such a packet can
be delivered to the application.</t>
<t>Implementations SHOULD provide programming
interfaces for inquiring the values of the
parameters latched in a connection.</t>
<t>Implementations that provide such programming
interfaces MUST make available to applications
all relevant and available information about a
peer's ID, including authentication information.
This includes the peer certificate, when one is
used, and the trust anchor that it was validated
to (but not necessarily the whole certificate
validation chain).</t>
<t>Implementations that provide such programming
interfaces SHOULD make available to applications
any information about local and/or remote public
and private IP addresses, in the case of
NAT-traversal.</t>
<t>Implementations that provide such programming
interfaces SHOULD make available to applications
the inner and outer local and peer addresses
whenever the latched connection uses tunnel mode
SAs.</t>
<t>Implementations SHOULD provide programming
interfaces for setting the values of the
parameters to be latched in a connection that
will be initiated or accepted, but these
interfaces MUST limit what values applications
may request according to system policy (i.e.,
the IPsec PAD and SPD) and the application's
local privileges. <vspace blankLines='1'/>
(Typical system policy may not allow
applications any choices here. Policy
extensions allowing for optional protection are
described in <xref
target="optional_protection"/>.)</t>
<t>Implementations SHOULD create IPsec channels
automatically by default when the application
does not explicitly request an IPsec
channel. Implemenations MAY provide a way to
disable automatic creation of connection
latches.</t>
<t>The parameters latched in an IPsec channel MUST
remain unchanged once the channel is
established.</t>
<t>Timeouts while establishing child SAs with
parameters that match those latched into an
IPsec channel MUST be treated as packet loss (as
happens, for example, when a network
partitions); normal ULP and/or application
timeout handling and retransmission
considerations apply.</t>
<t>Implementations that have a restartable key
management process (or "daemon") MUST arrange
for existing latched connections to either be
broken and disconnected, or for them to survive
the restart of key exchange processes. (This is
implied by the above requirements.) For
example, if such an implementation relies on
keeping some aspects of connection latch state
in the restartable key management process (e.g.,
values that potentially have large
representations, such as BTNS peer IDs), then
either such state must be restored on restart of
such a process, or outstanding connection
latches must be transitioned to the CLOSED
state.</t>
<t>Dynamic IPsec policy (see <xref
target='optional_protection'/>) related to
connection latches, if any, MUST be torn down
when latched connections are torn down, and MUST
NOT survive reboots.</t>
</list>
</t>
<t>We describe two models, one of them normative, of IPsec
channels for native IPsec implementations. The
normative model is based on abstract programming
interfaces in the form of function calls between ULPs
and the key management component of IPsec (basically,
the SAD, augmented with a Latch Database (LD)). The
second model is based on abstract programming interfaces
between ULPs and the IPsec (Encapsulating Security
Payload / Authentication Header (ESP/AH)) layer in the
form of meta-data tagging of packets within the IP
stack.</t>
<t>The two models given below are not, however, entirely
equivalent. One model cannot be implemented with NICs
that offload ESP/AH but which do not tag incoming
packets passed to the host processor with SA
information, nor allow the host processor to so tag
outgoing packets. That same model can be easily
extended to support connection latching with unconnected
datagram "sockets", while the other model is rigidly
tied to a notion of "connections" and cannot be so
extended. There may be other minor differences between
the two models. Rather than seek to establish
equivalency for some set of security guarantees we
instead choose one model to be the normative one.</t>
<t>We also provide a model for non-native implementations,
such as bump-in-the-stack (BITS) and Security Gateway
(SG) implementations. The connection latching model for
non-native implementations is not full-featured as it
depends on estimating packet flow state, which may not
always be possible. Nor can non-native IPsec
implementations be expected to provide APIs related to
connection latching (implementations that do could be
said to be native). As such this third model is not
suitable for channel binding applications <xref
target='RFC5056'/>.</t>
<section anchor="states" title="Connection latch state
machine">
<t>Connection latches can exist in any of the following
five states:
<list style='symbols'>
<t>LISTENER</t>
<t>ESTABLISHED</t>
<t>BROKEN (there exist SAs which conflict
with the given connection latch)</t>
<t>CLOSED (by the ULP, the application or
administratively)</t>
</list>
and always have an associated owner, or holder, such as
a ULP transmission control block (TCB).
</t>
<t>A connection latch can be born in the LISTENER state,
which can transition only to the CLOSED state. The
LISTENER state corresponds to LISTEN state of TCP
(and other ULPs) and is associated with IP 3-tuples,
and can give rise to new connection latches in the
ESTABLISHED state.</t>
<t>A connection latch can also be born in the
ESTABLISHED and BROKEN states, either through the
direct initiative of a ULP or when an event occurs
that causes a LISTENER latch to create a new latch
(in either ESTABLISHED or BROKEN states). These
states represents an active connection latch for a
traffic flow's 5-tuple. Connection latches in these
two states can transition to the other of the two
states, as well as to the CLOSED state.</t>
<t>Connection latches remain in the CLOSED state until
their owners are informed except where the owner
caused the transition, in which case this state is
fleeting. Transitions from ESTABLISHED or BROKEN
states to the CLOSED state should typically be
initiated by latch owners, but implementations
SHOULD provide administrative interfaces through
which to close active latches.</t>
<t>Connection latches transition to the BROKEN state
when there exist SAs in the SAD whose traffic
selectors encompass the 5-tuple bound by the latch,
and whose peer and/or parameters conflict with those
bound by the latch. Transitions to the BROKEN state
always cause the associated owner to be informed.
Connection latches in the BROKEN state transition
back to ESTABLISHED when the conflict is
cleared.</t>
<t>Most state transitions are the result of local
actions of the latch owners (ULPs). The only
exceptions are: birth into the ESTABLISHED state
from latches in the LISTENER state, transitions to
the BROKEN state, transitions from the BROKEN state
to ESTABLISHED, and administrative transitions to
the CLOSED state. (Additionally, see the
implementation note about restartable key management
processes in <xref target='connection_latching'/>.)
<vspace blankLines='100'/> </t>
<figure anchor='state_machine_figure' title='Connection
Latching State Machine'>
<preamble>The state diagram below makes use of
conventions described in <xref
target='conventions'/> and state transition
events described in <xref
target='key_manager'/>.</preamble>
<artwork>
<![CDATA[
<CREATE_LISTENER_LATCH(3-tuple, ...)>
:
v <CREATE_CONNECTION_LATCH(5-tuple, ...)>
/--------\ : :
+------|LISTENER|...... : :
| \--------/ : : : +--------------------+
| : : : : |Legend: |
| : : : : | dotted lines denote|
| <conn. trigger event> : : | latch creation |
| (e.g., TCP SYN : : : | |
| received, : : : | solid lines denote |
| connect() : : : | state transition|
| called, ...) v v : | |
| : /-----------\ : | semi-solid lines |
| : |ESTABLISHED| : | denote async |
| <conflict> \-----------/ : | notification |
| : ^ | : +--------------------+
| : | <conflict>
| : <conflict | :
| : cleared> | :
| : | | :
| : | v v
| : /----------------\
| :.....>| BROKEN |.-.-.-.-.-> <ALERT()>
| \----------------/
| |
<RELEASE_LATCH()> <RELEASE_LATCH()>
| |
| v
| /------\
+------------------->|CLOSED|
\------/
]]>
</artwork>
</figure>
<t>The details of the transitions depend on the model of
connection latching followed by any given
implementation. See the following sections.</t>
</section>
<section anchor="key_manager"
title="Normative Model: ULP interfaces to the key
manager">
<t>This section describes the NORMATIVE model of
connection latching.</t>
<t>In this section we describe connection latching in
terms of a function call interface between ULPs and
the "key manager" component of a native IPsec
implementation. Abstract interfaces for creating,
inquiring about, and releasing IPsec channels are
described.</t>
<t>This model adds a service to the IPsec key manager
(i.e., the component that manages the SAD and
interfaces with separate implementations of, or
directly implements, key exchange protocols):
management of connection latches. There is also a
new IPsec database, the Latch Database (LD), that
contains all connection latch objects. The LD does
not persist across system reboots.</t>
<t>The traditional IPsec processing model allows the
concurrent existence of SAs with different peers but
overlapping traffic selectors. Such behaviour, in
this model, directly violates the requirements for
connection latching (see <xref
target='connection_latching'/>). We address
this problem by requiring that connection latches be
broken (and holders informed) when such conflicts
arise.</t>
<t>The following INFORMATIVE figure illustrates this
model and API in terms that are familiar to many
implementors, though not applicable to all:
<vspace blankLines='100'/></t>
<figure anchor='arch_figure1' title='Informative
Implementation Architecture Diagram'>
<artwork>
<![CDATA[
+--------------------------------------------+
| +--------------+ |
| |Administrator | |
| |apps | |
| +--------------+ |
| ^ ^ |
| | | | user mode
| v v |
| +--------------+ +-------++--------+ |
| |App | |IKEv2 || | |
| | | | +---+ || +----+ | |
| | | | |PAD| || |SPD | | |
| | | | +---+ || +--^-+ | |
| +--------------+ +-+-----++----+---+ |
| ^ | | |
+---|---------------------|-----------|------+ user/kernel mode
| |syscalls | PF_KEY | | interface
+---|---------------------|-----------|------+
| v | | |
|+-------+ +------------|-----------|-----+|
||ULP | | IPsec key|manager | ||
|+-------+ | | +--------v----+||
| ^ ^ | | | Logical SPD |||
| | | | | +-----------^-+||
| | | | +-------+ | || kernel mode
| | | | | | ||
| | | | +----------+ +--v--+ | ||
| | +-------->| Latch DB |<-->| SAD | | ||
| | | +----------+ +--^--+ | ||
| | +--------------------|------|--+|
+-|-------------------------------v------v---+
| | IPsec Layer (ESP/AH) |
| | |
+-v------------------------------------------+
| IP Layer |
+--------------------------------------------+
]]>
</artwork>
</figure>
<t>The ULP interfaces to the IPsec LD database are as
follows:
<list style='symbols'>
<t>CREATE_LISTENER_LATCH(3-tuple, [type and
quality of protection parameters]) ->
latch handle | error
<list style='empty'>
<t>If there is no conflicting connection
latch object in the LISTENER state
for the given 3-tuple (local
address, protocol and local port
number), and local policy permits
it, then this operation atomically
creates a connection latch object in
the LISTENER state for the given
3-tuple.</t>
<t>When a child SA is created that
matches a listener latch's 3-tuple,
but not any ESTABLISHED connection
latch's 5-tuple (local address,
remote address, protocol, local port
number and remote port number), then
the key manager creates a new
connection latch object in the
ESTABLISHED state. The key manager
MUST inform the holder of the
listener latch of connection latches
created as a result of the listener
latch; see the "ALERT()" interface
below.</t>
</list>
</t>
<t>CREATE_CONNECTION_LATCH(5-tuple, [type and
quality of protection parameters], [peer
ID], [local ID]) -> latch handle | error
<list style='empty'>
<t>If no connection latch exists in the
ESTABLISHED states with the same
5-tuple, and if there exist no child
SAs that match the given 5-tuple,
and if local policy permits it, then
the system MUST initiate an IKE
exchange to setup child SAs for this
5-tuple. Otherwise an error is
returned to the ULP. Once one or
more applicable SAs exist in the SAD
and all such SAs share the same type
and quality of protection parameters
and the same peer then this
operation creates a connection latch
object in the ESTABLISHED state for
the given 5-tuple. If the caller
provided all the optional arguments
to this operation then the resulting
connection latch can be created in
the ESTABLISHED state directly.</t>
<t>If there exist no child SAs matching
the given 5-tuple then the key
manager SHOULD try to create a pair
of child SAs for that 5-tuple. In
any case, the key manager can expect
that the ULP will send a packet that
would trigger the creation of such
SAs.</t>
</list>
</t>
<t>RELEASE_LATCH(latch object handle)
<list style='empty'>
<t>Changes the state of the given
connection latch to CLOSED; the
connection latch is then
deleted.</t>
<t>The key manager MAY delete any
existing child SAs that match the
given latch if it had been in the
ESTABLISHED states. If the key
manager does delete such SAs then it
SHOULD inform the peer with an
informational Delete payload (see
IKEv2 <xref target='RFC4306'/>).</t>
</list>
</t>
<t>FIND_LATCH(5-tuple) -> latch handle | error
<list style='empty'>
<t>Given a 5-tuple returns a latch
handle (or an error).</t>
</list>
</t>
<t>INQUIRE_LATCH(latch object handle) -> {latch
state, latched parameters} | error
<list style='empty'>
<t>Returns all available information
about the given latch, including its
current state (or an error).</t>
</list>
</t>
</list>
</t>
<t>The IPsec LD interface to the ULP is as follows:
<list style='symbols'>
<t>ALERT(latch object handle, 5-tuple, new
state, [reason])
<list style='empty'>
<t>Alerts a ULP as to an asynchronous
state change for the given
connection latch and, optionally,
provides a reason for the
change.</t>
</list>
<vspace blankLines='1'/>
This interface is to be provided by each ULP
to the key manager. The specific details of
how this interface is provided are
implementation details, thus not specified
here (for example, this could be a
"callback" function or "closure" registered
as part of the CREATE_LISTENER_LATCH()
interface, or it could be provided when the
ULP is loaded onto the running system via a
registration interface provided by the key
manager.</t>
</list>
</t>
<t>Needless to say, the LD is updated whenever a
connection latch object is created, deleted or
broken.</t>
<t>The API described above is a new service of the IPsec
key manager. In particular the IPsec key manager
MUST prevent conflicts amongst latches, and it MUST
prevent conflicts between any latch and existing or
proposed child SAs as follows:
<list style='symbols'>
<t>Non-listener connection latches MUST NOT be
created if there exist conflicting SAs in
the SAD at the time the connection latch is
requested or would be created (from a
listener latch). A child SA conflicts with
another, in view of a latch, if and only if:
a) its traffic selectors and the conflicting
SA's match the given latch's, and b) its
peer, type of protection, or quality of
protection parameters differ from the
conflicting SA.</t>
<t>Child SA proposals that would conflict with
an extant connection latch and whose traffic
selectors can be narrowed to avoid the
conflict SHOULD be narrowed (see section 2.9
of <xref target='RFC4306'/>), otherwise the
latch MUST be transitioned to the BROKEN
state.</t>
<t>Where child SA proposals that would conflict
with an extant connection latch cannot be
narrowed to avoid the conflict the key
manager MUST break the connection latch and
inform the holder (i.e., the ULP) prior to
accepting the conflicting SAs.</t>
</list>
</t>
<t>Finally, the key manager MUST protect latched
connections against SPD changes that would change
the quality of protection afforded to a latched
connection's traffic, or which would bypass it.
When such a configuration change takes place the key
manager MUST respond in either of the following
ways. The REQUIRED to implement behaviour is to
transition into the BROKEN state all connection
latches that conflict with the given SPD change.
An OPTIONAL behaviour is to logically update the
SPD as if a PROTECT entry had been added at the head
of the SPD-S with traffic selectors matching only
the latched connection's 5-tuple, and with
processing information taken from the connection
latch. Such updates of the SPD MUST NOT survive
system crashes or reboots.</t>
<t>ULPs create latched connections by interfacing with
IPsec below as follows:
<list style='symbols'>
<t>For listening end-points the ULP will request
a connection latch listener object for the
ULP listener's 3-tuple. Any latching
parameters requested by the application
MUST be passed along.</t>
<t>When the ULP receives a packet initiating a
connection for a 5-tuple matching a 3-tuple
listener latch, then the ULP will ask
the key manager whether a 5-tuple connection
latch was created. If not then the ULP will
either reject the new connection or accept
it and inform the application that the new
connection is not latched.</t>
<t>When initiating a connection the ULP will
request a connection latch object for the
connection's 5-tuple. Any latching
parameters requested by the application
MUST be passed along. If no latch can be
created then the ULP MUST either return an
error to the application or continue with
the new connection and inform the
application that the new connection is not
latched.</t>
<t>When a connection is torn down and no further
packets are expected for it then the ULP
MUST request that the connection latch
object be destroyed.</t>
<t>When tearing down a listener the ULP MUST
request that the connection latch listener
object be destroyed.</t>
<t>When a ULP listener rejects connections the
ULP will request the destruction of any
connection latch objects that may have been
created as a result of the peer's attempt to
open the connection.</t>
<t>When the key manager informs a ULP that a
connection latch has transitioned to the
BROKEN state then the ULP MUST stop sending
packets and MUST drop all subsequent
incoming packets for the affected connection
until it transitions back to ESTABLISHED.
Connection-oriented ULPs SHOULD act as
though the connection is experiencing packet
loss.</t>
<t>When the key manager informs a ULP that a
connection latch has been administratively
transitioned to the CLOSED state then
connection-oriented ULPs MUST act as though
the connection has been reset by the peer.
Implementations of ULPs which are not
connection-oriented, and which have no API
by which to simulate a reset, MUST drop all
inbound packets for that connection and MUST
NOT send any further packets -- the
application is expected to detect
timeouts and act accordingly.</t>
</list>
</t>
<t>The main benefit of this model of connection latching
is that it accommodates IPsec implementations where
ESP/AH handling is implemented in hardware (for all
or a subset of the host's SAD), but where the
hardware does not support tagging inbound packets
with the indexes of SAD entries corresponding to the
SAs that protected them.</t>
<section anchor='race_cond' title='Race Conditions and
Corner Cases'>
<t>ULPs MUST drop inbound packets and stop sending
packets immediately upon receipt of a connection
latch break message. Otherwise the ULP will not
be able to distinguish inbound packets that were
protected consistently with the connection's
latch from inbound packets that were not. This
may include dropping inbound packets that were
protected by a suitable SA; dropping such
packets is no different, from the ULP's point of
view, than packet loss elsewhere on the network
at the IP layer or below -- harmless, from a
security point of view as the connection fails
safe, but it can result in retransmits.</t>
<t>Another race condition is as follows. A
PROTECTed TCP SYN packet may be received and
decapsulated but the SA that protected it could
have expired before the key manager creates the
connection latch that would be created by that
packet. In this case the key manager will have
to initiate new child SAs so as to determine
what the sender's peer ID is so it can be
included in the connection latch. Here there is
no guarantee that the peer ID for the new SAs
will be the same as those of the peer that sent
the TCP SYN packet. This race condition is
harmless: TCP will send a SYN+ACK to the wrong
peer, which will then respond with an RST -- the
connection latch will reflect the new peer
however, so if the new peer is malicious it will
not be able to appear to be the old peer.
Therefore this race condition is harmless.</t>
</section>
<section anchor='example1' title='Example'>
<t>Consider several systems with a very simple PAD
containing a single entry like so:</t>
<figure anchor="pad" title="Example PAD">
<artwork>
Child SA
Rule Remote ID IDs allowed SPD Search by
---- --------- ----------- -------------
1 <any valid to trust anchor X> 192.0.2/24 by-IP
</artwork>
</figure>
<t>And a simple SPD like so:</t>
<figure anchor="sgA_spd" title="[SG-A] SPD table">
<preamble>
</preamble>
<artwork>
Rule Local Remote Next Action
TS TS Proto
---- ----- ------ ----- ----------------
1 192.0.2/24:ANY 192.0.2/24:1-5000 TCP PROTECT(ESP,...)
1 192.0.2/24:1-5000 192.0.2/24:ANY TCP PROTECT(ESP,...)
1 ANY ANY ANY BYPASS
</artwork>
<postamble></postamble>
</figure>
<t>Effectively this says: for TCP ports 1-5000 in
our network allow only peers that have
credentials issued by CA X and PROTECT that
traffic with ESP, otherwise bypass all other
traffic.</t>
<t>Now let's consider two hosts, A and B, in this
network that wish to communicate using port
4000, and a third host, C, that is also in the
same network and wishes to attack A and/or B.
All three hosts have credentials and
certificates issued by CA X. Let's also imagine
that A is connected to its network via a
wireless link and is dynamically address.</t>
<t>B is listening on port 4000. A initiates a
connection from port 32800 to B on port
4000.</t>
<t>We'll assume no IPsec APIs, but that TCP creates
latches where possible.</t>
<t>We'll consider three cases: a) A and B both
support connection latching, b) only A does, c)
only B does. For the purposes of this example
the SAD is empty on all three hosts when A
initiates its TCP connection to B on port 4000.</t>
<t>When an application running on A initiates a TCP
connection to B on port 4000, A will begin by
creating a connection latch. Since the SAD is
empty A will initiate an IKEv2 exchange to
create an IKE_SA with B and a pair
of CHILD SAs for the 5-tuple {TCP, A, 32800, B,
4000}, then a new latch will be created in
ESTABLISHED state. Sometime later TCP will send
a SYN packet protected by the A-to-B child
SA, per the SPD.</t>
<t>When an application running on B creates a TCP
listener "socket" on port 4000, B will create a
LISTENER connection latch for the 3-tuple {TCP,
B, 4000}. When B receives A's TCP SYN packet it
will then create a connection latch for {TCP, B,
4000, A, 32800}. Since by this point CHILD SAs
have been created whose traffic selectors
encompass this 5-tuple and there are no other
conflicting SAs in the SAD, this connection
latch will be created in the ESTABLISHED
state.</t>
<t>If C attempts to mount a man-in-the-middle attack
on A (i.e., pretend to have B's address(es)) any
time after A created its connection latch then
C's SAs with A will cause the connection latch
to break, and the TCP connection to be reset
(since we assume no APIs by which TCP could
notify the application of the connection latch
break). If C attempts to impersonate A to B
then the same thing will happen on B.</t>
<t>If A does not support connection latching then C
will be able to impersonate B to A at any time,
but without having seen the cleartext of traffic
between A and B, C will be limited by the TCP
sequence numbers to attacks such as RST
attacks. Similarly if B does not support
connection latching.</t>
</section>
</section>
<section anchor="packet_tagging"
title="Informative model: local packet tagging">
<t>In this section we describe connection latching in
terms of interfaces between ULPs and IPsec based on
tagging packets as they go up and down the IP stack.</t>
<t>This section is INFORMATIVE.</t>
<t>In this model the ULPs maintain connection latch
objects and state, rather than the IPsec key
manager, as well as effectively caching a subset of
the decorrelated SPD in ULP TCBs. Local tagging of
packets as they move up and down the stack with SA
identifiers then allows the ULPs to enforce
connection latching semantics. These tags, of
course, don't appear on the wire.</t>
<t>The interface between the ULPs and IPsec interface is
as follows:
<list style='symbols'>
<t>The IPsec layer tags all inbound protected
packets addressed to the host with the index
of the SAD entry corresponding to the SA
that protected the packet.</t>
<t>The IPsec layer understands two types of tags
on outbound packets:
<list style='symbols'>
<t>a tag specifying a set of latched
parameters (peer ID, quality of
protection, etc...) that the IPsec
layer will use to find or acquire an
appropriate SA for protecting the
outbound packet (else IPsec will
inform the ULP and drop the
packet);</t>
<t>a tag requesting feedback about the
SA used to protect the outgoing
packet, if any.</t>
</list>
</t>
</list>
</t>
<t>ULPs create latched connections by interfacing with
IPsec below as follows:
<list style='symbols'>
<t>When the ULP passes a connection's initiating
packet to IP the ULP requests feedback about
the SA used to protect the outgoing packet,
if any, and may specify latching parameters
requested by the application. If the packet
is protected by IPsec then the ULP records
certain parameters of the SA used to protect
it in the connection's TCB.</t>
<t>When a ULP receives a connection's initiating
packet it processes the IPsec tag of the
packet, and it records in the connection's
TCB the parameters of the SA that should be
latched.</t>
</list>
</t>
<t>Once SA parameters are recorded in a connection's TCB
the ULP enforces the connection's latch, or binding,
to these parameters as follows:
<list style='symbols'>
<t>The ULP processes the IPsec tag of all
inbound packets for a given connection and
checks that the SAs used to protect input
packets match the connection latches
recorded in the TCBs. Packets which are not
so protected are dropped (this corresponds
to transitioning the connection latch to the
BROKEN state until the next acceptable
packet arrives, but in this model this
transition is imaginary), or cause the ULP
to break the connection latch and inform the
application.</t>
<t>The ULP always requests that outgoing packets
be protected by SAs that match the latched
connection by appropriately tagging outbound
packets.</t>
</list>
</t>
<t>By effectively caching a subset of the decorrelated
SPD in ULP TCBs and through its packet tagging
nature, this method of connection latching can also
optimize processing of the SPD by obviating the need
to search it, both, on input and output, for packets
intended for the host or originated by the host.
This makes implementation of the OPTIONAL "logical
SPD" updates described in <xref
target='key_manager'/> and <xref
target='optional_protection'/> an incidental
side effect of this approach.</t>
<t>This model of connection latching may not be workable
with ESP/AH offload hardware that does not support
the packet tagging scheme described above.</t>
<t>Note that this model has no BROKEN connection latch
state.</t>
<t>Extending the ULP/IPsec packet-tagging interface to
the application for use with connection-less
datagram transports should enable applications to
use such transports and implement connection
latching at the application layer.</t>
</section>
<section anchor='bits_and_sg_conn_latching' title="Non-native mode IPsec">
<t>This section is INFORMATIVE.</t>
<t>Non-native IPsec implementations, primarily BITS and
SG, can implement connection latching too. One
major distinction between native IPsec and
BITS/BITW/SG IPsec is the lack of APIs for
applications at the end-points in the case of the
latter. As a result there can be no uses of the
latch management interfaces as described in <xref
target='key_manager'/>, not at the ULP
end-points. Therefore BITS/BITW/SG implementations
must discern ULP connection state from packet
inspection (which many firewalls can do) and emulate
calls to the key manager accordingly.</t>
<t>When a connection latch is broken a BITS/BITW/SG
implementation may have to fake a connection reset
by sending appropriate packets (e.g., TCP RST
packets), for the affected connections.</t>
<t>As with all stateful middle-boxes this scheme suffers
from the inability of the middle-box to interact
with the applications. For example, connection
death may be difficult to ascertain. Nor can
channel binding applications work with channels
maintained by proxy without being able to
communicate (securely) about it with the
middle-box.</t>
</section>
<!--
<section anchor='latch_death' title="Conflict Resolution">
<t>Consider a system, say, an IMAP server, with an IPsec
policy allowing all peers with certificates issued
by some CA to claim any dynamically allocated
address in a local network.</t>
<t>In such an environment a peer might appear using some
address, then disappear (e.g., a laptop whose
battery runs out) and another peer might later
(after the first peer's DHCP lease expires) appear
using the same IP address as the first peer. The
first peer might have had a long-lived TCP
connection open with the server. The new peer might
try to open a connection with the same server and
with the same 5-tuple as the first peer. The new
peer's TCP SYN packet will fail to match the
existing connection's latch.</t>
<t>In such cases implementations based on <xref
target='key_manager'/> and <xref
target='bits_and_sg_conn_latching'/> will be
unable to narrow the new peer's child SA proposals
to avoid a conflict. The implementation is REQUIRED
then to transition the existing connection latch to
the BROKEN state and inform its ULP/application
owner.</t>
</section>
-->
<section anchor="note_about_peer_IDs" title="Implementation
Note Regarding Peer IDs">
<t>One of the recommendations for connection latching
implementators is to make available peer CERT
payloads (certificates) to the applications.</t>
<t>Additionally, raw public keys are likely to be used
in the construction of channel bindings for IPsec
channels; see <xref
target='I-D.williams-ipsec-channel-binding'/>,
and must be available, in any case, in order to
implement leap-of-faith at the application layer
(see <xref target='RFC5386'/> and <xref
target='RFC5387'/>).</t>
<t>Certificates and raw public keys are large bit
strings, too large to be reasonably kept in
kernel-mode implementations of connection latching
(which will likely be the typical case). Such
implementations should intern peer IDs in a
user-mode database and use small integers to refer
to them from the kernel-mode SAD and LD. Corruption
of such a database is akin to corruption of the
SAD/LD; in the event of corruption the
implementation MUST act as though all ESTABLISHED
and BROKEN connection latches are administratively
transitioned to the CLOSED state. Implemenations
without IPsec APIs MAY hash peer IDs and use the
hash to refer to them, preferably using a strong
hash algorithm.</t>
</section>
</section>
<section anchor="optional_features" title="Optional Features">
<t>At its bare minimum connection latching is a passive
layer atop IPsec that warn ULPs of SPD and SAD changes
that are incompatible with the SPD/SAD state that was
applicable to a connection when it was established.</t>
<t>There are some optional features, such as (abstract)
APIs. Some of these features make connection latching a
somewhat more active feature. Specifically, the
optional logical SPD updates described in <xref
target='key_manager'/> and the optional
protection/bypass feature described in the following
sub-section.</t>
<section anchor="optional_protection" title="Optional
Protection">
<t>Given IPsec APIs an application could request that a
connection's packets be protected where they would
otherwise be bypassed; that is, applications could
override BYPASS policy. Locally privileged
applications could request that their connections'
packets be bypassed rather than protected; that is,
privileged applications could override PROTECT
policy. We call this "optional protection."</t>
<t>Both native IPsec models of connection latching can
be extended to support optional protection. With
the model described in <xref
target='packet_tagging'/> optional protection
comes naturally: the IPsec layer need only check
that the protection requested for outbound packets
meets or exceeds (as determined by local or system
policy) the quality of protection, if any, required
by the SPD. Similarly, for the model described in
<xref target='key_manager'/> the check that
requested protection meets or exceeds that required
by the SPD is performed by the IPsec key manager
when creating connection latch and connection latch
listener objects.</t>
<t>When an application requests, and local policy
permits, either additional protection or bypassing
protection, then the SPD MUST be logically updated
such that there exists a suitable SPD entry
protecting or bypassing the exact 5-tuple recorded
by the corresponding connection latch. Such logical
SPD updates MUST be made at connection latch
creation time, and MUST be made atomically (see the
note about race conditions in <xref
target='key_manager'/>). Such updates of the
SPD MUST NOT survive system crashes or reboots.</t>
</section>
</section>
<section title="Simulataneous latch establishment">
<t>Some connection-oriented ULPs, specifically TCP, support
simulaneous connections (where two clients connect to
each other, using the same 5-tuple, at the same time).
Connection latching supports simultaneous latching as
well, provided that the key exchange protocol does not
make it impossible.</t>
<t>Consider two applications doing a simultaneous TCP
connect to each other and requesting an IPsec channel.
If they request the same connection latching parameters,
then the connection and channel should be established as
usual. Even if the key exchange protocol in use doesn't
support simultaneous IKE_SA and/or child SA
establishment, provided one peer's attempt to create the
necessary child SAs succeeds then the other peer should
be able to notice the new SAs immediately upon failure
of its attempts to create the same.</t>
<t>If, however, the two peer applications were to request
different connection latching parameters, then the
connection latch must fail on one end or on both
ends.</t>
</section>
<section title="Connection Latching to IPsec for Various ULPs">
<t>The following sub-sections describe connection latching
for each of three transport protocols. Note that for
TCP and UDP there is nothing in the following sections
that should not already be obvious from the remainder of
this document. The section on SCTP, however, specifies
details related to SCTP multi-homing, that may not be as
obvious.</t>
<section title="Connection Latching to IPsec for TCP">
<t>IPsec connection latch creation/release for TCP <xref
target='RFC0793'/> connections is triggered
when:
<list style='symbols'>
<t>A TCP listener end-point is created (e.g.,
when the BSD sockets listen() function is
called on a socket). This should cause the
creation of a LISTENER connection latch.</t>
<t>A TCP SYN packet is received on an IP address
and port number for which there is a
listener. This should cause the creation of
an ESTABLISHED or BROKEN connection
latch.</t>
<t>A TCP SYN packet is sent (e.g., as the result
of a call to the BSD sockets connect()
function). This should cause the creation
of an ESTABLISHED or BROKEN connection
latch.</t>
<t>Any state transition of a TCP connection to
the CLOSED state will cause a corresponding
transition for any associated connection
latch to the CLOSED state as well.</t>
</list>
</t>
<t>When a connection latch transitions to the BROKEN
state and the application requested (or system
policy dictates it) that the connection be broken,
then TCP should inform the application, if there is
a way to do so, or else it should wait, allowing the
TCP keepalive (or application-layer keepalive
strategy) to timeout the connection, if enabled.
When a connection latch is administratively
transitioned to the CLOSED state then TCP should act
as though an RST packet has been received.</t>
</section>
<section title="Connection Latching to IPsec for UDP with
Simulated Connections">
<t>UDP <xref target='RFC0768'/> is a connection-less
transport protocol. However, some networking APIs
(e.g., the BSD sockets API) allow for emulation of
UDP connections. In this case connection latching
can be supported using either model given above. We
ignore, in this section, the fact that the
connection latching model described in <xref
target='packet_tagging'/> can support
per-datagram latching by extending its packet
tagging interfaces to the application.</t>
<t>IPsec connection latch creation/release for UDP
connections is triggered when:
<list style='symbols'>
<t>An application creates a UDP "connection."
This should cause the creation of an
ESTABLISHED or BROKEN connection latch.</t>
<t>An application destroys a UDP "connection."
This should cause the creation of an
ESTABLISHED or BROKEN connection latch.</t>
</list>
</t>
<t>When a connection latch transitions to the BROKEN
state and the application requested (or system
policy dictates it) that the connection be broken,
then UDP should inform the application, if there is
a way to do so, or else it should wait, allowing the
application-layer keepalive/timeout strategy, if
any, to timeout the connection.</t>
<t>What constitutes an appropriate action in the face of
administrative transitions of connection latches to
the CLOSED state depends on whether the
implementation's "connected" UDP sockets API
provides a way for the socket to return an error
indicating that it has been closed.</t>
</section>
<section title="Connection Latching to IPsec for UDP with
Datagram-Tagging APIs">
<t>Implementations based on either model of connection
latching can provide applications with
datagram-tagging APIs based on those described in
<xref target='packet_tagging'/>. Implementations
UDP with of the normative model of IPsec connection
latching have to confirm, on output, that the
application provided 5-tuple agrees with the
application-provided connection latch; on input, UDP
can derive the tag by searching for a connection
latch matching incoming datagram's 5-tuple.</t>
</section>
<section title="Connection Latching to IPsec for SCTP">
<t>SCTP <xref target='RFC4960'/> a connection-oriented
protocol similar, in some ways, to TCP. The salient
difference, with respect to connection latching,
between SCTP and TCP is that SCTP allows each
end-point to be identified by a set of IP addresses,
though, like TCP, each end-point of an SCTP
connection (or, rather, SCTP association) can only
have one port number.</t>
<t>We can represent the multiplicity of SCTP association
end-point addresses as a multiplicity of 5-tuples,
each of which with its own a connection latch.
Alternatively we can extend the connection latch
object to support a multiplicity of addresses for
each end-point. The first approach is used
throughout this document, therefore we will assume
that representation.</t>
<t>Of course, this approach results in N x M connection
latches for any SCTP associations (where one
end-point has N addresses and the other has M),
whereas the alternative requires one connecton latch
per-SCTP association (with N + M addresses).
Implementors may choose either approach.</t>
<t>IPsec connection latch creation/release for SCTP
connections is triggered when:
<list style='symbols'>
<t>An SCTP listener end-point is created (e.g.,
when the SCTP sockets listen() function is
called on a socket). This should cause the
creation of a LISTENER connection latch for
each address of the listener.</t>
<t>An SCTP INIT chunk is received on an IP
address and port number for which there is a
listener. This should cause the creation of
one or more ESTABLISHED or BROKEN connection
latches, one for each distinct 5-tuple given
the client and server's addresses.</t>
<t>An SCTP INIT chunk is sent (e.g., as the
result of a call to the SCTP sockets
connect() function). This should cause the
creation of one or more ESTABLISHED or
BROKEN connection latches.</t>
<t>An SCTP ASCONF chunk <xref target='RFC5061'/>
adding an end-point IP address is sent or
received. This should cause the creation of
one or more ESTABLISHED or BROKEN connection
latches.</t>
<t>Any state transition of an SCTP association
to the CLOSED state will cause a
corresponding transition for any associated
connection latches to the CLOSED state as
well.</t>
<t>An SCTP ASCONF chunk <xref target='RFC5061'/>
deleting an end-point IP address is sent or
received. This should cause one or more
associated connection latches to be
CLOSED.</t>
</list>
</t>
<t>When a connection latch transitions to the BROKEN
state and the application requested (or system
policy dictates it) that the connection be broken,
then SCTP should inform the application, if there is
a way to do so, or else it should wait, allowing
SCTP path/endpoint failure detection (and/or
application-layer keepalive strategy) to timeout the
connection. When a connection latch is
administratively transitioned to the CLOSED state
then SCTP should act as though an ABORT chunk has
been received.</t>
</section>
</section>
<section title="Security Considerations">
<section title="Impact on IPsec">
<t>Connection latching effectively adds a mechanism for
dealing with the existence, in the SAD, of multiple
non-equivalent child SAs with overlapping traffic
selectors. This mechanism consists of, at minimum,
a local notification of transport protocols (and,
through them, applications) of the existence of such
a conflict which affects a transport layer's
connections. Affected transports are also notified
when the conflict is cleared. The transports must
drop inbound packets, and must not send outbound
packets for connections which are affected by a
conflict. In this minimal form connection latching
is a passive, local feature layered atop IPsec.</t>
<t>Connection latching achieves this by adding a new
type of IPsec database, the Latch Database (LD),
containing objects which represent a transport
protocol's interest in protecting a given packet
flow from such conflicts. The LD is managed in
conjunction with updates to the SAD and the SPD, so
that updates to either which conflict with
established connection latches can be detected. For
some IPsec implementations this may imply
significant changes to their internals. However,
two different models of connection laching are
given, and we hope that most native IPsec
implementators will find one model to be
significantly simpler to implement than the
other, and simple enough to implement.</t>
<t>This notion of conflicting SAs and how to deal with
the situation does not modify the basic IPsec
architecture -- the feature of IPsec which allows
such conflicts to arise remains, and it is up to the
transport protocols and applications to select
whether and how to respond to them.</t>
<t>There are, however, interesting corner cases in the
normative model of connection latching that
implementors must be aware of. The notes in <xref
target='race_cond'/> are particularly
relevant.</t>
</section>
<section title="Impact on IPsec of Optional Features">
<t><xref target='optional_features'/> describes optional
features of connection latching where the key
manager takes on a somewhat more active, though
still local, role. There are two such features:
optional protect/bypass, and preservation of
"logical" SPD entries to allow latched connections
to remain in the ESTABLISHED state in the face of
adverse administrative SPD (but not SAD)
changes. These two features interact with
administrative interfaces to IPsec; administrators
must be made aware of these features, and SHOULD be
given a way to break ESTABLISHED connection latches.
Also, given recent trends toward centralizing parts
of IPsec policy, these two features can be said to
have non-local effects where they prevent
distributed policy changes from taking effect
completely.</t>
</section>
<section title="Security Considerations for Applications">
<t>Connection latching protects individual connections
from weak peer ID<->address binding, IPsec
configuration changes, and from configurations that
allow multiple peers to assert the same addresses.
But connection latching does not ensure that any two
connections with the same end-point addresses will
have the same latched peer IDs. In other words,
applications that use multiple concurrent
connections between two given nodes may not be
protected any more or less by use of IPsec
connection latching than by use of IPsec alone
without connection latching. Such multi-connection
applications can, however, examine the latched SA
parameters of each connection to ensure that all
concurrent connections with the same end-point
addresses also have the same end-point IPsec
IDs.</t>
<t>Connection latching protects against TCP RST attacks.
It does not help, however, if the original peer of a
TCP connection is no longer available (e.g., if an
attacker has been able to interrupt the network
connection between the two peers).</t>
</section>
<section title="Channel Binding and IPsec APIs">
<t>IPsec channels are a pre-requisite for channel
binding <xref target='RFC5056'/> to IPsec.
Connection latching provides such channels, but the
channel bindings for IPsec channels (latched
connections) are not specified herein -- that is a
work in progress <xref
target='I-D.williams-ipsec-channel-binding'/>.</t>
<t>Without IPsec APIs connection latching provides
marginal security benefits over traditional IPsec.
Such APIs are not described herein; see <xref
target='I-D.ietf-btns-abstract-api'/>.</t>
</section>
</section>
<section title="IANA Considerations">
<t>There are not IANA considerations for this document.</t>
</section>
<section title="Acknowledgements">
<t>The author thanks Michael Richardson for all his help, as
well as Stephen Kent, Sam Hartman, Bill Sommerfeld, Dan
McDonald, Daniel Migault, and many others who've
participated in the BTNS WG or who've answered questions
about IPsec, connection latching implementations,
etc...</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;&rfc5386;&rfc4306;&rfc4301;
<!-- TCP RFCs -->
&rfc0793;
<!-- UDP RFCs -->
&rfc0768;
<!-- SCTP RFCs -->
&rfc4960;&rfc5061;
</references>
<references title="Informative References">
&rfc1034;&bellovin-useipsec;&dondeti-useipsec;&rfc5056;
&rfc5387;
&btns-abstract-api;&ipsec-channel-binding;
<reference anchor='IP_SEC_OPT.man'>
<front>
<title>Solaris ipsec(7P) manpage</title>
<author fullname='various'>
<organization abbrev='Sun'>
Sun Microsystems, Inc.
</organization>
</author>
<date month='October' year='2006'/>
</front>
<format type='HTML'
target='http://docs.sun.com/app/docs/doc/816-5177/ipsec-7p?a=view'/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-19 07:13:55 |