[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: September 1, 2007                             February 28, 2007


                  IPsec Channels: Connection Latching
               draft-ietf-btns-connection-latching-01.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 September 1, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).















Williams                Expires September 1, 2007               [Page 1]

Internet-Draft          IPsec Connection Latching          February 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 their lifetime.  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.  Latched
   connections also represent IPsec channels, a building block for
   channel binding to IPsec; channel binding adds an additional level of
   protection to applications using BTNS IPsec, and IPsec in general.


































Williams                Expires September 1, 2007               [Page 2]

Internet-Draft          IPsec Connection Latching          February 2007


Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  4
   1.1.  Conventions used in this document  . . . . . . . . . . . . .  4
   2.    Connection Latching  . . . . . . . . . . . . . . . . . . . .  5
   2.1.  Using Intimate Interfaces Between ULPs and IPsec . . . . . .  6
   2.2.  Latching through PAD manipulations (and extensions)  . . . .  7
   3.    BYPASS OR PROTECT  . . . . . . . . . . . . . . . . . . . . .  9
   4.    Security Considerations  . . . . . . . . . . . . . . . . . . 10
   5.    IANA Considerations  . . . . . . . . . . . . . . . . . . . . 11
   6.    References . . . . . . . . . . . . . . . . . . . . . . . . . 12
   6.1.  Normative References . . . . . . . . . . . . . . . . . . . . 12
   6.2.  Informative References . . . . . . . . . . . . . . . . . . . 12
         Author's Address . . . . . . . . . . . . . . . . . . . . . . 13
         Intellectual Property and Copyright Statements . . . . . . . 14




































Williams                Expires September 1, 2007               [Page 3]

Internet-Draft          IPsec Connection Latching          February 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 and/or weak association
   of peer IDs and their addresses.  The latter can occur as a result of
   "wildcard" matching inthe 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 September 1, 2007               [Page 4]

Internet-Draft          IPsec Connection Latching          February 2007


2.  Connection Latching

   Applications can 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.  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 protected by IPsec.

   Latches are created when "connections" (packet flows) are
   established.  These may be connections in the TCP sense, but they may
   also be logical (to an application) UDP "connections."

   The set of SA parameters that applications may wish to latch
   connections to includes:

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

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

   o  Transport mode vs. end-to-end tunnel mode.

   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 IDs and associated authentication information
   (e.g., certificates, trust anchors, etcetera).

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

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

   The following two sub-sections are informative; they describe
   possible implementation designs for connection latching.  One method
   works by interfacing IPsec and ULPs "natively," that is, as packets
   move up and down the stack.  The other works by interfacing ULPs and
   IPsec through the key exchange protocol and the PAD.  Both methods
   should work with any IPsec Key Exchange (KE) protocol, such as IKE



Williams                Expires September 1, 2007               [Page 5]

Internet-Draft          IPsec Connection Latching          February 2007


   [RFC2409] or IKEv2 [RFC4306], though the method in Section 2.2 is
   described in terms of the new Security Architecture for the Internet
   Protocol [RFC4301].  Both methods should also work for connection-
   oriented and connection-less transport protocols, though in the
   latter case it APIs are required that support a notion of connections
   when the transport protocol does not.

2.1.  Using Intimate Interfaces Between ULPs and IPsec

   In this section we describe connection latching in terms of intimate
   interfaces between ULPs and IPsec.

   This section is INFORMATIVE.

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

   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.

   All this requires intimate 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
      parameters.




Williams                Expires September 1, 2007               [Page 6]

Internet-Draft          IPsec Connection Latching          February 2007


   o  That ULPs be able to request that IPsec protect outgoing packets,
      including specific SA parameters, and that they get feedback from
      IPsec.

2.2.  Latching through PAD manipulations (and extensions)

   In this section we describe connection latching in terms ULP queries
   and manipulations of the IPsec PAD database.

   This section is INFORMATIVE.

   We imagine interfaces to the IPsec PAD database:

   o  Create a "template" PAD entry, and insert it into the PAD at an
      appropriate insertion point, whose child SA traffic selector
      contraints are exactly those of a specific packet flow (i.e., a
      five-tuple) such that: if a child SA exists or when one is created
      whose traffic selectors encompass that packet flow's selectors
      then the template will be "cloned" such that the clone entry
      matches only the peer ID of that SA.

   o  Create a template PAD entry, and insert it into the PAD at an
      appropriate insertion point, whose child SA traffic selector
      contraints correspond to a local listener (i.e., a three-tuple)
      such that when a child SA is created with traffic selectors
      encompassing template entry's then the template PAD entry is
      cloned such that: if a child SA exists or when one is created
      whose traffic selectors encompass that packet flow's selectors
      then the template will be "cloned" such that the clone entry
      matches only the peer ID of that SA.

   o  Search the PAD for a cloned PAD entry (and associated cloned SPD
      entries) matching a given packet flow's traffic selectors.

   o  Release a template PAD entry.

   o  Release a cloned PAD entry given the traffic selectors of the
      packet flow that should have given rise to the clone entry being
      deleted.  This will also release associated cloned SPD entries.

   Cloned and template PAD entries would have to be inserted ahead of
   any PAD entries that use wildcards or address/port ranges.

   It is crucial that once a cloned PAD entry exists no SAs can be
   created for a different peer whose traffic selectors match or
   emcopass those of the cloned entry.  This can be accomplished by
   searching the PAD at child SA creation time to look for conflicting
   cloned PAD entries.



Williams                Expires September 1, 2007               [Page 7]

Internet-Draft          IPsec Connection Latching          February 2007


   ULPs create latched connections by interfacing with IPsec below as
   follows:

   o  For listening end-points the ULP will create a template PAD entry
      with the listener's 3-tuple as child SA traffic selector
      constraints.

   o  When initiating a "connection" the ULP will create a template PAD
      entry with the packet flow's 5-tuple as child SA traffic selector
      constraints.

   o  When tearing down a "connection" the ULP will release any cloned
      PAD entry that matches the connection's 5-tuple.

   o  When tearing down a listener the ULP will release any template PAD
      entry matching the listener's 3-tuple.  Any cloned entries that
      were created as a result of this template entry are not released.

   o  When a ULP rejects connections or packets for non-existent
      connections the ULP has to release any cloned PAD entries that may
      have been created by IPsec processing of the rejected packet.

   One benefit of this method of connection latching is that it may be
   possible to implement connection latching in bump-in-the-stack (BITS)
   IPsec implementations.  For example, a network interface may provide
   ESP/AH offload capabilities and may hold subset of the SAD and the
   SPDs, but may not support tagging packets with information about the
   SA used or to be used.  In such a case the native interface method of
   connection latching may not be workable, but this method should be.

   Note that there is a race condition in this method of connection
   latching: ULPs may not be able to determine how connection-initiating
   packets were protected that arrive between the time a connection is
   closed and the time all associated PAD/SADB state is cleaned up.  For
   this reason ULPs should discard all connection-initiating packets
   arriving within some time of closing a connection; this time should
   based on a multiple of the maximum time to flush cloned PAD entries,
   associated SADB entries and the time it takes for a packet to move up
   the stack from ESP to the ULP.












Williams                Expires September 1, 2007               [Page 8]

Internet-Draft          IPsec Connection Latching          February 2007


3.  BYPASS OR PROTECT

   For some applications it may be useful to support both, protected and
   bypassed connections -- as long as the application knows whether a
   given connection is protected then it may take appropriate actions
   with respect to unprotected ones (e.g., require use of an
   application-layer security framework or mechanism, such as SASL
   [RFC4322]).

   The native method of connection latching described in Section 2.1 can
   be easily adapted to support this concept.  But the method for
   connection latching through PAD extensions would require a similar
   extension to the SPD: the ability to create template SPD entries to
   "BYPASS OR PROTECT" such that: when an SA is created for a packet
   flow that would match such a template SPD entry, then the template
   entry will be cloned as a PROTECT entry (note: use Populate From
   Packet (PFP) flags), but until then unprotected packets will be
   allowed to bypass IPsec protection.

   BYPASS OR PROTECT SPD entries are particularly useful in the context
   of IPsec-aware applications that can check for IPsec protection and
   act accordingly, but they may also be useful in the context of Stand-
   Alone BTNS (SAB).  BYPASS OR PROTECT SPD entries SHOULD only be
   allowed in the context of SAB or IPsec-aware applications.



























Williams                Expires September 1, 2007               [Page 9]

Internet-Draft          IPsec Connection Latching          February 2007


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

   Implementors should beware of potential race conditions in connection
   latching and defend against them, particularly with respect to
   connection latch tear down.

   Connection latching provides marginal security benefits over
   traditional IPsec without IPsec-specific APIs between applications
   and ULPs.  Such APIs are not described herein.

























Williams                Expires September 1, 2007              [Page 10]

Internet-Draft          IPsec Connection Latching          February 2007


5.  IANA Considerations

   There are not IANA considerations for this document.
















































Williams                Expires September 1, 2007              [Page 11]

Internet-Draft          IPsec Connection Latching          February 2007


6.  References

6.1.  Normative References

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

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

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

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



















Williams                Expires September 1, 2007              [Page 12]

Internet-Draft          IPsec Connection Latching          February 2007


Author's Address

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

   Email: Nicolas.Williams@sun.com










































Williams                Expires September 1, 2007              [Page 13]

Internet-Draft          IPsec Connection Latching          February 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 September 1, 2007              [Page 14]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/