One document matched: draft-ietf-btns-connection-latching-01.txt
Differences from draft-ietf-btns-connection-latching-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-18 22:42:04 |