NETWORK WORKING GROUP                                        N. Williams
Internet-Draft                                                       Sun
Expires: August 26, 2006                               February 22, 2006

                  IPsec Channels: Connection Latching

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on August 26, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).


   This document specifies, abstractly, how to interface applications
   and transport protocols with IPsec so as to create "channels" by
   "latching" connections to certain IPsec Security Association (SA)
   parameters for their lifetime.  This can be used to protect
   applications against accidental reconfiguration of IPsec that might
   expose live packet flows to unintended peers, such as might happen
   with Better Than Nothing Security (BTNS).  Latched connections
   represent IPsec channels, and as such, allow for channel binding to

Williams                 Expires August 26, 2006                [Page 1]

Internet-Draft          IPsec Connection Latching          February 2006

Table of Contents

   1.    Introduction  . . . . . . . . . . . . . . . . . . . . . . . . 3
   1.1.  Conventions used in this document . . . . . . . . . . . . . . 3
   2.    Connection Latching . . . . . . . . . . . . . . . . . . . . . 4
   3.    Security Considerations . . . . . . . . . . . . . . . . . . . 6
   4.    IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
   5.    Normative . . . . . . . . . . . . . . . . . . . . . . . . . . 7
         Author's Address  . . . . . . . . . . . . . . . . . . . . . . 8
         Intellectual Property and Copyright Statements  . . . . . . . 9

Williams                 Expires August 26, 2006                [Page 2]

Internet-Draft          IPsec Connection Latching          February 2006

1.  Introduction

   IPsec protects packets with little or no regard for stateful packet
   flows associated with upper layer protocols (ULPs).  This limits the
   usefulness of application interfaces to IPsec and exposes
   applications that rely on IPsec for session protection to risks
   associated with changing IPsec configurations and weak association of
   peers and their addresses.

   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 BTNS [I-D.ietf-btns-prob-and-applic] [BTNS].
   The method outlined below achieves this by interfacing ULPs and
   applications to IPsec and using these interfaces to bind ("latch")
   connections to certain IPsec SA parameters.

1.1.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

Williams                 Expires August 26, 2006                [Page 3]

Internet-Draft          IPsec Connection Latching          February 2006

2.  Connection Latching

   Applications create latched connections implicitly by creating
   connections with the ULPs' default latching policy; alternatively,
   applications MAY request IPsec protection of connections, prior to
   establishment, even when the Security Policy Database (SPD) would
   bypass protection provided that Peer Authentication Database (PAD)
   entries exist to authenticate peers.  ULPs MUST default to latching
   the set of SA parameters given below when applications do not specify
   any and when a connection's initiating packet is sent/received
   protected by IPsec.

   ULPs create latched connections by interfacing with IPsec below as

   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.  If the application requested IPsec protection,
      then the ULP passes this request down to IPsec with the initial
      packet.  If the packet is protected by IPsec then the ULP records
      certain parameters of the SA used to protect it in the
      connection's transmission control block (TCB).

   o  When a ULP receives a connection's initiating packet it should
      obtain, from IP/IPsec, information about how the packet was
      protected; the ULP then records certain parameters of the SA used
      to protect the incoming packet in the connection's TCB.

   Once SA parameters are recorded in a connection's TCB the ULP
   enforces the connection's latch, or binding, to these parameters as

   o  The ULP inspects the SA used to protect input packets and drops
      packets which are either protected by SAs whose parameters do not
      match the latched parameters or which are not protected at all.

   o  The ULP always requests that outgoing packets be protected by SAs
      with the latched parameters.

   This requires certain logical interfaces between ULPs and the IP/
   IPsec layer, namely:

   o  That IPsec be able to pass up to ULPs information about how each
      incoming packets was protected, if at all, including specific SA

   o  That ULPs be able to request that IPsec protect outgoing packets,
      including specific SA parameters.

Williams                 Expires August 26, 2006                [Page 4]

Internet-Draft          IPsec Connection Latching          February 2006

   The set of SA parameters that applications may wish to latch
   connections to, and which ULPs MUST allow latching to, includes, but
   is not limited to:

   o  Type of protection: confidentiality and/or integrity protection
      (e.g., ESP vs. AH).

   o  Quality of protection (e.g., algorithms and key sizes, replay

   o  Encapsulation.

   o  Peer identity (i.e., peers' asserted and authorized IDs, as per
      the IPsec processing model [RFC4301].  This item, in particular,
      is necessary to protect applications from weak peer ID<->address
      binding in IPsec configurations.

   ULPs MUST make available to applications the latched SA parameters,
   including node/peer ID types values, and, where nodes are
   authenticated using public keys, the local node and remote peer
   public key values and signature or encryption algorithm identifiers.

   ULPs MUST allow applications to specify all SA parameters other than
   node/peer ID types and values.  ULPs MAY allow applications to
   specify peer ID types and values.

   This method of connection latching works generally for both,
   connection-oriented ULPs (e.g., TCP), and connection-less ULPs (UDP).
   It also works for ULPs that support multi-homing (e.g., SCTP),
   provided that a node has the same ID for all of its addresses that
   may be referenced by an SCTP connection and that its peers' PAD
   configurations reflect this.

   For connection-less ULPs connection latching requires keeping a
   virtual connection (e.g., as in connected UDP sockets in the BSD
   sockets API).  However, it is not necessarily the case that existing
   application interfaces to connection-less ULPs can support implicit
   connection latching.

   This method of connection latching also works generally with key
   exchange protocols, such as IKEv1 [RFC2409] and IKEv2 [RFC4306], as
   well as manual SA keying, and with a variety of peer authentication
   mechanisms (e.g., pre-shared keys, certified public keys, etc...).
   It does not work for multi-casting however.

   Inability to establish an SA with parameters that match a connection
   latch is akin to inability to communicate with the peer; normal ULP
   timeout handling and considerations apply.

Williams                 Expires August 26, 2006                [Page 5]

Internet-Draft          IPsec Connection Latching          February 2006

3.  Security Considerations

   Connection latching protects only individual connections from weak
   peer ID<->address binding or changing IPsec configurations, but it
   does not ensure that any two connections with the same end-point
   addresses, even if one established while the other is alive, will
   have the same latched peer IDs.  In other words, applications that
   use multiple connections between two given nodes are not protected
   any more or less by use of IPsec connection latching than by use of
   IPsec alone.  Such multi-connection applications can, however,
   examine the latched SA parameters of each connection to ensure that
   each every connection with the same end-point addresses also has the
   same end-point IPsec IDs.

   IPsec channels are a pre-requisite for 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.

Williams                 Expires August 26, 2006                [Page 6]

Internet-Draft          IPsec Connection Latching          February 2006

4.  IANA Considerations

   There are not IANA considerations for this document.

5.  Normative

   [BTNS]     Williams, N., "Better-Than-Nothing-Security: An
              Unauthenticated Mode of IPsec", draft-btns-btns-00.txt
              (work in progress), February 2006.

              Touch, J., "Problem and Applicability Statement for Better
              Than Nothing Security  (BTNS)",
              draft-ietf-btns-prob-and-applic-00 (work in progress),
              July 2005.

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

   [RFC2409]  Harkins, D. and D. Carrel, "The Internet Key Exchange
              (IKE)", RFC 2409, November 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.

Williams                 Expires August 26, 2006                [Page 7]

Internet-Draft          IPsec Connection Latching          February 2006

Author's Address

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


Williams                 Expires August 26, 2006                [Page 8]

Internet-Draft          IPsec Connection Latching          February 2006

Intellectual Property Statement

   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

   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

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The Internet Society (2006).  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.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Williams                 Expires August 26, 2006                [Page 9]