One document matched: draft-ietf-btns-connection-latching-02.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 rfc2119 SYSTEM '/var/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc2025 SYSTEM '/var/bibxml/reference.RFC.2025.xml'>
<!ENTITY rfc0854 SYSTEM '/var/bibxml/reference.RFC.0854.xml'>
<!ENTITY rfc1035 SYSTEM '/var/bibxml/reference.RFC.1035.xml'>
<!ENTITY rfc3008 SYSTEM '/var/bibxml/reference.RFC.3008.xml'>
<!ENTITY rfc2203 SYSTEM '/var/bibxml/reference.RFC.2203.xml'>
<!ENTITY rfc2367 SYSTEM '/var/bibxml/reference.RFC.2367.xml'>
<!ENTITY rfc2623 SYSTEM '/var/bibxml/reference.RFC.2623.xml'>
<!ENTITY rfc3530 SYSTEM '/var/bibxml/reference.RFC.3530.xml'>
<!ENTITY rfc2478 SYSTEM '/var/bibxml/reference.RFC.2478.xml'>
<!ENTITY rfc2743 SYSTEM '/var/bibxml/reference.RFC.2743.xml'>
<!ENTITY rfc2744 SYSTEM '/var/bibxml/reference.RFC.2744.xml'>
<!ENTITY rfc1964 SYSTEM '/var/bibxml/reference.RFC.1964.xml'>
<!ENTITY rfc2408 SYSTEM '/var/bibxml/reference.RFC.2408.xml'>
<!ENTITY rfc2409 SYSTEM '/var/bibxml/reference.RFC.2409.xml'>
<!ENTITY rfc4301 SYSTEM '/var/bibxml/reference.RFC.4301.xml'>
<!ENTITY rfc4306 SYSTEM '/var/bibxml/reference.RFC.4306.xml'>
<!ENTITY rfc4322 SYSTEM '/var/bibxml/reference.RFC.4322.xml'>
<!ENTITY on-channel-binding SYSTEM '/var/bibxml/reference.I-D.williams-on-channel-binding.xml'>
<!ENTITY btns-applic SYSTEM '/var/bibxml/reference.I-D.ietf-btns-prob-and-applic.xml'>
<!ENTITY btns-core SYSTEM '/var/bibxml/reference.I-D.ietf-btns-core.xml'>
<!ENTITY btns-abstract-api SYSTEM '/var/bibxml/reference.I-D.ietf-btns-abstract-api.xml'>
<!ENTITY useipsec SYSTEM '/var/bibxml/reference.I-D.bellovin-useipsec.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc tocindent="no" ?>
<?rfc autobreaks="no" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<rfc ipr="full3978" docName="draft-ietf-btns-connection-latching-02.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="September" year="2007"/>
<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. This 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.</t>
<t>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. A model of of
connection latching based on a modification to the child
SA authorization process is given.</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 BTNS <xref target='I-D.ietf-btns-prob-and-applic'/>
is used.</t>
<t>A method is desired for creating "IPsec channels," that
is, packet flows predictably protected for their
duration, even in the face of IPsec reconfiguration or
weak association of peer IDs and addresses. The methods
outlined below achieve this by interfacing ULPs and
applications to IPsec and using these interfaces to bind
("latch") connections to peer IDs and SA parameters.</t>
<section 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>
</section>
</section>
<section 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>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>Peer identity: peers' asserted and
authorized IDs, as per the IPsec processing
model <xref target='RFC4301'/> and BTNS <xref
target='I-D.ietf-btns-core'/>.</t>
</list>
</t>
<t>Implementations SHOULD provide applications with APIs for
inquiring whether a connection is latched and what the
latched parameters are. Implementations SHOULD provide
applications with some control, through application
programming interfaces (APIs) <xref
target='I-D.ietf-btns-abstract-api'/>, over what
quality of protection, or the expected identity of a
peer. If an application does not use such interfaces
then it will obtain default quality of protection
derived from system policy. Implementations MAY
create IPsec channels automatically by default when the
application does not request an IPsec channel.</t>
<t>IPsec channels have the following states:
<list style='symbols'>
<t>Listener</t>
<t>Larval (in the process of being established)</t>
<t>Established</t>
<t>Failed</t>
</list>
</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 (they must be dropped) until the
channel is established.</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
must be dropped).</t>
<t>Native 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 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.</t>
<t>Implementations that provide such programming
interfaces MUST make available to applications
NAT-related information about the peer: whether
it is behind a NAT and, if it is, the inner and
outer tunnel addresses of the peer.</t>
<t>Native 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
privilege. <vspace blankLines='1'/> (Typical
system policy may not allow applications any
freedom here. Policy extensions allowing for
optional protection are described in <xref
target="bypass_or_protect"/>.)</t>
<t>The parameters latched in an IPsec channel MUST
remain unchanged once the channel is
established.</t>
<t>Timeouts while establishing an SA with parameters
that match a 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. Failure to
establish an appropriate SA for an IPsec channel
MAY be communicated to the ULP and application
(e.g., as though the connection had been
reset)</t>
<t>Implementations that have a restartable key
management process (or "daemon") MUST arrange
for existing latched connections to either be
reset and disconnected, or for them to survive
the restart of key exchange processes. (This is
implied by the above requirements.)</t>
<t>Any IPsec channel created with a given peer while
another distinct, established IPsec channel
exists with the same source and destination
addresses SHOULD be bound to the same peer.</t>
</list>
</t>
<t>We describe two models (one normative) of IPsec channels
for native IPsec implementations. Both models should
suffice for all-software native implementations of
IPsec. One the other or both models should be workable
for most native implementations where part of the IPsec
stack is implemented in hardware. The normative model
is based on abstract programming interfaces between ULPs
and the key management component of IPsec, plus a
modification to the child SA authorization process. The
second model is based on abstract programming interfaces
between ULPs and the ESP/AH layer in the IP stack. Both
models imply extensions to any PF_KEY-like protocols
<xref target="RFC2367"/> that may be used internally by
the implementation.</t>
<t>We also provide a model for non-native implementations,
such as bump-in-the-stack (BITS) and 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. As such this third model is not suitable for
channel binding applications <xref
target='I-D.williams-on-channel-binding'/>.</t>
<section anchor="pad_interfaces"
title="Normative Model: ULP interfaces to the key
manager and child SA authorization process extensions">
<t>This section is NORMATIVE.</t>
<t>In this section we describe connection latching in
terms of an 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 requires an extension to the IPsec child
SA authorization process such that no SAs
conflicting with a connection latch are allowed.
Normally the IPsec processing model does allow SAs
with different peers but overlapping traffic
selectors -- behaviour that, in this model, directly
violates the requirements for connection
latching.</t>
<t>The ULP interfaces to the IPsec PAD database are as
follows:
<list style='symbols'>
<t>Create a connection latch listener object for
a ULP 3-tuple (local address, protocol and
local port number). This operation succeeds
whenever there are no other connection latch
listeners for the same 3-tuple. Connection
latch listener objects can result in
connection latch objects when a child SA is
created whose traffic selectors encompass
the given 3-tuple.</t>
<t>Create a connection latch object for a ULP
5-tuple (local and remote address, protocol
and local and remote port numbers). This
operation succeeds when no conflicting
connection latch objects exist and when
there exist no child SAs encompassing the
given 5-tuple or when all such SAs are with
the same peer and equal quality of
protection.</t>
<t>Destroy a connection latch listener
object.</t>
<t>Destroy a connection latch object.</t>
<t>Inquire whether a connection latch exists for
a given 5-tuple, its state, and its latched
parameters.</t>
</list>
</t>
<t>The IPsec processing model is modified as follows:
<list style='numbers'>
<t>The API described above is a new service of
the IPsec key manager. In particular the
IPsec key manager has to reject new
connection latches that conflict with others
or with current SAD state.</t>
<t>At child SA creation time the IPsec key
manager MUST reject child SA proposals that
would conflict with an established
connection latch, or else it MUST narrow
such proposed child SAs such that the
resulting SAs do not conflict with
established connection latches.</t>
</list>
</t>
<t>Implementations SHOULD provide a flag for PAD entries
such that PAD entries so flagged will result in the
key manager rejecting any connection latch requests
with remote addresses which peers matching those PAD
entries may assert. This flag makes it possible to
preserve traditional IPsec child SA authorization
semantics where desired. Alternatively
implementations MAY provide a flag to disable or
enable connection latching altogether.</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
should be passed along.</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
should be passed along.</t>
<t>When a latched connection is torn down and no
further packets are expected for it then the
ULP will request that the connection latch
object be destroyed.</t>
<t>When tearing down a listener the ULP will
request that the connection latch listener
object be destroyed.</t>
<t>When a ULP listener rejects connections for
non-existent 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>
</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 SAD entries corresponding to the SAs that
protected them.</t>
<t>Note that there is a race condition in this method of
connection latching: packets may race with the ULP
and the IPsec key manager's manipulation of
connection latch objects and SAD entries. As a
result ULPs may not be able to trust some packets
even though a suitable connection latch object may
exist. Implementations MUST prevent such races.
One method to prevent these races is to tag packets
passed up by the ESP/AH layer with a key manager
state version number that is monotonically
incremented every time that connection latching
state changes; this version number must be
incremented atomically relative to the SAD,
including SAD subsets stored on IPsec offload
hardware. Other methods may be possible, including
dropping packets that arrive within a certain amount
of time since the creation/destruction of connection
latch objects (e.g., if the maximum latency within
the key manager and IP stack is known and
guaranteed).</t>
</section>
<section anchor="intimate_interfaces"
title="Using Intimate Interfaces Between ULPs and IPsec">
<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>The ULPs and IPsec interface through a local packet
tagging scheme (the tags don't appear on the wire):
<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
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 transmission control
block (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.</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>The main benefit of this model of connection latching
is its simplicity. For example, no changes need be
made to the child SA authorization process.
However, this model of connection latching is not
workable with ESP/AH offload hardware that does not
support the packet tagging scheme described
above.</t>
</section>
<section anchor='bits_and_sg_conn_latching' title="Non-native mode IPsec">
<t>[Fill this out. Basically, for BITS/BITW/SG
implementations connection latching requires
inspecting packets to discern ULP connection state,
recording such state, and establishing associated
connection latches. Like all stateful middle-boxes
this 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 proxy.]</t>
<t>[Sam requested this section offline, and believe we
need a PAD entry flag to indicate which PAD entries'
addresses (child SA constraints) are subject to
connection latching, and which are not. Sam
believes this is needed in the native IPsec model
based on extending the child SA authorization
process; I disagree. -Nico]</t>
</section>
</section>
<section anchor="bypass_or_protect" 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." Note that optional
protection as described here does not provide a way to
override DISCARD policy.</t>
<t>Both native IPsec models of connection latching can be
extended to support optional protection. With the model
described in <xref target='intimate_interfaces'/>
optional protection comes naturally: the IPsec layer
need only check that the protection requested for
outbound packets meets or exceeds the quality of
protection, if any, required by the SPD. Similarly, for
the model described in <xref target='pad_interfaces'/>
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>
</section>
<section title="Security Considerations">
<t>Connection latching protects only individual connections
from weak peer ID<->address binding, IPsec
configuration changes, and from configurations that
allow multiple peers to assert the same addresses, but
it does not ensure that any two connections with the
same end-point addresses, even if one established while
the other is alive, will have the same latched peer IDs.
In other words, applications that use multiple
concurrent connections between two given nodes are not
protected any more or less by use of IPsec connection
latching than by use of IPsec alone. Such
multi-connection applications can, however, examine the
latched SA parameters of each connection to ensure that
each every connection with the same end-point addresses
also has the same end-point IPsec IDs.</t>
<t>IPsec channels are a pre-requisite for channel binding
<xref target='I-D.williams-on-channel-binding'/> to
IPsec. Connection latching provides such channels, but
the process of binding IPsec channels (latched
connections) to authentication at application layers is
not specified herein.</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 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, 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;&btns-applic;&btns-core;&btns-abstract-api;&rfc4306;&rfc4301;&rfc4322;&rfc2367;
</references>
<references title="Informative References">
&useipsec;&on-channel-binding;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-19 07:16:43 |