[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 RFC 5660

NETWORK WORKING GROUP                                        N. Williams
Internet-Draft                                                       Sun
Expires: August 27, 2008                               February 24, 2008


                  IPsec Channels: Connection Latching
               draft-ietf-btns-connection-latching-06.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 August 27, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).















Williams                 Expires August 27, 2008                [Page 1]

Internet-Draft          IPsec Connection Latching          February 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 August 27, 2008                [Page 2]

Internet-Draft          IPsec Connection Latching          February 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 August 27, 2008                [Page 3]

Internet-Draft          IPsec Connection Latching          February 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 August 27, 2008                [Page 4]

Internet-Draft          IPsec Connection Latching          February 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 August 27, 2008                [Page 5]

Internet-Draft          IPsec Connection Latching          February 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 August 27, 2008                [Page 6]

Internet-Draft          IPsec Connection Latching          February 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 August 27, 2008                [Page 7]

Internet-Draft          IPsec Connection Latching          February 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 August 27, 2008                [Page 8]

Internet-Draft          IPsec Connection Latching          February 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 August 27, 2008                [Page 9]

Internet-Draft          IPsec Connection Latching          February 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 August 27, 2008               [Page 10]

Internet-Draft          IPsec Connection Latching          February 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 August 27, 2008               [Page 11]

Internet-Draft          IPsec Connection Latching          February 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 August 27, 2008               [Page 12]

Internet-Draft          IPsec Connection Latching          February 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 August 27, 2008               [Page 13]

Internet-Draft          IPsec Connection Latching          February 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.

   Extending the ULP/IPsec interface to the application should enable
   applications to use connection-less datagram transports and implement
   connection latching at the application layer.

2.4.  Non-native mode IPsec

   Non-native IPsec implementations, primarily BITS and SG, can
   implement connection latching too.  One major distinction between



Williams                 Expires August 27, 2008               [Page 14]

Internet-Draft          IPsec Connection Latching          February 2008


   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/
   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 August 27, 2008               [Page 15]

Internet-Draft          IPsec Connection Latching          February 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 August 27, 2008               [Page 16]

Internet-Draft          IPsec Connection Latching          February 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 August 27, 2008               [Page 17]

Internet-Draft          IPsec Connection Latching          February 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 August 27, 2008               [Page 18]

Internet-Draft          IPsec Connection Latching          February 2008


6.  IANA Considerations

   There are not IANA considerations for this document.
















































Williams                 Expires August 27, 2008               [Page 19]

Internet-Draft          IPsec Connection Latching          February 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 August 27, 2008               [Page 20]

Internet-Draft          IPsec Connection Latching          February 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 August 27, 2008               [Page 21]

Internet-Draft          IPsec Connection Latching          February 2008


   [RFC5056]  Williams, N., "On the Use of Channel Bindings to Secure
              Channels", RFC 5056, November 2007.

















































Williams                 Expires August 27, 2008               [Page 22]

Internet-Draft          IPsec Connection Latching          February 2008


Author's Address

   Nicolas Williams
   Sun Microsystems
   5300 Riata Trace Ct
   Austin, TX  78727
   US

   Email: Nicolas.Williams@sun.com










































Williams                 Expires August 27, 2008               [Page 23]

Internet-Draft          IPsec Connection Latching          February 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 August 27, 2008               [Page 24]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/