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