< draft-ietf-btns-connection-latching-10.txt   draft-ietf-btns-connection-latching-11.txt >
NETWORK WORKING GROUP N. Williams NETWORK WORKING GROUP N. Williams
Internet-Draft Sun Internet-Draft Sun
Intended status: Standards Track April 9, 2009 Intended status: Standards Track August 13, 2009
Expires: October 11, 2009 Expires: February 14, 2010
IPsec Channels: Connection Latching IPsec Channels: Connection Latching
draft-ietf-btns-connection-latching-10.txt draft-ietf-btns-connection-latching-11.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 32 skipping to change at page 1, line 32
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 11, 2009. This Internet-Draft will expire on February 14, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 24 skipping to change at page 2, line 24
measure of protection to BTNS IPsec nodes. measure of protection to BTNS IPsec nodes.
Finally, the availability of IPsec channels will make it possible to Finally, the availability of IPsec channels will make it possible to
use channel binding to IPsec channels. use channel binding to IPsec channels.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conventions used in this document . . . . . . . . . . . . 5 1.1. Conventions used in this document . . . . . . . . . . . . 5
2. Connection Latching . . . . . . . . . . . . . . . . . . . 5 2. Connection Latching . . . . . . . . . . . . . . . . . . . 5
2.1. Latching of Quality of Protection Parameters . . . . . . . 8 2.1. Latching of Quality of Protection Parameters . . . . . . . 9
2.2. Connection latch state machine . . . . . . . . . . . . . . 9 2.2. Connection latch state machine . . . . . . . . . . . . . . 9
2.3. Normative Model: ULP interfaces to the key manager . . . . 11 2.3. Normative Model: ULP interfaces to the key manager . . . . 11
2.3.1. Race Conditions and Corner Cases . . . . . . . . . . . . . 16 2.3.1. Race Conditions and Corner Cases . . . . . . . . . . . . . 16
2.3.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.3.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4. Informative model: local packet tagging . . . . . . . . . 19 2.4. Informative model: local packet tagging . . . . . . . . . 19
2.5. Non-native mode IPsec . . . . . . . . . . . . . . . . . . 20 2.5. Non-native mode IPsec . . . . . . . . . . . . . . . . . . 20
2.6. Implementation Note Regarding Peer IDs . . . . . . . . . . 21 2.6. Implementation Note Regarding Peer IDs . . . . . . . . . . 21
3. Optional Features . . . . . . . . . . . . . . . . . . . . 21 3. Optional Features . . . . . . . . . . . . . . . . . . . . 21
3.1. Optional Protection . . . . . . . . . . . . . . . . . . . 21 3.1. Optional Protection . . . . . . . . . . . . . . . . . . . 21
4. Simulataneous latch establishment . . . . . . . . . . . . 22 4. Simulataneous latch establishment . . . . . . . . . . . . 22
5. Connection Latching to IPsec for Various ULPs . . . . . . 22 5. Connection Latching to IPsec for Various ULPs . . . . . . 22
5.1. Connection Latching to IPsec for TCP . . . . . . . . . . . 23 5.1. Connection Latching to IPsec for TCP . . . . . . . . . . . 23
5.2. Connection Latching to IPsec for UDP with Simulated 5.2. Connection Latching to IPsec for UDP with Simulated
Connections . . . . . . . . . . . . . . . . . . . . . . . 23 Connections . . . . . . . . . . . . . . . . . . . . . . . 23
5.3. Connection Latching to IPsec for UDP with 5.3. Connection Latching to IPsec for UDP with
Datagram-Tagging APIs . . . . . . . . . . . . . . . . . . 24 Datagram-Tagging APIs . . . . . . . . . . . . . . . . . . 24
5.4. Connection Latching to IPsec for SCTP . . . . . . . . . . 24 5.4. Connection Latching to IPsec for SCTP . . . . . . . . . . 24
6. Security Considerations . . . . . . . . . . . . . . . . . 25 5.5. Handling of BROKEN state for TCP and SCTP . . . . . . . . 25
6.1. Impact on IPsec . . . . . . . . . . . . . . . . . . . . . 25 6. Security Considerations . . . . . . . . . . . . . . . . . 26
6.2. Impact on IPsec of Optional Features . . . . . . . . . . . 26 6.1. Impact on IPsec . . . . . . . . . . . . . . . . . . . . . 26
6.3. Security Considerations for Applications . . . . . . . . . 26 6.2. Impact on IPsec of Optional Features . . . . . . . . . . . 27
6.3. Security Considerations for Applications . . . . . . . . . 27
6.4. Channel Binding and IPsec APIs . . . . . . . . . . . . . . 27 6.4. Channel Binding and IPsec APIs . . . . . . . . . . . . . . 27
7. IANA Considerations . . . . . . . . . . . . . . . . . . . 27 6.5. Denial of Service Attacks . . . . . . . . . . . . . . . . 28
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 27 7. IANA Considerations . . . . . . . . . . . . . . . . . . . 28
9. References . . . . . . . . . . . . . . . . . . . . . . . . 27 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 28
9.1. Normative References . . . . . . . . . . . . . . . . . . . 27 9. References . . . . . . . . . . . . . . . . . . . . . . . . 29
9.2. Informative References . . . . . . . . . . . . . . . . . . 28 9.1. Normative References . . . . . . . . . . . . . . . . . . . 29
Author's Address . . . . . . . . . . . . . . . . . . . . . 29 9.2. Informative References . . . . . . . . . . . . . . . . . . 29
Author's Address . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
IPsec protects packets with little or no regard for stateful packet IPsec protects packets with little or no regard for stateful packet
flows associated with upper layer protocols (ULPs). This exposes flows associated with upper layer protocols (ULPs). This exposes
applications that rely on IPsec for session protection to risks applications that rely on IPsec for session protection to risks
associated with changing IPsec configurations, configurations that associated with changing IPsec configurations, configurations that
allow multiple peers access to the same addresses, and/or weak allow multiple peers access to the same addresses, and/or weak
association of peer IDs and their addresses. The latter can occur as association of peer IDs and their addresses. The latter can occur as
a result of "wildcard" matching in the IPsec Peer Authorization a result of "wildcard" matching in the IPsec Peer Authorization
skipping to change at page 8, line 16 skipping to change at page 8, line 16
key exchange processes. (This is implied by the above key exchange processes. (This is implied by the above
requirements.) For example, if such an implementation relies on requirements.) For example, if such an implementation relies on
keeping some aspects of connection latch state in the restartable keeping some aspects of connection latch state in the restartable
key management process (e.g., values that potentially have large key management process (e.g., values that potentially have large
representations, such as BTNS peer IDs), then either such state representations, such as BTNS peer IDs), then either such state
must be restored on restart of such a process, or outstanding must be restored on restart of such a process, or outstanding
connection latches must be transitioned to the CLOSED state. connection latches must be transitioned to the CLOSED state.
o Dynamic IPsec policy (see Section 3.1) related to connection o Dynamic IPsec policy (see Section 3.1) related to connection
latches, if any, MUST be torn down when latched connections are latches, if any, MUST be torn down when latched connections are
torn down, and MUST NOT survive reboots. torn down, and MUST NOT survive reboots.
o When IKE dead peer detection (DPD) concludes that the remote peer
is dead or has rebooted, then the system SHOULD consider all
connection latches with that peer to be irremediably broken.
We describe two models, one of them normative, of IPsec channels for We describe two models, one of them normative, of IPsec channels for
native IPsec implementations. The normative model is based on native IPsec implementations. The normative model is based on
abstract programming interfaces in the form of function calls between abstract programming interfaces in the form of function calls between
ULPs and the key management component of IPsec (basically, the SAD, ULPs and the key management component of IPsec (basically, the SAD,
augmented with a Latch Database (LD)). The second model is based on augmented with a Latch Database (LD)). The second model is based on
abstract programming interfaces between ULPs and the IPsec abstract programming interfaces between ULPs and the IPsec
(Encapsulating Security Payload / Authentication Header (ESP/AH)) (Encapsulating Security Payload / Authentication Header (ESP/AH))
layer in the form of meta-data tagging of packets within the IP layer in the form of meta-data tagging of packets within the IP
stack. stack.
skipping to change at page 9, line 30 skipping to change at page 9, line 34
cryptographic suites, rather than a single cryptographic suite. In cryptographic suites, rather than a single cryptographic suite. In
such a case an implementation MUST report the QoP being used as such a case an implementation MUST report the QoP being used as
indeterminate. indeterminate.
2.2. Connection latch state machine 2.2. Connection latch state machine
Connection latches can exist in any of the following five states: Connection latches can exist in any of the following five states:
o LISTENER o LISTENER
o ESTABLISHED o ESTABLISHED
o BROKEN (there exist SAs which conflict with the given connection o BROKEN (there exist SAs which conflict with the given connection
latch) latch, conflicting SPD changes have been made, or DPD has been
triggered and the peer is considered dead or restarted)
o CLOSED (by the ULP, the application or administratively) o CLOSED (by the ULP, the application or administratively)
and always have an associated owner, or holder, such as a ULP and always have an associated owner, or holder, such as a ULP
transmission control block (TCB). transmission control block (TCB).
A connection latch can be born in the LISTENER state, which can A connection latch can be born in the LISTENER state, which can
transition only to the CLOSED state. The LISTENER state corresponds transition only to the CLOSED state. The LISTENER state corresponds
to LISTEN state of TCP (and other ULPs) and is associated with IP to LISTEN state of TCP (and other ULPs) and is associated with IP
3-tuples, and can give rise to new connection latches in the 3-tuples, and can give rise to new connection latches in the
ESTABLISHED state. ESTABLISHED state.
skipping to change at page 10, line 11 skipping to change at page 10, line 15
Connection latches remain in the CLOSED state until their owners are Connection latches remain in the CLOSED state until their owners are
informed except where the owner caused the transition, in which case informed except where the owner caused the transition, in which case
this state is fleeting. Transitions from ESTABLISHED or BROKEN this state is fleeting. Transitions from ESTABLISHED or BROKEN
states to the CLOSED state should typically be initiated by latch states to the CLOSED state should typically be initiated by latch
owners, but implementations SHOULD provide administrative interfaces owners, but implementations SHOULD provide administrative interfaces
through which to close active latches. through which to close active latches.
Connection latches transition to the BROKEN state when there exist Connection latches transition to the BROKEN state when there exist
SAs in the SAD whose traffic selectors encompass the 5-tuple bound by 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 the latch, and whose peer and/or parameters conflict with those bound
by the latch. Transitions to the BROKEN state always cause the by the latch. Transitions to the BROKEN state also take place when
SPD changes occur that would cause the latched connection's packets
to be sent or received with different protection parameters than
those that were latched. Transitions to the BROKEN state are also
allowed when IKEv2 DPD concludes that the remote peer is dead or has
rebooted. Transitions to the BROKEN state always cause the
associated owner to be informed. Connection latches in the BROKEN associated owner to be informed. Connection latches in the BROKEN
state transition back to ESTABLISHED when the conflict is cleared. state transition back to ESTABLISHED when all SA and/or SPD conflicts
are cleared.
Most state transitions are the result of local actions of the latch Most state transitions are the result of local actions of the latch
owners (ULPs). The only exceptions are: birth into the ESTABLISHED owners (ULPs). The only exceptions are: birth into the ESTABLISHED
state from latches in the LISTENER state, transitions to the BROKEN state from latches in the LISTENER state, transitions to the BROKEN
state, transitions from the BROKEN state to ESTABLISHED, and state, transitions from the BROKEN state to ESTABLISHED, and
administrative transitions to the CLOSED state. (Additionally, see administrative transitions to the CLOSED state. (Additionally, see
the implementation note about restartable key management processes in the implementation note about restartable key management processes in
Section 2.) Section 2.)
The state diagram below makes use of conventions described in The state diagram below makes use of conventions described in
Section 1.1 and state transition events described in Section 2.3. Section 1.1 and state transition events described in Section 2.3.
skipping to change at page 11, line 24 skipping to change at page 11, line 24
| : : : : | dotted lines denote| | : : : : | dotted lines denote|
| <conn. trigger event> : : | latch creation | | <conn. trigger event> : : | latch creation |
| (e.g., TCP SYN : : : | | | (e.g., TCP SYN : : : | |
| received, : : : | solid lines denote | | received, : : : | solid lines denote |
| connect() : : : | state transition| | connect() : : : | state transition|
| called, ...) v v : | | | called, ...) v v : | |
| : /-----------\ : | semi-solid lines | | : /-----------\ : | semi-solid lines |
| : |ESTABLISHED| : | denote async | | : |ESTABLISHED| : | denote async |
| <conflict> \-----------/ : | notification | | <conflict> \-----------/ : | notification |
| : ^ | : +--------------------+ | : ^ | : +--------------------+
| : | <conflict> | : | <conflict
| : <conflict | : | : <conflict or DPD>
| : cleared> | : | : cleared> | :
| : | | : | : | | :
| : | v v | : | v v
| : /----------------\ | : /----------------\
| :.....>| BROKEN |.-.-.-.-.-> <ALERT()> | :.....>| BROKEN |.-.-.-.-.-> <ALERT()>
| \----------------/ | \----------------/
| | | |
<RELEASE_LATCH()> <RELEASE_LATCH()> <RELEASE_LATCH()> <RELEASE_LATCH()>
| | | |
| v | v
skipping to change at page 23, line 24 skipping to change at page 23, line 24
o A TCP SYN packet is received on an IP address and port number for o A TCP SYN packet is received on an IP address and port number for
which there is a listener. This should cause the creation of an which there is a listener. This should cause the creation of an
ESTABLISHED or BROKEN connection latch. ESTABLISHED or BROKEN connection latch.
o A TCP SYN packet is sent (e.g., as the result of a call to the BSD o A TCP SYN packet is sent (e.g., as the result of a call to the BSD
sockets connect() function). This should cause the creation of an sockets connect() function). This should cause the creation of an
ESTABLISHED or BROKEN connection latch. ESTABLISHED or BROKEN connection latch.
o Any state transition of a TCP connection to the CLOSED state will o Any state transition of a TCP connection to the CLOSED state will
cause a corresponding transition for any associated connection cause a corresponding transition for any associated connection
latch to the CLOSED state as well. latch to the CLOSED state as well.
When a connection latch transitions to the BROKEN state and the See Section 5.5 for how to handle latch transitions to the BROKEN
application requested (or system policy dictates it) that the state.
connection be broken, then TCP should inform the application, if
there is a way to do so, or else it should wait, allowing the TCP
keepalive (or application-layer keepalive strategy) to timeout the
connection, if enabled. When a connection latch is administratively
transitioned to the CLOSED state then TCP should act as though an RST
packet has been received.
5.2. Connection Latching to IPsec for UDP with Simulated Connections 5.2. Connection Latching to IPsec for UDP with Simulated Connections
UDP [RFC0768] is a connection-less transport protocol. However, some UDP [RFC0768] is a connection-less transport protocol. However, some
networking APIs (e.g., the BSD sockets API) allow for emulation of networking APIs (e.g., the BSD sockets API) allow for emulation of
UDP connections. In this case connection latching can be supported UDP connections. In this case connection latching can be supported
using either model given above. We ignore, in this section, the fact using either model given above. We ignore, in this section, the fact
that the connection latching model described in Section 2.4 can that the connection latching model described in Section 2.4 can
support per-datagram latching by extending its packet tagging support per-datagram latching by extending its packet tagging
interfaces to the application. interfaces to the application.
skipping to change at page 25, line 22 skipping to change at page 25, line 16
o An SCTP ASCONF chunk [RFC5061] adding an end-point IP address is o An SCTP ASCONF chunk [RFC5061] adding an end-point IP address is
sent or received. This should cause the creation of one or more sent or received. This should cause the creation of one or more
ESTABLISHED or BROKEN connection latches. ESTABLISHED or BROKEN connection latches.
o Any state transition of an SCTP association to the CLOSED state o Any state transition of an SCTP association to the CLOSED state
will cause a corresponding transition for any associated will cause a corresponding transition for any associated
connection latches to the CLOSED state as well. connection latches to the CLOSED state as well.
o An SCTP ASCONF chunk [RFC5061] deleting an end-point IP address is o An SCTP ASCONF chunk [RFC5061] deleting an end-point IP address is
sent or received. This should cause one or more associated sent or received. This should cause one or more associated
connection latches to be CLOSED. connection latches to be CLOSED.
When a connection latch transitions to the BROKEN state and the See Section 5.5 for how to handle latch transitions to the BROKEN
application requested (or system policy dictates it) that the state.
connection be broken, then SCTP should inform the application, if
there is a way to do so, or else it should wait, allowing SCTP path/ 5.5. Handling of BROKEN state for TCP and SCTP
endpoint failure detection (and/or application-layer keepalive
strategy) to timeout the connection. When a connection latch is There are several ways to handle connection latch transitions to the
administratively transitioned to the CLOSED state then SCTP should BROKEN state in the case of connection-oriented ULPs like TCP or
act as though an ABORT chunk has been received. SCTP:
a. Wait for a possible future transition back to the ESTABLISHED
state, until which time the ULP will not move data between the
two end-points of the connection. ULP and application timeout
mechanisms will, of course, trigger in the event of too lengthy a
stay in the BROKEN state. SCTP can detect these timeouts and
initiate failover, in the case of multi-homed associations.
b. Act as though the connection has been reset (RST message
received, in TCP, or ABORT message received, in SCTP).
c. Act as though an ICMP destination unreachable message had been
received (in SCTP such messages can trigger path failover in the
case of multi-homed associations).
Implementions SHOULD provide APIs for either informing applications
(asynchronously or otherwise) of latch breaks, so that they may
choose a disposition (wait, close, or proceed with path failover), or
by which applications can select a specific disposition a priori
(before a latch break happens).
Implementions MUST provide a default disposition in the event of a
connection latch break. Though (a) is clearly the purist default, we
RECOMMEND (b) for TCP and SCTP associations where only a single path
remains (one 5-tuple), and (c) for multi-homed SCTP associations.
The rationale for this recommendation is as follows: a conflicting SA
most likely indicates that the original peer is gone and has been
replaced by another, and it's not likely that the original peer will
return, thus failing faster seems reasonable.
Note that our recommended default behavior does not create off-path
reset denial-of-service (DoS) attacks: to break a connection latch an
attacker would first have to successfully establish an SA, with one
of the connection's end-points, that conflicts with the connection
latch, and that requires multiple messages to be exchanged between
that end-point and the attacker. Unless the attacker's chosen victim
end-point allows the attacker to claim IP address ranges for its SAs
then the attacker would have to actually take over the other end-
point's addresses, which rules out off-path attacks.
6. Security Considerations 6. Security Considerations
6.1. Impact on IPsec 6.1. Impact on IPsec
Connection latching effectively adds a mechanism for dealing with the Connection latching effectively adds a mechanism for dealing with the
existence, in the SAD, of multiple non-equivalent child SAs with existence, in the SAD, of multiple non-equivalent child SAs with
overlapping traffic selectors. This mechanism consists of, at overlapping traffic selectors. This mechanism consists of, at
minimum, a local notification of transport protocols (and, through minimum, a local notification of transport protocols (and, through
them, applications) of the existence of such a conflict which affects them, applications) of the existence of such a conflict which affects
skipping to change at page 27, line 30 skipping to change at page 28, line 13
IPsec channels are a pre-requisite for channel binding [RFC5056] to IPsec channels are a pre-requisite for channel binding [RFC5056] to
IPsec. Connection latching provides such channels, but the channel IPsec. Connection latching provides such channels, but the channel
bindings for IPsec channels (latched connections) are not specified bindings for IPsec channels (latched connections) are not specified
herein -- that is a work in progress herein -- that is a work in progress
[I-D.williams-ipsec-channel-binding]. [I-D.williams-ipsec-channel-binding].
Without IPsec APIs connection latching provides marginal security Without IPsec APIs connection latching provides marginal security
benefits over traditional IPsec. Such APIs are not described herein; benefits over traditional IPsec. Such APIs are not described herein;
see [I-D.ietf-btns-abstract-api]. see [I-D.ietf-btns-abstract-api].
6.5. Denial of Service Attacks
Connection latch state transitions to the BROKEN state can be
triggered by on-path attackers, and any off-path attackers that can
attack routers, or cause an end-point to accept an ICMP Redirect
message. Connection latching protects applications against on- and
off-path attackers in general, but not against on-path denial of
service specifically.
Attackers can break latches if they can trigger DPD on one or both
end-points and if they cause packets to not move between two end-
points. Such attacks generally require that the attacker be on-path,
therefore we consider it acceptable to break latches when DPD
concludes that a peer is dead or rebooted.
Attackers can also break latches if IPsec policy on a node allows the
attacker to use the IP address of a peer of that node. Such
configurations are expected to be used in conjunction with BTNS in
general. Such attacks generally require that the attacker be on-
path.
7. IANA Considerations 7. IANA Considerations
There are not IANA considerations for this document. There are not IANA considerations for this document.
8. Acknowledgements 8. Acknowledgements
The author thanks Michael Richardson for all his help, as well as The author thanks Michael Richardson for all his help, as well as
Stephen Kent, Sam Hartman, Bill Sommerfeld, Dan McDonald, Daniel Stephen Kent, Sam Hartman, Bill Sommerfeld, Dan McDonald, Daniel
Migault, and many others who've participated in the BTNS WG or who've Migault, and many others who've participated in the BTNS WG or who've
answered questions about IPsec, connection latching implementations, answered questions about IPsec, connection latching implementations,
 End of changes. 14 change blocks. 
36 lines changed or deleted 100 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/