One document matched: draft-ietf-btns-connection-latching-05.txt
Differences from draft-ietf-btns-connection-latching-04.txt
NETWORK WORKING GROUP N. Williams
Internet-Draft Sun
Expires: July 13, 2008 January 10, 2008
IPsec Channels: Connection Latching
draft-ietf-btns-connection-latching-05.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 13, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Williams Expires July 13, 2008 [Page 1]
Internet-Draft IPsec Connection Latching January 2008
Abstract
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.
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 is given.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions used in this document . . . . . . . . . . . . . 4
2. Connection Latching . . . . . . . . . . . . . . . . . . . . 5
2.1. Connection latch state machine . . . . . . . . . . . . . . . 8
2.2. Normative Model: ULP interfaces to the key manager . . . . . 9
2.3. Informative model: local packet tagging . . . . . . . . . . 13
2.4. Non-native mode IPsec . . . . . . . . . . . . . . . . . . . 14
2.5. Conflict Resolution . . . . . . . . . . . . . . . . . . . . 15
3. Optional protection . . . . . . . . . . . . . . . . . . . . 16
4. Simulataneous latch establishment . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . 18
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Normative References . . . . . . . . . . . . . . . . . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . 24
Williams Expires July 13, 2008 [Page 2]
Internet-Draft IPsec Connection Latching January 2008
1. Introduction
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
[I-D.ietf-btns-prob-and-applic] is used.
Applications that wish to use IPsec may have to ensure that local
policy on the various end-points is configured appropriately
[I-D.bellovin-useipsec] [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 [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 SPD configuration, application
specifications must also address PAD/SPD configuration to strongly
bind individual addresses to individual IPsec identities and
credentials (certificates, public keys, ...).
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 and TCP can
make use of IPsec with minimal changes.
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.
If widely adopted, connection latching could make application use of
IPsec much simpler, at least for certain classes of applications.
Note: the terms "connection latch" and "IPsec channel" are used
interchangeably below. The latter term relates to "channel binding"
[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).
Williams Expires July 13, 2008 [Page 3]
Internet-Draft IPsec Connection Latching January 2008
1.1. Conventions used in this document
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 [RFC2119].
Williams Expires July 13, 2008 [Page 4]
Internet-Draft IPsec Connection Latching January 2008
2. Connection Latching
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:
o the peer's identity is the same for the lifetime of the packet
flow
o 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
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).
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:
o Type of protection: confidentiality and/or integrity protection;
o Transport mode vs. tunnel mode;
o Quality of protection: cryptographic algorithm suites, key
lengths, and replay protection;
o Peer identity: peers' asserted and authorized IDs, as per the
IPsec processing model [RFC4301] and BTNS [I-D.ietf-btns-core].
Additionally, there SHOULD be an optional way for applications to
specify the conflict resolution behaviour of an IPsec channel (see
description of the SUSPENDED and BROKEN connection latch states in
Section 2.1): whether to wait for the conflict to disappear, or
whether to break the channel. The default for this option SHOULD be
"break the channel", and MAY be configurable through local policy.
The 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 -- new ones
can be negotiated as necessary without compromising the security
guarantees of the channel -- because operational considerations of
the various key exchange protocols then cannot affect the design and
Williams Expires July 13, 2008 [Page 5]
Internet-Draft IPsec Connection Latching January 2008
features of connection latching.
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)
[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.
Requirements and recommendations:
o If an IPsec channel is desired then packets for a given connection
MUST NOT be sent until the channel is established.
o 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.
o 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.
o 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.
o Native implementations SHOULD provide programming interfaces for
inquiring the values of the parameters latched in a connection.
o 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.
o Implementations that provide such programming interfaces SHOULD
make available to applications any available 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.
Williams Expires July 13, 2008 [Page 6]
Internet-Draft IPsec Connection Latching January 2008
o 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.
(Typical system policy may not allow applications any freedom
here. Policy extensions allowing for optional protection are
described in Section 3.)
o The parameters latched in an IPsec channel MUST remain unchanged
once the channel is established.
o 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 SHOULD be communicated to the ULP and
application, and MAY cause the IPsec channel to be broken (which
MUST be communicated to the ULP and application).
o 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., potentially large values, 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.
o Dynamic IPsec policy related to connection latches MUST be torn
down when latched connections are torn down, even when the latter
is implied, such as at crash/halt/reboot time.
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. The second model is based on abstract
programming interfaces between ULPs and the IPsec (ESP/AH) layer in
the IP stack.
Williams Expires July 13, 2008 [Page 7]
Internet-Draft IPsec Connection Latching January 2008
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 extended to support connection
latching with unconnected datagram sockets, while the other model
cannot be so extended. There may be other minor differences between
the two models; rather than seek to prove equivalency for some set of
security guarantees we instead choose one model to be the normative
one.
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 (implementations that do
could be said to be native). As such this third model is not
suitable for channel binding applications [RFC5056].
2.1. Connection latch state machine
Connection latches can exist in any of the following five states:
o LISTENER
o ESTABLISHED
o SUSPENDED (there exist conflicting SAs, waiting for them to expire
or be removed)
o BROKEN (conflicting SAs were created)
o CLOSED (by the ULP, the application or administratively)
and always have an associated owner, or holder, such as a ULP
transmission control block (TCB).
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 sockets and is associated with IP 3-tuples,
and can give rise to new connection latches in the ESTABLISHED state.
A connection latch can also be born in the ESTABLISHED state, either
through the direct initiative of a ULP or when an event occurs that
causes a LISTENER latch to create an ESTABLISHED latch. This state
represents an active connection latch for a traffic flow's 5-tuple.
ESTABLISHED connection latches can transition to the SUSPENDED,
Williams Expires July 13, 2008 [Page 8]
Internet-Draft IPsec Connection Latching January 2008
BROKEN, and CLOSED states.
Connection latches remain in the CLOSED state until their owners are
informed except where the ownser caused the transition, in which case
this state is fleeting. Transitions to the CLOSED state should
typically be initiated by latch owners, but implementations MAY
provide administrative interfaces through which to close active
latches.
Connection latches transition to either the SUSPENDED or BROKEN
states, according to application preference (or system policy), 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 SUSPENDED always
cause the associated owner to be informed. Connection latches in the
SUSPENDED state may transition back to ESTABLISHED when the conflict
is cleared. Transitions to either state always cause the associated
owner to be notified. BROKEN connection latches can only transition
to CLOSED, but SUSPENDED latches can transition to either ESTABLISHED
or CLOSED (see above).
Most state transitions are the result of local actions of the latch
owners (ULPs). The only exceptions are: birth into the ESTABLISHED
state from a LISTENER latch, transitions to the SUSPENDED and BROKEN
states, and administrative transitions to the CLOSED state.
(Additionally, see the implementation note about restartable key
management processes in Section 2.)
The details of the transitions depend on the model of connection
latching followed by any given implementation. See the following
sections.
2.2. Normative Model: ULP interfaces to the key manager
This section is NORMATIVE.
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.
This model adds a service to the IPsec key manager (i.e., the
component that manages the SAD and interfaces with, or 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 traditional IPsec processing model allows the concurrent
Williams Expires July 13, 2008 [Page 9]
Internet-Draft IPsec Connection Latching January 2008
existence of SAs with different peers but overlapping traffic
selectors. Such behaviour, in this model, directly violates the
requirements for connection latching. We address this problem by
requiring that connection latches be broken (and holders informed)
when such conflicts arise.
The ULP interfaces to the IPsec PAD database are as follows:
o CREATE_LISTENER_LATCH(3-tuple, [type and quality of protection
parameters]) -> latch handle
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.
When a child SA is negotiated that would match a listener
latch's 3-tuple then the key manager SHOULD narrow the child SA
so that its local address and port ranges do not include the
3-tuple or so that the SA has only one local address and port
number: the one from the tuple.
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.
o CREATE_CONNECTION_LATCH(5-tuple, [type and quality of protection
parameters], [peer ID], [local ID]) -> latch handle
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, or 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.
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.
Williams Expires July 13, 2008 [Page 10]
Internet-Draft IPsec Connection Latching January 2008
When the key manager tries to create child SAs it should narrow
the proposals so that their traffic selector match no
connection latches in the ESTABLISHED states, or so that they
match only the 5-tuple of a single such connection latch.
o RELEASE_LATCH(latch object handle)
Changes the state of the given connection latch to CLOSED; the
connection latch is then deleted.
The key manager SHOULD 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
[RFC4306]).
o INQUIRE_LATCH(latch object handle) -> latch state, latched
parameters
Returns all available information about the given latch.
Needless to say, the LD is updated whenever a connection latch object
is created, deleted or broken.
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:
o 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 give latch's,
b) its peer, type of protection, or quality of protection
parameters differ from the conflicting SA.
o Child SA proposals that would conflict with an extant connection
latch and whose traffic selectors can be narrowed to avoid the
conflict MUST be narrowed (see section 2.9 of [RFC4306]);
o 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.
Additionally, the key manager MUST protect latched connections
against SPD changes that would change the quality of protection
Williams Expires July 13, 2008 [Page 11]
Internet-Draft IPsec Connection Latching January 2008
afforded to a latched connection's traffic, or which would bypass it.
When such a configuration change takes place the key manager MUST
either preserve a logical SPD entry such that the latched connection
continues to obtain the required protection, or the key manager MUST
break the latch and inform the latch holder (ULP) before the change
takes place. To do this the key manager can 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 actual SPD entry matched
by the connection (possibly augmented by the application's request
for additional protection). Such updates of the SPD MUST NOT survive
system crashes or reboots.
ULPs create latched connections by interfacing with IPsec below as
follows:
o 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.
o 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 (that it does not represent an IPsec channel).
o 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.
If no latch can be created then the ULP will either return an
error to the application or continue with the new connection and
inform the application that the new connection is not latched.
o 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.
o When tearing down a listener the ULP will request that the
connection latch listener object be destroyed.
o 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.
o When the key manager informs a ULP that a connection latch is no
longer valid then the ULP SHOULD reset or otherwise terminate the
connection and MUST inform the application.
Williams Expires July 13, 2008 [Page 12]
Internet-Draft IPsec Connection Latching January 2008
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.
Note that there is a race condition in this method of connection
latching: incoming 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 and the LD, 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).
2.3. Informative model: local packet tagging
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.
This section is INFORMATIVE.
The ULPs and IPsec interface through a local packet tagging scheme
(i.e., the tags don't appear on the wire):
o 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.
o The IPsec layer understands two types of tags on outbound packets:
* 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);
* a tag requesting feedback about the SA used to protect the
outgoing packet, if any.
ULPs create latched connections by interfacing with IPsec below as
Williams Expires July 13, 2008 [Page 13]
Internet-Draft IPsec Connection Latching January 2008
follows:
o 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.
o 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.
Once SA parameters are recorded in a connection's TCB the ULP
enforces the connection's latch, or binding, to these parameters as
follows:
o 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 SUSPENDED 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.
o The ULP always requests that outgoing packets be protected by SAs
that match the latched connection by appropriately tagging
outbound packets.
The receipt of a packet matching a latched connection's 5-tuple, but
protected by an SA with an inappropriate peer, SHOULD be taken as an
indication that the original peer is no longer at the original
address and that the connection SHOULD be reset, the application
informed, and the connection latch removed.
This model of connection latching may not be workable with ESP/AH
offload hardware that does not support the packet tagging scheme
described above.
2.4. Non-native mode IPsec
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 Section 2.2, not at the ULP end-points. Therefore BITS/
Williams Expires July 13, 2008 [Page 14]
Internet-Draft IPsec Connection Latching January 2008
BITW/SG implementations must discern ULP connection state from packet
inspection (which many firewalls can do) and emulate calls to the key
manager accordingly.
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.
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.
2.5. Conflict Resolution
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.
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.
In such cases implementations based on Section 2.2 and Section 2.4
will be unable to narrow the new peer's child SA proposals to avoid a
conflict, and must either reject them (and transition the existing
latch to SUSPENDED) or terminate the existing connection latch (i.e.,
transition it to the BROKEN state).
Implementors MUST provide termination of the existing connection as
the default behaviour in such cases. Implementors MAY provide a
configuration option for selecting the other behaviours.
Williams Expires July 13, 2008 [Page 15]
Internet-Draft IPsec Connection Latching January 2008
3. Optional protection
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."
Both native IPsec models of connection latching can be extended to
support optional protection. With the model described in Section 2.3
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
Section 2.2 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.
When an application requests, and IPsec 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 Section 2.2). Such updates of the SPD MUST NOT survive
system crashes or reboots.
Williams Expires July 13, 2008 [Page 16]
Internet-Draft IPsec Connection Latching January 2008
4. Simulataneous latch establishment
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.
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.
If, however, the two peer applications were to request different
connection latching parameters, then the connection latch must fail
on one end (if the key exchange protocol does not support
simultaneous SA creation) or on both ends.
Williams Expires July 13, 2008 [Page 17]
Internet-Draft IPsec Connection Latching January 2008
5. Security Considerations
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 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 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 all
concurrent connections with the same end-point addresses also have
the same end-point IPsec IDs.
Applications which are sensitive to connection closure, such as the
Border Gateway Protocol (BGP), SHOULD set the conflict resolution
option for connection latching (e.g., in the case of BGP that option
should be set to "wait for the conflict to be resolved").
IPsec channels are a pre-requisite for channel binding [RFC5056] 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.
Without IPsec APIs connection latching provides marginal security
benefits over traditional IPsec. Such APIs are not described herein;
see [I-D.ietf-btns-abstract-api].
Williams Expires July 13, 2008 [Page 18]
Internet-Draft IPsec Connection Latching January 2008
6. IANA Considerations
There are not IANA considerations for this document.
Williams Expires July 13, 2008 [Page 19]
Internet-Draft IPsec Connection Latching January 2008
7. Acknowledgements
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...
Williams Expires July 13, 2008 [Page 20]
Internet-Draft IPsec Connection Latching January 2008
8. References
8.1. Normative References
[I-D.ietf-btns-core]
Williams, N. and M. Richardson, "Better-Than-Nothing-
Security: An Unauthenticated Mode of IPsec",
draft-ietf-btns-core-06 (work in progress), January 2008.
[I-D.ietf-btns-prob-and-applic]
Touch, J., Black, D., and Y. Wang, "Problem and
Applicability Statement for Better Than Nothing Security
(BTNS)", draft-ietf-btns-prob-and-applic-06 (work in
progress), October 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
8.2. Informative References
[I-D.bellovin-useipsec]
Bellovin, S., "Guidelines for Mandating the Use of IPsec
Version 2", draft-bellovin-useipsec-07 (work in progress),
October 2007.
[I-D.dondeti-useipsec-430x]
Dondeti, L. and V. Narayanan, "Guidelines for using IPsec
and IKEv2", draft-dondeti-useipsec-430x-00 (work in
progress), October 2006.
[I-D.ietf-btns-abstract-api]
Richardson, M., "An interface between applications and
keying systems", draft-ietf-btns-abstract-api-00 (work in
progress), June 2007.
[IP_SEC_OPT.man]
Sun Microsystems, Inc., "Solaris ipsec(7P) manpage",
October 2006.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
Williams Expires July 13, 2008 [Page 21]
Internet-Draft IPsec Connection Latching January 2008
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
Channels", RFC 5056, November 2007.
Williams Expires July 13, 2008 [Page 22]
Internet-Draft IPsec Connection Latching January 2008
Author's Address
Nicolas Williams
Sun Microsystems
5300 Riata Trace Ct
Austin, TX 78727
US
Email: Nicolas.Williams@sun.com
Williams Expires July 13, 2008 [Page 23]
Internet-Draft IPsec Connection Latching January 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Williams Expires July 13, 2008 [Page 24]
| PAFTECH AB 2003-2026 | 2026-04-18 22:46:58 |