NETWORK WORKING GROUP                                        N. Williams
Internet-Draft                                                       Sun
Expires: June 11, 2008                                  December 9, 2007


                  IPsec Channels: Connection Latching
               draft-ietf-btns-connection-latching-04.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 June 11, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).















Williams                  Expires June 11, 2008                 [Page 1]


Internet-Draft          IPsec Connection Latching          December 2007


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  . . . . . . . . . . . . .  3
   2.    Connection Latching  . . . . . . . . . . . . . . . . . . . .  4
   2.1.  Normative Model: ULP interfaces to the key manager . . . . .  7
   2.2.  Informative model: local packet tagging  . . . . . . . . . . 10
   2.3.  Non-native mode IPsec  . . . . . . . . . . . . . . . . . . . 12
   2.4.  Conflict Resolution  . . . . . . . . . . . . . . . . . . . . 12
   3.    Optional protection  . . . . . . . . . . . . . . . . . . . . 14
   4.    Security Considerations  . . . . . . . . . . . . . . . . . . 15
   5.    IANA Considerations  . . . . . . . . . . . . . . . . . . . . 16
   6.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
   7.    References . . . . . . . . . . . . . . . . . . . . . . . . . 18
   7.1.  Normative References . . . . . . . . . . . . . . . . . . . . 18
   7.2.  Informative References . . . . . . . . . . . . . . . . . . . 18
         Author's Address . . . . . . . . . . . . . . . . . . . . . . 19
         Intellectual Property and Copyright Statements . . . . . . . 20
















Williams                  Expires June 11, 2008                 [Page 2]


Internet-Draft          IPsec Connection Latching          December 2007


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.

   A method is desired for creating "IPsec channels," that is, packet
   flows predictably protected for their duration, even in the face of
   IPsec reconfiguration or weak association of peer IDs and addresses.
   The methods outlined below achieve this by interfacing ULPs and
   applications to IPsec and using these interfaces to bind ("latch")
   connections to peer IDs and SA parameters.

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 June 11, 2008                 [Page 3]


Internet-Draft          IPsec Connection Latching          December 2007


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].

   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.

   IPsec channels can have the following states:

   o  LISTENER




Williams                  Expires June 11, 2008                 [Page 4]


Internet-Draft          IPsec Connection Latching          December 2007


   o  LARVAL (in the process of being established)

   o  ESTABLISHED

   o  BROKEN

   o  CLOSED

   and always have an associated owner, or holder, such as a ULP
   transmission control block (TCB).

   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 (they MUST be dropped) until the
      channel is established.

   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
      MUST be dropped).

   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.

   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



Williams                  Expires June 11, 2008                 [Page 5]


Internet-Draft          IPsec Connection Latching          December 2007


      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 MAY be communicated to the ULP and application
      (e.g., as though the connection had been reset)

   o  Implementations that have a restartable key management process (or
      "daemon") MUST arrange for existing latched connections to either
      be reset and disconnected, or for them to survive the restart of
      key exchange processes.  (This is implied by the above
      requirements.)  IPsec state 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.  Both models imply extensions to any PF_KEY-like
   protocols [RFC2367] that may be used internally by the
   implementation.

   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
   [I-D.williams-on-channel-binding].

2.1.  Normative Model: ULP interfaces to the key manager



Williams                  Expires June 11, 2008                 [Page 6]


Internet-Draft          IPsec Connection Latching          December 2007


   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: 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
   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 LARVAL or ESTABLISHED
         states with the same 5-tuple, and if there exist no child SAs



Williams                  Expires June 11, 2008                 [Page 7]


Internet-Draft          IPsec Connection Latching          December 2007


         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
         LARVAL 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.

         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 LARVAL or 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 LARVAL or 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,



Williams                  Expires June 11, 2008                 [Page 8]


Internet-Draft          IPsec Connection Latching          December 2007


      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 (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
   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.




Williams                  Expires June 11, 2008                 [Page 9]


Internet-Draft          IPsec Connection Latching          December 2007


   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 will reset or otherwise terminate the
      connection and inform the application.

   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.2.  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
   (the tags don't appear on the wire):




Williams                  Expires June 11, 2008                [Page 10]


Internet-Draft          IPsec Connection Latching          December 2007


   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 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
   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.

   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



Williams                  Expires June 11, 2008                [Page 11]


Internet-Draft          IPsec Connection Latching          December 2007


   offload hardware that does not support the packet tagging scheme
   described above.

2.3.  Non-native mode IPsec

   Non-native IPsec implementations, primarily BITS and SG, can
   implement connection latching too.  One major distinction between
   native IPsec and BITS/BITW/SG IPsec is the lack of APIs for
   applications at the end-points in the case of the latter.  As a
   result there can be no uses of the latch management interfaces as
   described in Section 2.1, 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.4.  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.1 and Section 2.3
   will be unable to narrow the new peer's child SA proposals to avoid a
   conflict, and must either reject them or terminate the existing
   connection.  Implementations based on Section 2.2 must either drop
   the new peer's TCP SYN packet, respond with a TCP RST packet, or
   terminate the existing connection.




Williams                  Expires June 11, 2008                [Page 12]


Internet-Draft          IPsec Connection Latching          December 2007


   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 June 11, 2008                [Page 13]


Internet-Draft          IPsec Connection Latching          December 2007


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.2
   optional protection comes naturally: the IPsec layer need only check
   that the protection requested for outbound packets meets or exceeds
   the quality of protection, if any, required by the SPD.  Similarly,
   for the model described in Section 2.1 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.1).  Such updates of the SPD MUST NOT survive
   system crashes or reboots.
























Williams                  Expires June 11, 2008                [Page 14]


Internet-Draft          IPsec Connection Latching          December 2007


4.  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.

   IPsec channels are a pre-requisite for channel binding
   [I-D.williams-on-channel-binding] to IPsec.  Connection latching
   provides such channels, but the process of binding IPsec channels
   (latched connections) to authentication at application layers is not
   specified herein.

   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 June 11, 2008                [Page 15]


Internet-Draft          IPsec Connection Latching          December 2007


5.  IANA Considerations

   There are not IANA considerations for this document.
















































Williams                  Expires June 11, 2008                [Page 16]


Internet-Draft          IPsec Connection Latching          December 2007


6.  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 June 11, 2008                [Page 17]


Internet-Draft          IPsec Connection Latching          December 2007


7.  References

7.1.  Normative References

   [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.

   [I-D.ietf-btns-core]
              Williams, N. and M. Richardson, "Better-Than-Nothing-
              Security: An Unauthenticated Mode of IPsec",
              draft-ietf-btns-core-05 (work in progress),
              September 2007.

   [I-D.ietf-btns-prob-and-applic]
              Touch, J., "Problem and Applicability Statement for Better
              Than Nothing Security  (BTNS)",
              draft-ietf-btns-prob-and-applic-05 (work in progress),
              February 2007.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2367]  McDonald, D., Metz, C., and B. Phan, "PF_KEY Key
              Management API, Version 2", RFC 2367, July 1998.

   [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.

7.2.  Informative References

   [I-D.bellovin-useipsec]
              Bellovin, S., "Guidelines for Mandating the Use of IPsec",
              draft-bellovin-useipsec-06 (work in progress),
              February 2007.

   [I-D.williams-on-channel-binding]
              Williams, N., "On the Use of Channel Bindings to Secure
              Channels", draft-williams-on-channel-binding-04 (work in
              progress), August 2007.

   [RFC4322]  Richardson, M. and D. Redelmeier, "Opportunistic
              Encryption using the Internet Key Exchange (IKE)",
              RFC 4322, December 2005.



Williams                  Expires June 11, 2008                [Page 18]


Internet-Draft          IPsec Connection Latching          December 2007


Author's Address

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

   Email: Nicolas.Williams@sun.com










































Williams                  Expires June 11, 2008                [Page 19]


Internet-Draft          IPsec Connection Latching          December 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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 June 11, 2008                [Page 20]