idnits 2.17.1 draft-ietf-btns-connection-latching-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 493 has weird spacing: '...| IPsec key|...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 9, 2009) is 5495 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'SG-A' is mentioned on line 708, but not defined ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETWORK WORKING GROUP N. Williams 3 Internet-Draft Sun 4 Intended status: Standards Track April 9, 2009 5 Expires: October 11, 2009 7 IPsec Channels: Connection Latching 8 draft-ietf-btns-connection-latching-10.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on October 11, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This document specifies, abstractly, how to interface applications 47 and transport protocols with IPsec so as to create "channels" by 48 latching "connections" (packet flows) to certain IPsec Security 49 Association (SA) parameters for the lifetime of the connections. 50 Connection latching is layered on top of IPsec and does not modify 51 the underlying IPsec architecture. 53 Connection latching can be used to protect applications against 54 accidentally exposing live packet flows to unintended peers, whether 55 as the result of a reconfiguration of IPsec or as the result of using 56 weak peer identity to peer address associations. Weak association of 57 peer ID and peer addresses is at the core of Better Than Nothing 58 Security (BTNS), thus connection latching can add a significant 59 measure of protection to BTNS IPsec nodes. 61 Finally, the availability of IPsec channels will make it possible to 62 use channel binding to IPsec channels. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 67 1.1. Conventions used in this document . . . . . . . . . . . . 5 68 2. Connection Latching . . . . . . . . . . . . . . . . . . . 5 69 2.1. Latching of Quality of Protection Parameters . . . . . . . 8 70 2.2. Connection latch state machine . . . . . . . . . . . . . . 9 71 2.3. Normative Model: ULP interfaces to the key manager . . . . 11 72 2.3.1. Race Conditions and Corner Cases . . . . . . . . . . . . . 16 73 2.3.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 17 74 2.4. Informative model: local packet tagging . . . . . . . . . 19 75 2.5. Non-native mode IPsec . . . . . . . . . . . . . . . . . . 20 76 2.6. Implementation Note Regarding Peer IDs . . . . . . . . . . 21 77 3. Optional Features . . . . . . . . . . . . . . . . . . . . 21 78 3.1. Optional Protection . . . . . . . . . . . . . . . . . . . 21 79 4. Simulataneous latch establishment . . . . . . . . . . . . 22 80 5. Connection Latching to IPsec for Various ULPs . . . . . . 22 81 5.1. Connection Latching to IPsec for TCP . . . . . . . . . . . 23 82 5.2. Connection Latching to IPsec for UDP with Simulated 83 Connections . . . . . . . . . . . . . . . . . . . . . . . 23 84 5.3. Connection Latching to IPsec for UDP with 85 Datagram-Tagging APIs . . . . . . . . . . . . . . . . . . 24 86 5.4. Connection Latching to IPsec for SCTP . . . . . . . . . . 24 87 6. Security Considerations . . . . . . . . . . . . . . . . . 25 88 6.1. Impact on IPsec . . . . . . . . . . . . . . . . . . . . . 25 89 6.2. Impact on IPsec of Optional Features . . . . . . . . . . . 26 90 6.3. Security Considerations for Applications . . . . . . . . . 26 91 6.4. Channel Binding and IPsec APIs . . . . . . . . . . . . . . 27 92 7. IANA Considerations . . . . . . . . . . . . . . . . . . . 27 93 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 27 94 9. References . . . . . . . . . . . . . . . . . . . . . . . . 27 95 9.1. Normative References . . . . . . . . . . . . . . . . . . . 27 96 9.2. Informative References . . . . . . . . . . . . . . . . . . 28 97 Author's Address . . . . . . . . . . . . . . . . . . . . . 29 99 1. Introduction 101 IPsec protects packets with little or no regard for stateful packet 102 flows associated with upper layer protocols (ULPs). This exposes 103 applications that rely on IPsec for session protection to risks 104 associated with changing IPsec configurations, configurations that 105 allow multiple peers access to the same addresses, and/or weak 106 association of peer IDs and their addresses. The latter can occur as 107 a result of "wildcard" matching in the IPsec Peer Authorization 108 Database (PAD), particularly when Better Than Nothing Security (BTNS) 109 [RFC5387] is used. 111 Applications that wish to use IPsec may have to ensure that local 112 policy on the various end-points is configured appropriately 113 [I-D.bellovin-useipsec] [I-D.dondeti-useipsec-430x]. There are no 114 standard Application Programming Interfaces (APIs) to do this -- a 115 major consequence of which, for example, is that applications must 116 still use hostnames (and, e.g., the Domain Name System [RFC1034]) and 117 IP addresses in existing APIs and must depend on an IPsec 118 configuration that they may not be able to verify. In addition to 119 specifying aspects of required Security Policy Database (SPD) 120 configuration, application specifications must also address PAD/SPD 121 configuration to strongly bind individual addresses to individual 122 IPsec identities and credentials (certificates, public keys, ...). 124 IPsec is, then, quite cumbersome for use by applications. To address 125 this we need APIs to IPsec. Not merely APIs for configuring IPsec, 126 but also APIs that are similar to the existing IP APIs (e.g., "BSD 127 sockets"), so that typical applications making use of UDP [RFC0768], 128 TCP [RFC0793] and SCTP [RFC4960] can make use of IPsec with minimal 129 changes. 131 This document describes the foundation for IPsec APIs that UDP and 132 TCP applications can use: a way to bind the traffic flows for, e.g., 133 TCP connections to security properties desired by the application. 134 We call these "connection latches" (and, in some contexts, "IPsec 135 channels"). The methods outlined below achieve this by interfacing 136 ULPs and applications to IPsec. 138 If widely adopted, connection latching could make application use of 139 IPsec much simpler, at least for certain classes of applications. 141 Connection latching, as specified herein, is primarily about watching 142 updates to the SPD and Security Association Database (SAD) to detect 143 changes that are adverse to an application's requirements for any 144 given packet flow, and to react accordingly (such as by synchronously 145 alerting the ULP and application before packets can be sent or 146 received under the new policy). Under no circumstance are IPsec 147 policy databases to be modified by connection latching in any way 148 that can persist beyond the lifetime of the related packet flows, nor 149 reboots. Under no circumstance is the PAD to be modified at all by 150 connection latching. If all optional features of connection latching 151 are excluded then connection latching can be implemented as a monitor 152 of SPD and SAD changes that intrudes in their workings no more than 153 is needed to provide synchronous alerts to ULPs and applications. 155 We assume the reader is familiar with the IPsec architecture 156 [RFC4301] and IKEv2 [RFC4306]. 158 Note: the terms "connection latch" and "IPsec channel" are used 159 interchangeably below. The latter term relates to "channel binding" 160 [RFC5056]. Connection latching is suitable for use in channel 161 binding applications, or will be, at any rate, when the channel 162 bindings for IPsec channels are defined (the specification of IPsec 163 channel bindings is out of scope for this document). 165 Note: where this document mentions IPsec peer "ID" it refers to the 166 Internet Key Exchange (IKE) peer ID (e.g., the ID derived from a 167 peer's cert, as well as the cert), not the peer's IP address. 169 1.1. Conventions used in this document 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 173 document are to be interpreted as described in [RFC2119]. 175 Abstract function names are all capitalized and denoted by a pair of 176 parenthesis. In their descriptions the arguments appear within the 177 parenthesis, with optional argument surrounded by square brackets. 178 Return values, if any, are indicated by following the function 179 argument list with "->" and a description of the return value. For 180 example, "FOO(3-tuple, [message])" would be a function named "FOO" 181 with two arguments, one of them optional, and returning nothing, 182 whereas "FOOBAR(handle) -> state" would be a function with a single, 183 required argument that returns a value. The values' types are 184 described in the surrounding text. 186 2. Connection Latching 188 An "IPsec channel" is a packet flow associated with a ULP control 189 block, such as a TCP connection, where all the packets are protected 190 by IPsec SAs such that: 191 o the peer's identity is the same for the lifetime of the packet 192 flow 193 o the quality of IPsec protection used for the packet flow's 194 individual packets is the same for all of them for the lifetime of 195 the packet flow 197 An IPsec channel is created when the associated packet flow is 198 created. This can be the result of a local operation (e.g., a 199 connect()) that causes the initial outgoing packet for that flow to 200 be sent, or it can be the result of receiving the first/initiating 201 packet for that flow (e.g., a TCP SYN packet). 203 An IPsec channel is destroyed when the associated packet flow ends. 204 An IPsec channel can also be "broken" when the connection latch 205 cannot be maintained for some reason (see below), in which case the 206 ULP and application are informed. 208 IPsec channels are created by "latching" various parameters listed 209 below to a ULP connection when the connections are created. The 210 REQUIRED set of parameters bound in IPsec channels is: 211 o Type of protection: confidentiality and/or integrity protection; 212 o Transport mode vs. tunnel mode; 213 o Quality of protection (QoP): cryptographic algorithm suites, key 214 lengths, and replay protection (see Section 2.1; 215 o Local identity: the local ID asserted to the peer, as per the 216 IPsec processing model [RFC4301] and BTNS [RFC5386]; 217 o Peer identity: the peer's asserted and authorized IDs, as per the 218 IPsec processing model [RFC4301] and BTNS [RFC5386]. 220 The SAs that protect a given IPsec channel's packets may change over 221 time in that they may expire and be replaced with equivalent SAs, or 222 may be re-keyed. The set of SAs that protect an IPsec channel's 223 packets need not be related by anything other than the fact that they 224 must be congruent to the channel (i.e, the SAs' parameters must match 225 those that are latched into the channel). In particular, it is 226 desirable that IPsec channels survive the expiration of IKE_SAs and 227 child SAs because operational considerations of the various key 228 exchange protocols then cannot affect the design and features of 229 connection latching. 231 When a situation arises in which the SPD is modified, or an SA is 232 added to the SAD, such that the new policy or SA are not congruent to 233 an established channel (see previous paragraph) then we consider this 234 a conflict. Conflict resolution is addressed below. 236 Requirements and recommendations: 237 o If an IPsec channel is desired then packets for a given connection 238 MUST NOT be sent until the channel is established. 239 o If an IPsec channel is desired then inbound packets for a given 240 connection MUST NOT be accepted until the channel is established. 241 I.e., inbound packets for a given connection arriving prior to the 242 establishment of the corresponding IPsec channel must be dropped 243 or the channel establishment must fail. 244 o Once an IPsec channel is established, packets for the latched 245 connection MUST NOT be sent unprotected nor protected by an SA 246 that does not match the latched parameters. 247 o Once an IPsec channel is established packets for the latched 248 connection MUST NOT be accepted unprotected nor protected by an SA 249 that does not match the latched parameters. I.e., such packets 250 either must be dropped or must cause the channel to be terminated 251 and the application to be informed before data from such a packet 252 can be delivered to the application. 253 o Implementations SHOULD provide programming interfaces for 254 inquiring the values of the parameters latched in a connection. 255 o Implementations that provide such programming interfaces MUST make 256 available to applications all relevant and available information 257 about a peer's ID, including authentication information. This 258 includes the peer certificate, when one is used, and the trust 259 anchor that it was validated to (but not necessarily the whole 260 certificate validation chain). 261 o Implementations that provide such programming interfaces SHOULD 262 make available to applications any information about local and/or 263 remote public and private IP addresses, in the case of NAT- 264 traversal. 265 o Implementations that provide such programming interfaces SHOULD 266 make available to applications the inner and outer local and peer 267 addresses whenever the latched connection uses tunnel mode SAs. 268 o Implementations SHOULD provide programming interfaces for setting 269 the values of the parameters to be latched in a connection that 270 will be initiated or accepted, but these interfaces MUST limit 271 what values applications may request according to system policy 272 (i.e., the IPsec PAD and SPD) and the application's local 273 privileges. 275 (Typical system policy may not allow applications any choices 276 here. Policy extensions allowing for optional protection are 277 described in Section 3.1.) 278 o Implementations SHOULD create IPsec channels automatically by 279 default when the application does not explicitly request an IPsec 280 channel. Implemenations MAY provide a way to disable automatic 281 creation of connection latches. 282 o The parameters latched in an IPsec channel MUST remain unchanged 283 once the channel is established. 284 o Timeouts while establishing child SAs with parameters that match 285 those latched into an IPsec channel MUST be treated as packet loss 286 (as happens, for example, when a network partitions); normal ULP 287 and/or application timeout handling and retransmission 288 considerations apply. 289 o Implementations that have a restartable key management process (or 290 "daemon") MUST arrange for existing latched connections to either 291 be broken and disconnected, or for them to survive the restart of 292 key exchange processes. (This is implied by the above 293 requirements.) For example, if such an implementation relies on 294 keeping some aspects of connection latch state in the restartable 295 key management process (e.g., values that potentially have large 296 representations, such as BTNS peer IDs), then either such state 297 must be restored on restart of such a process, or outstanding 298 connection latches must be transitioned to the CLOSED state. 299 o Dynamic IPsec policy (see Section 3.1) related to connection 300 latches, if any, MUST be torn down when latched connections are 301 torn down, and MUST NOT survive reboots. 303 We describe two models, one of them normative, of IPsec channels for 304 native IPsec implementations. The normative model is based on 305 abstract programming interfaces in the form of function calls between 306 ULPs and the key management component of IPsec (basically, the SAD, 307 augmented with a Latch Database (LD)). The second model is based on 308 abstract programming interfaces between ULPs and the IPsec 309 (Encapsulating Security Payload / Authentication Header (ESP/AH)) 310 layer in the form of meta-data tagging of packets within the IP 311 stack. 313 The two models given below are not, however, entirely equivalent. 314 One model cannot be implemented with NICs that offload ESP/AH but 315 which do not tag incoming packets passed to the host processor with 316 SA information, nor allow the host processor to so tag outgoing 317 packets. That same model can be easily extended to support 318 connection latching with unconnected datagram "sockets", while the 319 other model is rigidly tied to a notion of "connections" and cannot 320 be so extended. There may be other minor differences between the two 321 models. Rather than seek to establish equivalency for some set of 322 security guarantees we instead choose one model to be the normative 323 one. 325 We also provide a model for non-native implementations, such as bump- 326 in-the-stack (BITS) and Security Gateway (SG) implementations. The 327 connection latching model for non-native implementations is not full- 328 featured as it depends on estimating packet flow state, which may not 329 always be possible. Nor can non-native IPsec implementations be 330 expected to provide APIs related to connection latching 331 (implementations that do could be said to be native). As such this 332 third model is not suitable for channel binding applications 333 [RFC5056]. 335 2.1. Latching of Quality of Protection Parameters 337 In IPsec the assumption of IKE initiator/responder roles is non- 338 deterministic. That is, sometimes an IKE SA and child SAs will be 339 initiated by the "client" (e.g., the caller of the connect() BSD 340 sockets function) and sometimes by the "server" (e.g., the caller of 341 the accept() BSD sockets function). This means that the negotiation 342 of quality of protection is also non-deterministic unless one of the 343 peers offers a single cryptographic suite in the IKE negotiation. 345 When creating narrow child SAs with traffic selectors matching the 346 connection latch's 5-tuple it is possible to constrain the IKE 347 Quality of Protection negotiation to a single cryptographic suite. 348 Therefore implementations SHOULD provide an API for requesting the 349 use of such child SAs. Implementors SHOULD consider an application 350 request for a specific QoP to imply a request for narrow child SAs. 352 When using SAs with traffic selectors encompassing more than just a 353 single flow then the system may only be able to latch a set of 354 cryptographic suites, rather than a single cryptographic suite. In 355 such a case an implementation MUST report the QoP being used as 356 indeterminate. 358 2.2. Connection latch state machine 360 Connection latches can exist in any of the following five states: 361 o LISTENER 362 o ESTABLISHED 363 o BROKEN (there exist SAs which conflict with the given connection 364 latch) 365 o CLOSED (by the ULP, the application or administratively) 366 and always have an associated owner, or holder, such as a ULP 367 transmission control block (TCB). 369 A connection latch can be born in the LISTENER state, which can 370 transition only to the CLOSED state. The LISTENER state corresponds 371 to LISTEN state of TCP (and other ULPs) and is associated with IP 372 3-tuples, and can give rise to new connection latches in the 373 ESTABLISHED state. 375 A connection latch can also be born in the ESTABLISHED and BROKEN 376 states, either through the direct initiative of a ULP or when an 377 event occurs that causes a LISTENER latch to create a new latch (in 378 either ESTABLISHED or BROKEN states). These states represents an 379 active connection latch for a traffic flow's 5-tuple. Connection 380 latches in these two states can transition to the other of the two 381 states, as well as to the CLOSED state. 383 Connection latches remain in the CLOSED state until their owners are 384 informed except where the owner caused the transition, in which case 385 this state is fleeting. Transitions from ESTABLISHED or BROKEN 386 states to the CLOSED state should typically be initiated by latch 387 owners, but implementations SHOULD provide administrative interfaces 388 through which to close active latches. 390 Connection latches transition to the BROKEN state when there exist 391 SAs in the SAD whose traffic selectors encompass the 5-tuple bound by 392 the latch, and whose peer and/or parameters conflict with those bound 393 by the latch. Transitions to the BROKEN state always cause the 394 associated owner to be informed. Connection latches in the BROKEN 395 state transition back to ESTABLISHED when the conflict is cleared. 397 Most state transitions are the result of local actions of the latch 398 owners (ULPs). The only exceptions are: birth into the ESTABLISHED 399 state from latches in the LISTENER state, transitions to the BROKEN 400 state, transitions from the BROKEN state to ESTABLISHED, and 401 administrative transitions to the CLOSED state. (Additionally, see 402 the implementation note about restartable key management processes in 403 Section 2.) 404 The state diagram below makes use of conventions described in 405 Section 1.1 and state transition events described in Section 2.3. 407 408 : 409 v 410 /--------\ : : 411 +------|LISTENER|...... : : 412 | \--------/ : : : +--------------------+ 413 | : : : : |Legend: | 414 | : : : : | dotted lines denote| 415 | : : | latch creation | 416 | (e.g., TCP SYN : : : | | 417 | received, : : : | solid lines denote | 418 | connect() : : : | state transition| 419 | called, ...) v v : | | 420 | : /-----------\ : | semi-solid lines | 421 | : |ESTABLISHED| : | denote async | 422 | \-----------/ : | notification | 423 | : ^ | : +--------------------+ 424 | : | 425 | : | : 427 | : | | : 428 | : | v v 429 | : /----------------\ 430 | :.....>| BROKEN |.-.-.-.-.-> 431 | \----------------/ 432 | | 433 434 | | 435 | v 436 | /------\ 437 +------------------->|CLOSED| 438 \------/ 440 Figure 1: Connection Latching State Machine 442 The details of the transitions depend on the model of connection 443 latching followed by any given implementation. See the following 444 sections. 446 2.3. Normative Model: ULP interfaces to the key manager 448 This section describes the NORMATIVE model of connection latching. 450 In this section we describe connection latching in terms of a 451 function call interface between ULPs and the "key manager" component 452 of a native IPsec implementation. Abstract interfaces for creating, 453 inquiring about, and releasing IPsec channels are described. 455 This model adds a service to the IPsec key manager (i.e., the 456 component that manages the SAD and interfaces with separate 457 implementations of, or directly implements, key exchange protocols): 458 management of connection latches. There is also a new IPsec 459 database, the Latch Database (LD), that contains all connection latch 460 objects. The LD does not persist across system reboots. 462 The traditional IPsec processing model allows the concurrent 463 existence of SAs with different peers but overlapping traffic 464 selectors. Such behaviour, in this model, directly violates the 465 requirements for connection latching (see Section 2). We address 466 this problem by requiring that connection latches be broken (and 467 holders informed) when such conflicts arise. 469 The following INFORMATIVE figure illustrates this model and API in 470 terms that are familiar to many implementors, though not applicable 471 to all: 473 +--------------------------------------------+ 474 | +--------------+ | 475 | |Administrator | | 476 | |apps | | 477 | +--------------+ | 478 | ^ ^ | 479 | | | | user mode 480 | v v | 481 | +--------------+ +-------++--------+ | 482 | |App | |IKEv2 || | | 483 | | | | +---+ || +----+ | | 484 | | | | |PAD| || |SPD | | | 485 | | | | +---+ || +--^-+ | | 486 | +--------------+ +-+-----++----+---+ | 487 | ^ | | | 488 +---|---------------------|-----------|------+ user/kernel mode 489 | |syscalls | PF_KEY | | interface 490 +---|---------------------|-----------|------+ 491 | v | | | 492 |+-------+ +------------|-----------|-----+| 493 ||ULP | | IPsec key|manager | || 494 |+-------+ | | +--------v----+|| 495 | ^ ^ | | | Logical SPD ||| 496 | | | | | +-----------^-+|| 497 | | | | +-------+ | || kernel mode 498 | | | | | | || 499 | | | | +----------+ +--v--+ | || 500 | | +-------->| Latch DB |<-->| SAD | | || 501 | | | +----------+ +--^--+ | || 502 | | +--------------------|------|--+| 503 +-|-------------------------------v------v---+ 504 | | IPsec Layer (ESP/AH) | 505 | | | 506 +-v------------------------------------------+ 507 | IP Layer | 508 +--------------------------------------------+ 510 Figure 2: Informative Implementation Architecture Diagram 512 The ULP interfaces to the IPsec LD database are as follows: 513 o CREATE_LISTENER_LATCH(3-tuple, [type and quality of protection 514 parameters]) -> latch handle | error 515 If there is no conflicting connection latch object in the 516 LISTENER state for the given 3-tuple (local address, protocol 517 and local port number), and local policy permits it, then this 518 operation atomically creates a connection latch object in the 519 LISTENER state for the given 3-tuple. 521 When a child SA is created that matches a listener latch's 522 3-tuple, but not any ESTABLISHED connection latch's 5-tuple 523 (local address, remote address, protocol, local port number and 524 remote port number), then the key manager creates a new 525 connection latch object in the ESTABLISHED state. The key 526 manager MUST inform the holder of the listener latch of 527 connection latches created as a result of the listener latch; 528 see the "ALERT()" interface below. 529 o CREATE_CONNECTION_LATCH(5-tuple, [type and quality of protection 530 parameters], [peer ID], [local ID]) -> latch handle | error 531 If no connection latch exists in the ESTABLISHED states with 532 the same 5-tuple, and if there exist no child SAs that match 533 the given 5-tuple, and if local policy permits it, then the 534 system MUST initiate an IKE exchange to setup child SAs for 535 this 5-tuple. Otherwise an error is returned to the ULP. Once 536 one or more applicable SAs exist in the SAD and all such SAs 537 share the same type and quality of protection parameters and 538 the same peer then this operation creates a connection latch 539 object in the ESTABLISHED state for the given 5-tuple. If the 540 caller provided all the optional arguments to this operation 541 then the resulting connection latch can be created in the 542 ESTABLISHED state directly. 543 If there exist no child SAs matching the given 5-tuple then the 544 key manager SHOULD try to create a pair of child SAs for that 545 5-tuple. In any case, the key manager can expect that the ULP 546 will send a packet that would trigger the creation of such SAs. 547 o RELEASE_LATCH(latch object handle) 548 Changes the state of the given connection latch to CLOSED; the 549 connection latch is then deleted. 550 The key manager MAY delete any existing child SAs that match 551 the given latch if it had been in the ESTABLISHED states. If 552 the key manager does delete such SAs then it SHOULD inform the 553 peer with an informational Delete payload (see IKEv2 554 [RFC4306]). 555 o FIND_LATCH(5-tuple) -> latch handle | error 556 Given a 5-tuple returns a latch handle (or an error). 557 o INQUIRE_LATCH(latch object handle) -> {latch state, latched 558 parameters} | error 559 Returns all available information about the given latch, 560 including its current state (or an error). 562 The IPsec LD interface to the ULP is as follows: 563 o ALERT(latch object handle, 5-tuple, new state, [reason]) 564 Alerts a ULP as to an asynchronous state change for the given 565 connection latch and, optionally, provides a reason for the 566 change. 568 This interface is to be provided by each ULP to the key manager. 570 The specific details of how this interface is provided are 571 implementation details, thus not specified here (for example, this 572 could be a "callback" function or "closure" registered as part of 573 the CREATE_LISTENER_LATCH() interface, or it could be provided 574 when the ULP is loaded onto the running system via a registration 575 interface provided by the key manager. 577 Needless to say, the LD is updated whenever a connection latch object 578 is created, deleted or broken. 580 The API described above is a new service of the IPsec key manager. 581 In particular the IPsec key manager MUST prevent conflicts amongst 582 latches, and it MUST prevent conflicts between any latch and existing 583 or proposed child SAs as follows: 584 o Non-listener connection latches MUST NOT be created if there exist 585 conflicting SAs in the SAD at the time the connection latch is 586 requested or would be created (from a listener latch). A child SA 587 conflicts with another, in view of a latch, if and only if: a) its 588 traffic selectors and the conflicting SA's match the given 589 latch's, and b) its peer, type of protection, or quality of 590 protection parameters differ from the conflicting SA. 591 o Child SA proposals that would conflict with an extant connection 592 latch and whose traffic selectors can be narrowed to avoid the 593 conflict SHOULD be narrowed (see section 2.9 of [RFC4306]), 594 otherwise the latch MUST be transitioned to the BROKEN state. 595 o Where child SA proposals that would conflict with an extant 596 connection latch cannot be narrowed to avoid the conflict the key 597 manager MUST break the connection latch and inform the holder 598 (i.e., the ULP) prior to accepting the conflicting SAs. 600 Finally, the key manager MUST protect latched connections against SPD 601 changes that would change the quality of protection afforded to a 602 latched connection's traffic, or which would bypass it. When such a 603 configuration change takes place the key manager MUST respond in 604 either of the following ways. The REQUIRED to implement behaviour is 605 to transition into the BROKEN state all connection latches that 606 conflict with the given SPD change. An OPTIONAL behaviour is to 607 logically update the SPD as if a PROTECT entry had been added at the 608 head of the SPD-S with traffic selectors matching only the latched 609 connection's 5-tuple, and with processing information taken from the 610 connection latch. Such updates of the SPD MUST NOT survive system 611 crashes or reboots. 613 ULPs create latched connections by interfacing with IPsec below as 614 follows: 615 o For listening end-points the ULP will request a connection latch 616 listener object for the ULP listener's 3-tuple. Any latching 617 parameters requested by the application MUST be passed along. 619 o When the ULP receives a packet initiating a connection for a 620 5-tuple matching a 3-tuple listener latch, then the ULP will ask 621 the key manager whether a 5-tuple connection latch was created. 622 If not then the ULP will either reject the new connection or 623 accept it and inform the application that the new connection is 624 not latched. 625 o When initiating a connection the ULP will request a connection 626 latch object for the connection's 5-tuple. Any latching 627 parameters requested by the application MUST be passed along. If 628 no latch can be created then the ULP MUST either return an error 629 to the application or continue with the new connection and inform 630 the application that the new connection is not latched. 631 o When a connection is torn down and no further packets are expected 632 for it then the ULP MUST request that the connection latch object 633 be destroyed. 634 o When tearing down a listener the ULP MUST request that the 635 connection latch listener object be destroyed. 636 o When a ULP listener rejects connections the ULP will request the 637 destruction of any connection latch objects that may have been 638 created as a result of the peer's attempt to open the connection. 639 o When the key manager informs a ULP that a connection latch has 640 transitioned to the BROKEN state then the ULP MUST stop sending 641 packets and MUST drop all subsequent incoming packets for the 642 affected connection until it transitions back to ESTABLISHED. 643 Connection-oriented ULPs SHOULD act as though the connection is 644 experiencing packet loss. 645 o When the key manager informs a ULP that a connection latch has 646 been administratively transitioned to the CLOSED state then 647 connection-oriented ULPs MUST act as though the connection has 648 been reset by the peer. Implementations of ULPs which are not 649 connection-oriented, and which have no API by which to simulate a 650 reset, MUST drop all inbound packets for that connection and MUST 651 NOT send any further packets -- the application is expected to 652 detect timeouts and act accordingly. 654 The main benefit of this model of connection latching is that it 655 accommodates IPsec implementations where ESP/AH handling is 656 implemented in hardware (for all or a subset of the host's SAD), but 657 where the hardware does not support tagging inbound packets with the 658 indexes of SAD entries corresponding to the SAs that protected them. 660 2.3.1. Race Conditions and Corner Cases 662 ULPs MUST drop inbound packets and stop sending packets immediately 663 upon receipt of a connection latch break message. Otherwise the ULP 664 will not be able to distinguish inbound packets that were protected 665 consistently with the connection's latch from inbound packets that 666 were not. This may include dropping inbound packets that were 667 protected by a suitable SA; dropping such packets is no different, 668 from the ULP's point of view, than packet loss elsewhere on the 669 network at the IP layer or below -- harmless, from a security point 670 of view as the connection fails safe, but it can result in 671 retransmits. 673 Another race condition is as follows. A PROTECTed TCP SYN packet may 674 be received and decapsulated but the SA that protected it could have 675 expired before the key manager creates the connection latch that 676 would be created by that packet. In this case the key manager will 677 have to initiate new child SAs so as to determine what the sender's 678 peer ID is so it can be included in the connection latch. Here there 679 is no guarantee that the peer ID for the new SAs will be the same as 680 those of the peer that sent the TCP SYN packet. This race condition 681 is harmless: TCP will send a SYN+ACK to the wrong peer, which will 682 then respond with an RST -- the connection latch will reflect the new 683 peer however, so if the new peer is malicious it will not be able to 684 appear to be the old peer. Therefore this race condition is 685 harmless. 687 2.3.2. Example 689 Consider several systems with a very simple PAD containing a single 690 entry like so: 692 Child SA 693 Rule Remote ID IDs allowed SPD Search by 694 ---- --------- ----------- ------------- 695 1 192.0.2/24 by-IP 697 Figure 3: Example PAD 699 And a simple SPD like so: 701 Rule Local Remote Next Action 702 TS TS Proto 703 ---- ----- ------ ----- ---------------- 704 1 192.0.2/24:ANY 192.0.2/24:1-5000 TCP PROTECT(ESP,...) 705 1 192.0.2/24:1-5000 192.0.2/24:ANY TCP PROTECT(ESP,...) 706 1 ANY ANY ANY BYPASS 708 Figure 4: [SG-A] SPD table 710 Effectively this says: for TCP ports 1-5000 in our network allow only 711 peers that have credentials issued by CA X and PROTECT that traffic 712 with ESP, otherwise bypass all other traffic. 714 Now let's consider two hosts, A and B, in this network that wish to 715 communicate using port 4000, and a third host, C, that is also in the 716 same network and wishes to attack A and/or B. All three hosts have 717 credentials and certificates issued by CA X. Let's also imagine that 718 A is connected to its network via a wireless link and is dynamically 719 address. 721 B is listening on port 4000. A initiates a connection from port 722 32800 to B on port 4000. 724 We'll assume no IPsec APIs, but that TCP creates latches where 725 possible. 727 We'll consider three cases: a) A and B both support connection 728 latching, b) only A does, c) only B does. For the purposes of this 729 example the SAD is empty on all three hosts when A initiates its TCP 730 connection to B on port 4000. 732 When an application running on A initiates a TCP connection to B on 733 port 4000, A will begin by creating a connection latch. Since the 734 SAD is empty A will initiate an IKEv2 exchange to create an IKE_SA 735 with B and a pair of CHILD SAs for the 5-tuple {TCP, A, 32800, B, 736 4000}, then a new latch will be created in ESTABLISHED state. 737 Sometime later TCP will send a SYN packet protected by the A-to-B 738 child SA, per the SPD. 740 When an application running on B creates a TCP listener "socket" on 741 port 4000, B will create a LISTENER connection latch for the 3-tuple 742 {TCP, B, 4000}. When B receives A's TCP SYN packet it will then 743 create a connection latch for {TCP, B, 4000, A, 32800}. Since by 744 this point CHILD SAs have been created whose traffic selectors 745 encompass this 5-tuple and there are no other conflicting SAs in the 746 SAD, this connection latch will be created in the ESTABLISHED state. 748 If C attempts to mount a man-in-the-middle attack on A (i.e., pretend 749 to have B's address(es)) any time after A created its connection 750 latch then C's SAs with A will cause the connection latch to break, 751 and the TCP connection to be reset (since we assume no APIs by which 752 TCP could notify the application of the connection latch break). If 753 C attempts to impersonate A to B then the same thing will happen on 754 B. 756 If A does not support connection latching then C will be able to 757 impersonate B to A at any time, but without having seen the cleartext 758 of traffic between A and B, C will be limited by the TCP sequence 759 numbers to attacks such as RST attacks. Similarly if B does not 760 support connection latching. 762 2.4. Informative model: local packet tagging 764 In this section we describe connection latching in terms of 765 interfaces between ULPs and IPsec based on tagging packets as they go 766 up and down the IP stack. 768 This section is INFORMATIVE. 770 In this model the ULPs maintain connection latch objects and state, 771 rather than the IPsec key manager, as well as effectively caching a 772 subset of the decorrelated SPD in ULP TCBs. Local tagging of packets 773 as they move up and down the stack with SA identifiers then allows 774 the ULPs to enforce connection latching semantics. These tags, of 775 course, don't appear on the wire. 777 The interface between the ULPs and IPsec interface is as follows: 778 o The IPsec layer tags all inbound protected packets addressed to 779 the host with the index of the SAD entry corresponding to the SA 780 that protected the packet. 781 o The IPsec layer understands two types of tags on outbound packets: 782 * a tag specifying a set of latched parameters (peer ID, quality 783 of protection, etc...) that the IPsec layer will use to find or 784 acquire an appropriate SA for protecting the outbound packet 785 (else IPsec will inform the ULP and drop the packet); 786 * a tag requesting feedback about the SA used to protect the 787 outgoing packet, if any. 789 ULPs create latched connections by interfacing with IPsec below as 790 follows: 791 o When the ULP passes a connection's initiating packet to IP the ULP 792 requests feedback about the SA used to protect the outgoing 793 packet, if any, and may specify latching parameters requested by 794 the application. If the packet is protected by IPsec then the ULP 795 records certain parameters of the SA used to protect it in the 796 connection's TCB. 797 o When a ULP receives a connection's initiating packet it processes 798 the IPsec tag of the packet, and it records in the connection's 799 TCB the parameters of the SA that should be latched. 801 Once SA parameters are recorded in a connection's TCB the ULP 802 enforces the connection's latch, or binding, to these parameters as 803 follows: 804 o The ULP processes the IPsec tag of all inbound packets for a given 805 connection and checks that the SAs used to protect input packets 806 match the connection latches recorded in the TCBs. Packets which 807 are not so protected are dropped (this corresponds to 808 transitioning the connection latch to the BROKEN state until the 809 next acceptable packet arrives, but in this model this transition 810 is imaginary), or cause the ULP to break the connection latch and 811 inform the application. 812 o The ULP always requests that outgoing packets be protected by SAs 813 that match the latched connection by appropriately tagging 814 outbound packets. 816 By effectively caching a subset of the decorrelated SPD in ULP TCBs 817 and through its packet tagging nature, this method of connection 818 latching can also optimize processing of the SPD by obviating the 819 need to search it, both, on input and output, for packets intended 820 for the host or originated by the host. This makes implementation of 821 the OPTIONAL "logical SPD" updates described in Section 2.3 and 822 Section 3.1 an incidental side effect of this approach. 824 This model of connection latching may not be workable with ESP/AH 825 offload hardware that does not support the packet tagging scheme 826 described above. 828 Note that this model has no BROKEN connection latch state. 830 Extending the ULP/IPsec packet-tagging interface to the application 831 for use with connection-less datagram transports should enable 832 applications to use such transports and implement connection latching 833 at the application layer. 835 2.5. Non-native mode IPsec 837 This section is INFORMATIVE. 839 Non-native IPsec implementations, primarily BITS and SG, can 840 implement connection latching too. One major distinction between 841 native IPsec and BITS/BITW/SG IPsec is the lack of APIs for 842 applications at the end-points in the case of the latter. As a 843 result there can be no uses of the latch management interfaces as 844 described in Section 2.3, not at the ULP end-points. Therefore BITS/ 845 BITW/SG implementations must discern ULP connection state from packet 846 inspection (which many firewalls can do) and emulate calls to the key 847 manager accordingly. 849 When a connection latch is broken a BITS/BITW/SG implementation may 850 have to fake a connection reset by sending appropriate packets (e.g., 851 TCP RST packets), for the affected connections. 853 As with all stateful middle-boxes this scheme suffers from the 854 inability of the middle-box to interact with the applications. For 855 example, connection death may be difficult to ascertain. Nor can 856 channel binding applications work with channels maintained by proxy 857 without being able to communicate (securely) about it with the 858 middle-box. 860 2.6. Implementation Note Regarding Peer IDs 862 One of the recommendations for connection latching implementators is 863 to make available peer CERT payloads (certificates) to the 864 applications. 866 Additionally, raw public keys are likely to be used in the 867 construction of channel bindings for IPsec channels; see 868 [I-D.williams-ipsec-channel-binding], and must be available, in any 869 case, in order to implement leap-of-faith at the application layer 870 (see [RFC5386] and [RFC5387]). 872 Certificates and raw public keys are large bit strings, too large to 873 be reasonably kept in kernel-mode implementations of connection 874 latching (which will likely be the typical case). Such 875 implementations should intern peer IDs in a user-mode database and 876 use small integers to refer to them from the kernel-mode SAD and LD. 877 Corruption of such a database is akin to corruption of the SAD/LD; in 878 the event of corruption the implementation MUST act as though all 879 ESTABLISHED and BROKEN connection latches are administratively 880 transitioned to the CLOSED state. Implemenations without IPsec APIs 881 MAY hash peer IDs and use the hash to refer to them, preferably using 882 a strong hash algorithm. 884 3. Optional Features 886 At its bare minimum connection latching is a passive layer atop IPsec 887 that warn ULPs of SPD and SAD changes that are incompatible with the 888 SPD/SAD state that was applicable to a connection when it was 889 established. 891 There are some optional features, such as (abstract) APIs. Some of 892 these features make connection latching a somewhat more active 893 feature. Specifically, the optional logical SPD updates described in 894 Section 2.3 and the optional protection/bypass feature described in 895 the following sub-section. 897 3.1. Optional Protection 899 Given IPsec APIs an application could request that a connection's 900 packets be protected where they would otherwise be bypassed; that is, 901 applications could override BYPASS policy. Locally privileged 902 applications could request that their connections' packets be 903 bypassed rather than protected; that is, privileged applications 904 could override PROTECT policy. We call this "optional protection." 905 Both native IPsec models of connection latching can be extended to 906 support optional protection. With the model described in Section 2.4 907 optional protection comes naturally: the IPsec layer need only check 908 that the protection requested for outbound packets meets or exceeds 909 (as determined by local or system policy) the quality of protection, 910 if any, required by the SPD. Similarly, for the model described in 911 Section 2.3 the check that requested protection meets or exceeds that 912 required by the SPD is performed by the IPsec key manager when 913 creating connection latch and connection latch listener objects. 915 When an application requests, and local policy permits, either 916 additional protection or bypassing protection, then the SPD MUST be 917 logically updated such that there exists a suitable SPD entry 918 protecting or bypassing the exact 5-tuple recorded by the 919 corresponding connection latch. Such logical SPD updates MUST be 920 made at connection latch creation time, and MUST be made atomically 921 (see the note about race conditions in Section 2.3). Such updates of 922 the SPD MUST NOT survive system crashes or reboots. 924 4. Simulataneous latch establishment 926 Some connection-oriented ULPs, specifically TCP, support simulaneous 927 connections (where two clients connect to each other, using the same 928 5-tuple, at the same time). Connection latching supports 929 simultaneous latching as well, provided that the key exchange 930 protocol does not make it impossible. 932 Consider two applications doing a simultaneous TCP connect to each 933 other and requesting an IPsec channel. If they request the same 934 connection latching parameters, then the connection and channel 935 should be established as usual. Even if the key exchange protocol in 936 use doesn't support simultaneous IKE_SA and/or child SA 937 establishment, provided one peer's attempt to create the necessary 938 child SAs succeeds then the other peer should be able to notice the 939 new SAs immediately upon failure of its attempts to create the same. 941 If, however, the two peer applications were to request different 942 connection latching parameters, then the connection latch must fail 943 on one end or on both ends. 945 5. Connection Latching to IPsec for Various ULPs 947 The following sub-sections describe connection latching for each of 948 three transport protocols. Note that for TCP and UDP there is 949 nothing in the following sections that should not already be obvious 950 from the remainder of this document. The section on SCTP, however, 951 specifies details related to SCTP multi-homing, that may not be as 952 obvious. 954 5.1. Connection Latching to IPsec for TCP 956 IPsec connection latch creation/release for TCP [RFC0793] connections 957 is triggered when: 958 o A TCP listener end-point is created (e.g., when the BSD sockets 959 listen() function is called on a socket). This should cause the 960 creation of a LISTENER connection latch. 961 o A TCP SYN packet is received on an IP address and port number for 962 which there is a listener. This should cause the creation of an 963 ESTABLISHED or BROKEN connection latch. 964 o A TCP SYN packet is sent (e.g., as the result of a call to the BSD 965 sockets connect() function). This should cause the creation of an 966 ESTABLISHED or BROKEN connection latch. 967 o Any state transition of a TCP connection to the CLOSED state will 968 cause a corresponding transition for any associated connection 969 latch to the CLOSED state as well. 971 When a connection latch transitions to the BROKEN state and the 972 application requested (or system policy dictates it) that the 973 connection be broken, then TCP should inform the application, if 974 there is a way to do so, or else it should wait, allowing the TCP 975 keepalive (or application-layer keepalive strategy) to timeout the 976 connection, if enabled. When a connection latch is administratively 977 transitioned to the CLOSED state then TCP should act as though an RST 978 packet has been received. 980 5.2. Connection Latching to IPsec for UDP with Simulated Connections 982 UDP [RFC0768] is a connection-less transport protocol. However, some 983 networking APIs (e.g., the BSD sockets API) allow for emulation of 984 UDP connections. In this case connection latching can be supported 985 using either model given above. We ignore, in this section, the fact 986 that the connection latching model described in Section 2.4 can 987 support per-datagram latching by extending its packet tagging 988 interfaces to the application. 990 IPsec connection latch creation/release for UDP connections is 991 triggered when: 992 o An application creates a UDP "connection." This should cause the 993 creation of an ESTABLISHED or BROKEN connection latch. 994 o An application destroys a UDP "connection." This should cause the 995 creation of an ESTABLISHED or BROKEN connection latch. 997 When a connection latch transitions to the BROKEN state and the 998 application requested (or system policy dictates it) that the 999 connection be broken, then UDP should inform the application, if 1000 there is a way to do so, or else it should wait, allowing the 1001 application-layer keepalive/timeout strategy, if any, to timeout the 1002 connection. 1004 What constitutes an appropriate action in the face of administrative 1005 transitions of connection latches to the CLOSED state depends on 1006 whether the implementation's "connected" UDP sockets API provides a 1007 way for the socket to return an error indicating that it has been 1008 closed. 1010 5.3. Connection Latching to IPsec for UDP with Datagram-Tagging APIs 1012 Implementations based on either model of connection latching can 1013 provide applications with datagram-tagging APIs based on those 1014 described in Section 2.4. Implementations UDP with of the normative 1015 model of IPsec connection latching have to confirm, on output, that 1016 the application provided 5-tuple agrees with the application-provided 1017 connection latch; on input, UDP can derive the tag by searching for a 1018 connection latch matching incoming datagram's 5-tuple. 1020 5.4. Connection Latching to IPsec for SCTP 1022 SCTP [RFC4960] a connection-oriented protocol similar, in some ways, 1023 to TCP. The salient difference, with respect to connection latching, 1024 between SCTP and TCP is that SCTP allows each end-point to be 1025 identified by a set of IP addresses, though, like TCP, each end-point 1026 of an SCTP connection (or, rather, SCTP association) can only have 1027 one port number. 1029 We can represent the multiplicity of SCTP association end-point 1030 addresses as a multiplicity of 5-tuples, each of which with its own a 1031 connection latch. Alternatively we can extend the connection latch 1032 object to support a multiplicity of addresses for each end-point. 1033 The first approach is used throughout this document, therefore we 1034 will assume that representation. 1036 Of course, this approach results in N x M connection latches for any 1037 SCTP associations (where one end-point has N addresses and the other 1038 has M), whereas the alternative requires one connecton latch per-SCTP 1039 association (with N + M addresses). Implementors may choose either 1040 approach. 1042 IPsec connection latch creation/release for SCTP connections is 1043 triggered when: 1044 o An SCTP listener end-point is created (e.g., when the SCTP sockets 1045 listen() function is called on a socket). This should cause the 1046 creation of a LISTENER connection latch for each address of the 1047 listener. 1048 o An SCTP INIT chunk is received on an IP address and port number 1049 for which there is a listener. This should cause the creation of 1050 one or more ESTABLISHED or BROKEN connection latches, one for each 1051 distinct 5-tuple given the client and server's addresses. 1052 o An SCTP INIT chunk is sent (e.g., as the result of a call to the 1053 SCTP sockets connect() function). This should cause the creation 1054 of one or more ESTABLISHED or BROKEN connection latches. 1055 o An SCTP ASCONF chunk [RFC5061] adding an end-point IP address is 1056 sent or received. This should cause the creation of one or more 1057 ESTABLISHED or BROKEN connection latches. 1058 o Any state transition of an SCTP association to the CLOSED state 1059 will cause a corresponding transition for any associated 1060 connection latches to the CLOSED state as well. 1061 o An SCTP ASCONF chunk [RFC5061] deleting an end-point IP address is 1062 sent or received. This should cause one or more associated 1063 connection latches to be CLOSED. 1065 When a connection latch transitions to the BROKEN state and the 1066 application requested (or system policy dictates it) that the 1067 connection be broken, then SCTP should inform the application, if 1068 there is a way to do so, or else it should wait, allowing SCTP path/ 1069 endpoint failure detection (and/or application-layer keepalive 1070 strategy) to timeout the connection. When a connection latch is 1071 administratively transitioned to the CLOSED state then SCTP should 1072 act as though an ABORT chunk has been received. 1074 6. Security Considerations 1076 6.1. Impact on IPsec 1078 Connection latching effectively adds a mechanism for dealing with the 1079 existence, in the SAD, of multiple non-equivalent child SAs with 1080 overlapping traffic selectors. This mechanism consists of, at 1081 minimum, a local notification of transport protocols (and, through 1082 them, applications) of the existence of such a conflict which affects 1083 a transport layer's connections. Affected transports are also 1084 notified when the conflict is cleared. The transports must drop 1085 inbound packets, and must not send outbound packets for connections 1086 which are affected by a conflict. In this minimal form connection 1087 latching is a passive, local feature layered atop IPsec. 1089 Connection latching achieves this by adding a new type of IPsec 1090 database, the Latch Database (LD), containing objects which represent 1091 a transport protocol's interest in protecting a given packet flow 1092 from such conflicts. The LD is managed in conjunction with updates 1093 to the SAD and the SPD, so that updates to either which conflict with 1094 established connection latches can be detected. For some IPsec 1095 implementations this may imply significant changes to their 1096 internals. However, two different models of connection laching are 1097 given, and we hope that most native IPsec implementators will find 1098 one model to be significantly simpler to implement than the other, 1099 and simple enough to implement. 1101 This notion of conflicting SAs and how to deal with the situation 1102 does not modify the basic IPsec architecture -- the feature of IPsec 1103 which allows such conflicts to arise remains, and it is up to the 1104 transport protocols and applications to select whether and how to 1105 respond to them. 1107 There are, however, interesting corner cases in the normative model 1108 of connection latching that implementors must be aware of. The notes 1109 in Section 2.3.1 are particularly relevant. 1111 6.2. Impact on IPsec of Optional Features 1113 Section 3 describes optional features of connection latching where 1114 the key manager takes on a somewhat more active, though still local, 1115 role. There are two such features: optional protect/bypass, and 1116 preservation of "logical" SPD entries to allow latched connections to 1117 remain in the ESTABLISHED state in the face of adverse administrative 1118 SPD (but not SAD) changes. These two features interact with 1119 administrative interfaces to IPsec; administrators must be made aware 1120 of these features, and SHOULD be given a way to break ESTABLISHED 1121 connection latches. Also, given recent trends toward centralizing 1122 parts of IPsec policy, these two features can be said to have non- 1123 local effects where they prevent distributed policy changes from 1124 taking effect completely. 1126 6.3. Security Considerations for Applications 1128 Connection latching is not negotiated. It is therefore possible for 1129 one end of a connection to be using connection latching while the 1130 other does not, in which case it's possible for policy changes local 1131 to the non-latched end to cause packets to be sent unprotected. The 1132 end doing connection latching will reject unprotected packets, but if 1133 they bear sensitive data then the damage may already be done. 1134 Therefore applications SHOULD check that both ends of a connection 1135 are latched (such a check is implicit for applications that use 1136 channel binding to IPsec). 1138 Connection latching protects individual connections from weak peer 1139 ID<->address binding, IPsec configuration changes, and from 1140 configurations that allow multiple peers to assert the same 1141 addresses. But connection latching does not ensure that any two 1142 connections with the same end-point addresses will have the same 1143 latched peer IDs. In other words, applications that use multiple 1144 concurrent connections between two given nodes may not be protected 1145 any more or less by use of IPsec connection latching than by use of 1146 IPsec alone without connection latching. Such multi-connection 1147 applications can, however, examine the latched SA parameters of each 1148 connection to ensure that all concurrent connections with the same 1149 end-point addresses also have the same end-point IPsec IDs. 1151 Connection latching protects against TCP RST attacks. It does not 1152 help, however, if the original peer of a TCP connection is no longer 1153 available (e.g., if an attacker has been able to interrupt the 1154 network connection between the two peers). 1156 6.4. Channel Binding and IPsec APIs 1158 IPsec channels are a pre-requisite for channel binding [RFC5056] to 1159 IPsec. Connection latching provides such channels, but the channel 1160 bindings for IPsec channels (latched connections) are not specified 1161 herein -- that is a work in progress 1162 [I-D.williams-ipsec-channel-binding]. 1164 Without IPsec APIs connection latching provides marginal security 1165 benefits over traditional IPsec. Such APIs are not described herein; 1166 see [I-D.ietf-btns-abstract-api]. 1168 7. IANA Considerations 1170 There are not IANA considerations for this document. 1172 8. Acknowledgements 1174 The author thanks Michael Richardson for all his help, as well as 1175 Stephen Kent, Sam Hartman, Bill Sommerfeld, Dan McDonald, Daniel 1176 Migault, and many others who've participated in the BTNS WG or who've 1177 answered questions about IPsec, connection latching implementations, 1178 etc... 1180 9. References 1182 9.1. Normative References 1184 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1185 August 1980. 1187 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1188 RFC 793, September 1981. 1190 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1191 Requirement Levels", BCP 14, RFC 2119, March 1997. 1193 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1194 Internet Protocol", RFC 4301, December 2005. 1196 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1197 RFC 4306, December 2005. 1199 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 1200 RFC 4960, September 2007. 1202 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 1203 Kozuka, "Stream Control Transmission Protocol (SCTP) 1204 Dynamic Address Reconfiguration", RFC 5061, 1205 September 2007. 1207 [RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing 1208 Security: An Unauthenticated Mode of IPsec", RFC 5386, 1209 November 2008. 1211 9.2. Informative References 1213 [I-D.bellovin-useipsec] 1214 Bellovin, S., "Guidelines for Specifying the Use of IPsec 1215 Version 2", draft-bellovin-useipsec-10 (work in progress), 1216 August 2008. 1218 [I-D.dondeti-useipsec-430x] 1219 Dondeti, L. and V. Narayanan, "Guidelines for using IPsec 1220 and IKEv2", draft-dondeti-useipsec-430x-00 (work in 1221 progress), October 2006. 1223 [I-D.ietf-btns-abstract-api] 1224 Richardson, M., "An abstract interface between 1225 applications and IPsec", draft-ietf-btns-abstract-api-02 1226 (work in progress), November 2008. 1228 [I-D.williams-ipsec-channel-binding] 1229 Williams, N., "End-Point Channel Bindings for IPsec Using 1230 IKEv2 and Public Keys", 1231 draft-williams-ipsec-channel-binding-01 (work in 1232 progress), April 2008. 1234 [IP_SEC_OPT.man] 1235 Sun Microsystems, Inc., "Solaris ipsec(7P) manpage", 1236 October 2006. 1238 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1239 STD 13, RFC 1034, November 1987. 1241 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 1242 Channels", RFC 5056, November 2007. 1244 [RFC5387] Touch, J., Black, D., and Y. Wang, "Problem and 1245 Applicability Statement for Better-Than-Nothing Security 1246 (BTNS)", RFC 5387, November 2008. 1248 Author's Address 1250 Nicolas Williams 1251 Sun Microsystems 1252 5300 Riata Trace Ct 1253 Austin, TX 78727 1254 US 1256 Email: Nicolas.Williams@sun.com