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