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