summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5660.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5660.txt')
-rw-r--r--doc/rfc/rfc5660.txt1739
1 files changed, 1739 insertions, 0 deletions
diff --git a/doc/rfc/rfc5660.txt b/doc/rfc/rfc5660.txt
new file mode 100644
index 0000000..52f1cc7
--- /dev/null
+++ b/doc/rfc/rfc5660.txt
@@ -0,0 +1,1739 @@
+
+
+
+
+
+
+Network Working Group N. Williams
+Request for Comments: 5660 Sun
+Category: Standards Track October 2009
+
+
+ IPsec Channels: Connection Latching
+
+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.
+ Connection latching is layered on top of IPsec and does not modify
+ the underlying IPsec architecture.
+
+ 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.
+
+ Finally, the availability of IPsec channels will make it possible to
+ use channel binding to IPsec channels.
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (c) 2009 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+
+
+
+
+
+Williams Standards Track [Page 1]
+
+RFC 5660 IPsec Connection Latching October 2009
+
+
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the BSD License.
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 1.1. Conventions Used in This Document ..........................4
+ 2. Connection Latching .............................................4
+ 2.1. Latching of Quality-of-Protection Parameters ...............8
+ 2.2. Connection Latch State Machine .............................9
+ 2.3. Normative Model: ULP Interfaces to the Key Manager ........12
+ 2.3.1. Race Conditions and Corner Cases ...................17
+ 2.3.2. Example ............................................18
+ 2.4. Informative Model: Local Packet Tagging ...................19
+ 2.5. Non-Native Mode IPsec .....................................21
+ 2.6. Implementation Note Regarding Peer IDs ....................22
+ 3. Optional Features ..............................................22
+ 3.1. Optional Protection .......................................22
+ 4. Simultaneous Latch Establishment ...............................23
+ 5. Connection Latching to IPsec for Various ULPs ..................23
+ 5.1. Connection Latching to IPsec for TCP ......................24
+ 5.2. Connection Latching to IPsec for UDP with
+ Simulated Connections .....................................24
+ 5.3. Connection Latching to IPsec for UDP with
+ Datagram-Tagging APIs .....................................25
+ 5.4. Connection Latching to IPsec for SCTP .....................25
+ 5.5. Handling of BROKEN State for TCP and SCTP .................26
+ 6. Security Considerations ........................................27
+ 6.1. Impact on IPsec ...........................................27
+ 6.2. Impact on IPsec of Optional Features ......................28
+ 6.3. Security Considerations for Applications ..................28
+ 6.4. Channel Binding and IPsec APIs ............................29
+ 6.5. Denial-of-Service Attacks .................................29
+ 7. Acknowledgements ...............................................30
+ 8. References .....................................................30
+ 8.1. Normative References ......................................30
+ 8.2. Informative References ....................................30
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams Standards Track [Page 2]
+
+RFC 5660 IPsec Connection Latching October 2009
+
+
+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 Better Than Nothing Security (BTNS)
+ [RFC5387] is used.
+
+ Applications that wish to use IPsec may have to ensure that local
+ policy on the various end-points is configured appropriately
+ [RFC5406] [USING-IPSEC]. There are no standard Application
+ Programming Interfaces (APIs) to do this (though there are non-
+ standard APIs, such as [IP_SEC_OPT.man]) -- 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
+ 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, etc.).
+
+ 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 [RFC0768],
+ TCP [RFC0793], and Stream Control Transmission Protocol (SCTP)
+ [RFC4960] 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.
+
+ 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
+
+
+
+Williams Standards Track [Page 3]
+
+RFC 5660 IPsec Connection Latching October 2009
+
+
+ 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.
+
+ We assume the reader is familiar with the IPsec architecture
+ [RFC4301] and Internet Key Exchange Protocol version 2 (IKEv2)
+ [RFC4306].
+
+ 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).
+
+ 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.
+
+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].
+
+ Abstract function names are all capitalized and denoted by a pair of
+ parentheses. In their descriptions, the arguments appear within the
+ parentheses, with optional arguments 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.
+
+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:
+
+
+
+
+Williams Standards Track [Page 4]
+
+RFC 5660 IPsec Connection Latching October 2009
+
+
+ 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).
+
+ 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.
+
+ 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 versus tunnel mode;
+
+ o Quality of protection (QoP): cryptographic algorithm suites, key
+ lengths, and replay protection (see Section 2.1);
+
+ o Local identity: the local ID asserted to the peer, as per the
+ IPsec processing model [RFC4301] and BTNS [RFC5386];
+
+ o Peer identity: the peer's asserted and authorized IDs, as per the
+ IPsec processing model [RFC4301] and BTNS [RFC5386].
+
+ 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
+ they 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.
+
+
+
+
+
+
+Williams Standards Track [Page 5]
+
+RFC 5660 IPsec Connection Latching October 2009
+
+
+ When a situation arises in which the SPD is modified, or an SA is
+ added to the SAD, such that the new policy and/or SA are not
+ congruent to an established channel (see previous paragraph), then we
+ consider this a conflict. Conflict resolution is addressed below.
+
+ 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.
+ That is, 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. That is, such packets
+ must either be dropped or 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 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 and available information
+ about a peer's ID, including authentication information. This
+ includes the peer certificate, when one is used, and the trust
+ anchor to which it was validated (but not necessarily the whole
+ certificate validation chain).
+
+ o 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.
+
+ o 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.
+
+
+
+
+
+
+Williams Standards Track [Page 6]
+
+RFC 5660 IPsec Connection Latching October 2009
+
+
+ o 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.
+
+ (Typical system policy may not allow applications any choices
+ here. Policy extensions allowing for optional protection are
+ described in Section 3.1.)
+
+ o Implementations SHOULD create IPsec channels automatically by
+ default when the application does not explicitly request an IPsec
+ channel. Implementations MAY provide a way to disable automatic
+ creation of connection latches.
+
+ o The parameters latched in an IPsec channel MUST remain unchanged
+ once the channel is established.
+
+ o 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.
+
+ 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., 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.
+
+ o Dynamic IPsec policy (see Section 3.1) related to connection
+ latches, if any, MUST be torn down when latched connections are
+ torn down, and MUST NOT survive reboots.
+
+ o When IKE dead-peer detection (DPD) concludes that the remote peer
+ is dead or has rebooted, then the system SHOULD consider all
+ connection latches with that peer to be irremediably broken.
+
+ 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,
+
+
+
+Williams Standards Track [Page 7]
+
+RFC 5660 IPsec Connection Latching October 2009
+
+
+ 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.
+
+ The two models given below are not, however, entirely equivalent.
+ One model cannot be implemented with Network Interface cards (NICs)
+ that offload ESP/AH but that 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.
+
+ 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
+ [RFC5056].
+
+2.1. Latching of Quality-of-Protection Parameters
+
+ In IPsec, the assumption of IKE initiator/responder roles is non-
+ deterministic. That is, sometimes an IKE SA and child SAs will be
+ initiated by the "client" (e.g., the caller of the connect() BSD
+ sockets function) and sometimes by the "server" (e.g., the caller of
+ the accept() BSD Sockets function). This means that the negotiation
+ of quality of protection is also non-deterministic unless one of the
+ peers offers a single cryptographic suite in the IKE negotiation.
+
+ When creating narrow child SAs with traffic selectors matching the
+ connection latch's 5-tuple, it is possible to constrain the IKE
+ Quality-of-Protection negotiation to a single cryptographic suite.
+ Therefore, implementations SHOULD provide an API for requesting the
+ use of such child SAs. Implementors SHOULD consider an application
+ request for a specific QoP to imply a request for narrow child SAs.
+
+
+
+
+
+
+
+Williams Standards Track [Page 8]
+
+RFC 5660 IPsec Connection Latching October 2009
+
+
+ When using SAs with traffic selectors encompassing more than just a
+ single flow, then the system may only be able to latch a set of
+ cryptographic suites, rather than a single cryptographic suite. In
+ such a case, an implementation MUST report the QoP being used as
+ indeterminate.
+
+2.2. Connection Latch State Machine
+
+ Connection latches can exist in any of the following five states:
+
+ o LISTENER
+
+ o ESTABLISHED
+
+ o BROKEN (there exist SAs that conflict with the given connection
+ latch, conflicting SPD changes have been made, or DPD has been
+ triggered and the peer is considered dead or restarted)
+
+ 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 (and other ULPs) 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 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 represent 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.
+
+ 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.
+
+ 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 also take place when
+
+
+
+Williams Standards Track [Page 9]
+
+RFC 5660 IPsec Connection Latching October 2009
+
+
+ SPD changes occur that would cause the latched connection's packets
+ to be sent or received with different protection parameters than
+ those that were latched. Transitions to the BROKEN state are also
+ allowed when IKEv2 DPD concludes that the remote peer is dead or has
+ rebooted. Transitions to the BROKEN state always cause the
+ associated owner to be informed. Connection latches in the BROKEN
+ state transition back to ESTABLISHED when all SA and/or SPD conflicts
+ are cleared.
+
+ 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
+ Section 2.)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams Standards Track [Page 10]
+
+RFC 5660 IPsec Connection Latching October 2009
+
+
+ The state diagram below makes use of conventions described in
+ Section 1.1 and state transition events described in Section 2.3.
+
+ <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 or DPD>
+ | : cleared> | :
+ | : | | :
+ | : | v v
+ | : /----------------\
+ | :.....>| BROKEN |.-.-.-.-.-> <ALERT()>
+ | \----------------/
+ | |
+ <RELEASE_LATCH()> <RELEASE_LATCH()>
+ | |
+ | v
+ | /------\
+ +------------------->|CLOSED|
+ \------/
+
+ Figure 1: Connection Latching State Machine
+
+ The details of the transitions depend on the model of connection
+ latching followed by any given implementation. See the following
+ sections.
+
+
+
+
+
+
+
+
+
+
+Williams Standards Track [Page 11]
+
+RFC 5660 IPsec Connection Latching October 2009
+
+
+2.3. Normative Model: ULP Interfaces to the Key Manager
+
+ This section describes the NORMATIVE model of connection latching.
+
+ 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.
+
+ 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.
+
+ The traditional IPsec processing model allows the concurrent
+ existence of SAs with different peers but overlapping traffic
+ selectors. Such behavior, in this model, directly violates the
+ requirements for connection latching (see Section 2). We address
+ this problem by requiring that connection latches be broken (and
+ holders informed) when such conflicts arise.
+
+ The following INFORMATIVE figure illustrates this model and API in
+ terms that are familiar to many implementors, though not applicable
+ to all:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams Standards Track [Page 12]
+
+RFC 5660 IPsec Connection Latching October 2009
+
+
+ +--------------------------------------------+
+ | +--------------+ |
+ | |Administrator | |
+ | |apps | |
+ | +--------------+ |
+ | ^ ^ |
+ | | | | user mode
+ | v v |
+ | +--------------+ +-------++--------+ |
+ | |App | |IKEv2 || | |
+ | | | | +---+ || +----+ | |
+ | | | | |PAD| || |SPD | | |
+ | | | | +---+ || +--^-+ | |
+ | +--------------+ +-+-----++----+---+ |
+ | ^ | | |
+ +---|---------------------|-----------|------+ user/kernel mode
+ | |syscalls | PF_KEY | | interface
+ | | | [RFC2367] | |
+ +---|---------------------|-----------|------+
+ | v | | |
+ |+-------+ +------------|-----------|-----+|
+ ||ULP | | IPsec key|manager | ||
+ |+-------+ | | +--------v----+||
+ | ^ ^ | | | Logical SPD |||
+ | | | | | +-----------^-+||
+ | | | | +-------+ | || kernel mode
+ | | | | | | ||
+ | | | | +----------+ +--v--+ | ||
+ | | +-------->| Latch DB |<-->| SAD | | ||
+ | | | +----------+ +--^--+ | ||
+ | | +--------------------|------|--+|
+ +-|-------------------------------v------v---+
+ | | IPsec Layer (ESP/AH) |
+ | | |
+ +-v------------------------------------------+
+ | IP Layer |
+ +--------------------------------------------+
+
+ Figure 2: Informative Implementation Architecture Diagram
+
+ The ULP interfaces to the IPsec LD are as follows:
+
+ o CREATE_LISTENER_LATCH(3-tuple, [type and quality-of-protection
+ parameters]) -> latch handle | error
+
+
+
+
+
+
+
+Williams Standards Track [Page 13]
+
+RFC 5660 IPsec Connection Latching October 2009
+
+
+ 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 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.
+
+ o CREATE_CONNECTION_LATCH(5-tuple, [type and quality-of-protection
+ parameters], [peer ID], [local ID]) -> latch handle | error
+
+ If a) the requested latch does not exist (or exists, but is in
+ the CLOSED state), b) all the latch parameters are provided, or
+ if suitable SAs exist in the SAD from which to derive them, and
+ c) if there are no conflicts with the SPD and SAD, then this
+ creates a connection latch in the ESTABLISHED state. If the
+ latch parameters are not provided and no suitable SAs exist in
+ the SAD from which to derive those parameters, then the key
+ manager MUST initiate child SAs, and if need be, IKE_SA, from
+ which to derive those parameters.
+
+ The key manager MAY delay the child SA setup and return
+ immediately after the policy check, knowing that the ULP that
+ requested the latch will subsequently output a packet that will
+ trigger the SA establishment. Such an implementation may
+ require an additional, fleeting state in the connection latch
+ state machine, a "LARVAL" state, so to speak, that is not
+ described herein.
+
+ If the connection latch ultimately cannot be established,
+ either because of conflicts or because no SAs can be
+ established with the peer at the destination address, then an
+ error is returned to the ULP. (If the key manager delayed SA
+ establishment, and SA establishment ultimately fails, then the
+ key manager has to inform the ULP, possibly asynchronously.
+ This is one of several details that implementors who use a
+ LARVAL state must take care of.)
+
+
+
+
+
+
+
+Williams Standards Track [Page 14]
+
+RFC 5660 IPsec Connection Latching October 2009
+
+
+ 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 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
+ [RFC4306]).
+
+ o FIND_LATCH(5-tuple) -> latch handle | error
+
+ Given a 5-tuple returns a latch handle (or an error).
+
+ o INQUIRE_LATCH(latch object handle) -> {latch state, latched
+ parameters} | error
+
+ Returns all available information about the given latch,
+ including its current state (or an error).
+
+ The IPsec LD interface to the ULP is as follows:
+
+ o ALERT(latch object handle, 5-tuple, new state, [reason])
+
+ Alerts a ULP as to an asynchronous state change for the given
+ connection latch and, optionally, provides a reason for the
+ change.
+
+ 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).
+
+ 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
+
+
+
+Williams Standards Track [Page 15]
+
+RFC 5660 IPsec Connection Latching October 2009
+
+
+ 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.
+
+ o 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 [RFC4306]);
+ otherwise, the latch MUST be transitioned to the BROKEN state.
+
+ 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.
+
+ 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 behavior is
+ to transition into the BROKEN state all connection latches that
+ conflict with the given SPD change. An OPTIONAL behavior 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.
+
+ ULPs create latched connections by interfacing with IPsec 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 MUST 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.
+
+ 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 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.
+
+
+
+
+Williams Standards Track [Page 16]
+
+RFC 5660 IPsec Connection Latching October 2009
+
+
+ o 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.
+
+ o When tearing down a listener, the ULP MUST 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 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.
+
+ o 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 that 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.
+
+ 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), even
+ where the hardware does not support tagging inbound packets with the
+ indexes of SAD entries corresponding to the SAs that protected them.
+
+2.3.1. Race Conditions and Corner Cases
+
+ 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.
+
+
+
+
+
+
+Williams Standards Track [Page 17]
+
+RFC 5660 IPsec Connection Latching October 2009
+
+
+ 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 a 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.
+
+2.3.2. Example
+
+ Consider several systems with a very simple PAD containing a single
+ entry like so:
+
+ Child SA
+ Rule Remote ID IDs allowed SPD Search by
+ ---- --------- ----------- -------------
+ 1 <any valid to trust anchor X> 192.0.2/24 by-IP
+
+ Figure 3: Example PAD
+
+ And a simple SPD like so:
+
+ 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
+
+ Figure 4: [SG-A] SPD Table
+
+ 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.
+
+ 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
+ addressed.
+
+
+
+
+Williams Standards Track [Page 18]
+
+RFC 5660 IPsec Connection Latching October 2009
+
+
+ B is listening on port 4000. A initiates a connection from port
+ 32800 to B on port 4000.
+
+ We'll assume no IPsec APIs, but that TCP creates latches where
+ possible.
+
+ 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.
+
+ 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.
+
+ 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.
+
+ If C attempts to mount a man-in-the-middle attack on A (i.e.,
+ pretends 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.
+
+ If A does not support connection latching, then C will be able to
+ impersonate B to A at any time. 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, then C will be able to impersonate A to
+ B.
+
+2.4. 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.
+
+
+
+
+Williams Standards Track [Page 19]
+
+RFC 5660 IPsec Connection Latching October 2009
+
+
+ This section is INFORMATIVE.
+
+ 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. Tagging 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.
+
+ The interface between the ULPs and IPsec interface is as follows:
+
+ 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 as 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 that
+ are not so protected are dropped (this corresponds to
+ transitioning the connection latch to the BROKEN state until the
+
+
+
+
+Williams Standards Track [Page 20]
+
+RFC 5660 IPsec Connection Latching October 2009
+
+
+ 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.
+
+ 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 Sections 2.3 and 3.1
+ an incidental side effect of this approach.
+
+ This model of connection latching may not be workable with ESP/AH
+ offload hardware that does not support the packet tagging scheme
+ described above.
+
+ Note that this model has no explicit BROKEN connection latch state.
+
+ 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.
+
+2.5. Non-Native Mode IPsec
+
+ This section is INFORMATIVE.
+
+ Non-native IPsec implementations, primarily BITS and SG, can
+ implement connection latching, too. One major distinction between
+ native IPsec and BITS, bump-in-the-wire (BITW), or 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.3: 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.
+
+ 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 middleboxes, this scheme suffers from the
+ inability of the middlebox to interact with the applications. For
+ example, connection death may be difficult to ascertain. Nor can
+
+
+
+Williams Standards Track [Page 21]
+
+RFC 5660 IPsec Connection Latching October 2009
+
+
+ channel binding applications work with channels maintained by proxy
+ without being able to communicate (securely) about it with the
+ middlebox.
+
+2.6. Implementation Note Regarding Peer IDs
+
+ One of the recommendations for connection latching implementors is to
+ make peer CERT payloads (certificates) available to the applications.
+
+ Additionally, raw public keys are likely to be used in the
+ construction of channel bindings for IPsec channels (see [IPSEC-CB]),
+ and they must be available, in any case, in order to implement leap-
+ of-faith at the application layer (see [RFC5386] and [RFC5387]).
+
+ 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. Implementations without IPsec APIs
+ MAY hash peer IDs and use the hash to refer to them, preferably using
+ a strong hash algorithm.
+
+3. Optional Features
+
+ At its bare minimum, connection latching is a passive layer atop
+ IPsec that warns ULPs of SPD and SAD changes that are incompatible
+ with the SPD/SAD state that was applicable to a connection when it
+ was established.
+
+ 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
+ Section 2.3 and the optional protection/bypass feature described in
+ the following sub-section.
+
+3.1. 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".
+
+
+
+
+Williams Standards Track [Page 22]
+
+RFC 5660 IPsec Connection Latching October 2009
+
+
+ Both native IPsec models of connection latching can be extended to
+ support optional protection. With the model described in
+ Section 2.4, 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. In the case of
+ the model described in Section 2.3, enforcement of minimum protection
+ requirements would be done by the IPsec key manager via the
+ connection latch state machine.
+
+ 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 Section 2.3). Such updates of
+ the SPD MUST NOT survive system crashes or reboots.
+
+4. Simultaneous Latch Establishment
+
+ Some connection-oriented ULPs, specifically TCP, support simultaneous
+ 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 or on both ends.
+
+5. Connection Latching to IPsec for Various ULPs
+
+ 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.
+
+
+
+Williams Standards Track [Page 23]
+
+RFC 5660 IPsec Connection Latching October 2009
+
+
+5.1. Connection Latching to IPsec for TCP
+
+ IPsec connection latch creation/release for TCP [RFC0793] connections
+ is triggered when:
+
+ o 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.
+
+ o 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.
+
+ o 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.
+
+ o 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.
+
+ See Section 5.5 for how to handle latch transitions to the BROKEN
+ state.
+
+5.2. Connection Latching to IPsec for UDP with Simulated Connections
+
+ UDP [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 Section 2.4 can
+ support per-datagram latching by extending its packet tagging
+ interfaces to the application.
+
+ IPsec connection latch creation/release for UDP connections is
+ triggered when:
+
+ o an application creates a UDP "connection". This should cause the
+ creation of an ESTABLISHED or BROKEN connection latch.
+
+ o an application destroys a UDP "connection". This should cause the
+ creation of an ESTABLISHED or BROKEN connection latch.
+
+ 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
+
+
+
+
+
+Williams Standards Track [Page 24]
+
+RFC 5660 IPsec Connection Latching October 2009
+
+
+ there is a way to do so, or else it should wait, allowing the
+ application-layer keepalive/timeout strategy, if any, to time out the
+ connection.
+
+ 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.
+
+5.3. Connection Latching to IPsec for UDP with Datagram-Tagging APIs
+
+ Implementations based on either model of connection latching can
+ provide applications with datagram-tagging APIs based on those
+ described in Section 2.4. 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.
+
+5.4. Connection Latching to IPsec for SCTP
+
+ SCTP [RFC4960], a connection-oriented protocol is 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.
+
+ We can represent the multiplicity of SCTP association end-point
+ addresses as a multiplicity of 5-tuples, each of which with its own
+ 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.
+
+ 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 connection latch per
+ SCTP association (with N + M addresses). Implementors may choose
+ either approach.
+
+
+
+
+
+
+
+
+
+
+Williams Standards Track [Page 25]
+
+RFC 5660 IPsec Connection Latching October 2009
+
+
+ IPsec connection latch creation/release for SCTP connections is
+ triggered when:
+
+ o 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.
+
+ o 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.
+
+ o 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.
+
+ o an SCTP Address Configuration Change Chunk (ASCONF) [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.
+
+ o 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.
+
+ o an SCTP ASCONF chunk [RFC5061] deleting an end-point IP address is
+ sent or received. This should cause one or more associated
+ connection latches to be CLOSED.
+
+ See Section 5.5 for how to handle latch transitions to the BROKEN
+ state.
+
+5.5. Handling of BROKEN State for TCP and SCTP
+
+ There are several ways to handle connection latch transitions to the
+ BROKEN state in the case of connection-oriented ULPs like TCP or
+ SCTP:
+
+ a. Wait for a possible future transition back to the ESTABLISHED
+ state, until which time the ULP will not move data between the
+ two end-points of the connection. ULP and application timeout
+ mechanisms will, of course, be triggered in the event of too
+ lengthy a stay in the BROKEN state. SCTP can detect these
+ timeouts and initiate failover, in the case of multi-homed
+ associations.
+
+
+
+
+
+Williams Standards Track [Page 26]
+
+RFC 5660 IPsec Connection Latching October 2009
+
+
+ b. Act as though the connection has been reset (RST message
+ received, in TCP, or ABORT message received, in SCTP).
+
+ c. Act as though an ICMP destination unreachable message had been
+ received (in SCTP such messages can trigger path failover in the
+ case of multi-homed associations).
+
+ Implementations SHOULD provide APIs that allow applications either 1)
+ to be informed (asynchronously or otherwise) of latch breaks so that
+ they may choose a disposition, and/or 2) to select a specific
+ disposition a priori (before a latch break happens). The options for
+ disposition are wait, close, or proceed with path failover.
+
+ Implementations MUST provide a default disposition in the event of a
+ connection latch break. Though (a) is clearly the purist default, we
+ RECOMMEND (b) for TCP and SCTP associations where only a single path
+ remains (one 5-tuple), and (c) for multi-homed SCTP associations.
+ The rationale for this recommendation is as follows: a conflicting SA
+ most likely indicates that the original peer is gone and has been
+ replaced by another, and it's not likely that the original peer will
+ return; thus, failing faster seems reasonable.
+
+ Note that our recommended default behavior does not create off-path
+ reset denial-of-service (DoS) attacks. To break a connection latch,
+ an attacker would first have to successfully establish an SA, with
+ one of the connection's end-points, that conflicts with the
+ connection latch and that requires multiple messages to be exchanged
+ between that end-point and the attacker. Unless the attacker's
+ chosen victim end-point allows the attacker to claim IP address
+ ranges for its SAs, then the attacker would have to actually take
+ over the other end-point's addresses, which rules out off-path
+ attacks.
+
+6. Security Considerations
+
+6.1. Impact on IPsec
+
+ 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 that 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
+ that are affected by a conflict. In this minimal form, connection
+ latching is a passive, local feature layered atop IPsec.
+
+
+
+
+Williams Standards Track [Page 27]
+
+RFC 5660 IPsec Connection Latching October 2009
+
+
+ We achieve this by adding a new type of IPsec database, the Latch
+ Database (LD), containing objects that 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 that 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 latching are given, and we hope that
+ most native IPsec implementors will find at least one model to be
+ simple enough to implement in their stack.
+
+ This notion of conflicting SAs and how to deal with the situation
+ does not modify the basic IPsec architecture -- the feature of IPsec
+ that 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.
+
+ There are, however, interesting corner cases in the normative model
+ of connection latching that implementors must be aware of. The notes
+ in Section 2.3.1 are particularly relevant.
+
+6.2. Impact on IPsec of Optional Features
+
+ Section 3 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 they 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.
+
+6.3. Security Considerations for Applications
+
+ Connection latching is not negotiated. It is therefore possible for
+ one end of a connection to be using connection latching while the
+ other does not; in which case, it's possible for policy changes local
+ to the non-latched end to cause packets to be sent unprotected. The
+ end doing connection latching will reject unprotected packets, but if
+ they bear sensitive data, then the damage may already be done.
+ Therefore, applications SHOULD check that both ends of a connection
+ are latched (such a check is implicit for applications that use
+ channel binding to IPsec).
+
+
+
+
+Williams Standards Track [Page 28]
+
+RFC 5660 IPsec Connection Latching October 2009
+
+
+ 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.
+
+ 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).
+
+6.4. Channel Binding and IPsec APIs
+
+ IPsec channels are a prerequisite for channel binding [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 [IPSEC-CB].
+
+ Without IPsec APIs, connection latching provides marginal security
+ benefits over traditional IPsec. Such APIs are not described herein;
+ see [ABSTRACT-API].
+
+6.5. Denial-of-Service Attacks
+
+ Connection latch state transitions to the BROKEN state can be
+ triggered by on-path attackers and any off-path attackers that can
+ attack routers or cause an end-point to accept an ICMP Redirect
+ message. Connection latching protects applications against on- and
+ off-path attackers in general, but not against on-path denial of
+ service specifically.
+
+ Attackers can break latches if they can trigger DPD on one or both
+ end-points and if they cause packets to not move between two end-
+ points. Such attacks generally require that the attacker be on-path;
+ therefore, we consider it acceptable to break latches when DPD
+ concludes that a peer is dead or rebooted.
+
+ Attackers can also break latches if IPsec policy on a node allows the
+ attacker to use the IP address of a peer of that node. Such
+
+
+
+
+
+Williams Standards Track [Page 29]
+
+RFC 5660 IPsec Connection Latching October 2009
+
+
+ configurations are expected to be used in conjunction with BTNS in
+ general. Such attacks generally require that the attacker be on-
+ path.
+
+7. Acknowledgements
+
+ 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.
+
+8. References
+
+8.1. Normative References
+
+ [RFC0768] Postel, J., "User Datagram Protocol", STD 6,
+ RFC 768, August 1980.
+
+ [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
+ RFC 793, September 1981.
+
+ [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.
+
+ [RFC4960] Stewart, R., "Stream Control Transmission
+ Protocol", RFC 4960, September 2007.
+
+ [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and
+ M. Kozuka, "Stream Control Transmission Protocol
+ (SCTP) Dynamic Address Reconfiguration", RFC 5061,
+ September 2007.
+
+ [RFC5386] Williams, N. and M. Richardson, "Better-Than-
+ Nothing Security: An Unauthenticated Mode of
+ IPsec", RFC 5386, November 2008.
+
+8.2. Informative References
+
+ [ABSTRACT-API] Richardson, M., "An abstract interface between
+ applications and IPsec", Work in Progress,
+ November 2008.
+
+
+
+Williams Standards Track [Page 30]
+
+RFC 5660 IPsec Connection Latching October 2009
+
+
+ [IPSEC-CB] Williams, N., "End-Point Channel Bindings for IPsec
+ Using IKEv2 and Public Keys", Work in Progress,
+ April 2008.
+
+ [IP_SEC_OPT.man] Sun Microsystems, Inc., "ipsec(7P) man page,
+ Solaris 10 Reference Manual Collection".
+
+ [RFC1034] Mockapetris, P., "Domain names - concepts and
+ facilities", STD 13, RFC 1034, November 1987.
+
+ [RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key
+ Management API, Version 2", RFC 2367, July 1998.
+
+ [RFC5056] Williams, N., "On the Use of Channel Bindings to
+ Secure Channels", RFC 5056, November 2007.
+
+ [RFC5387] Touch, J., Black, D., and Y. Wang, "Problem and
+ Applicability Statement for Better-Than-Nothing
+ Security (BTNS)", RFC 5387, November 2008.
+
+ [RFC5406] Bellovin, S., "Guidelines for Specifying the Use of
+ IPsec Version 2", BCP 146, RFC 5406, February 2009.
+
+ [USING-IPSEC] Dondeti, L. and V. Narayanan, "Guidelines for using
+ IPsec and IKEv2", Work in Progress, October 2006.
+
+Author's Address
+
+ Nicolas Williams
+ Sun Microsystems
+ 5300 Riata Trace Ct
+ Austin, TX 78727
+ US
+
+ EMail: Nicolas.Williams@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams Standards Track [Page 31]
+