idnits 2.17.1 draft-ietf-btns-connection-latching-06.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 821. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 832. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 839. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 845. 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 -- 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 (February 24, 2008) is 5906 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) == 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 4306 (Obsoleted by RFC 5996) == 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-00 Summary: 3 errors (**), 0 flaws (~~), 6 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: August 27, 2008 February 24, 2008 6 IPsec Channels: Connection Latching 7 draft-ietf-btns-connection-latching-06.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 August 27, 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 This can be used to protect applications against accidentally 45 exposing live packet flows to unintended peers, whether as the result 46 of a reconfiguration of IPsec or as the result of using weak peer 47 identity to peer address associations. 49 Weak association of peer ID and peer addresses is at the core of 50 Better Than Nothing Security (BTNS), thus connection latching can add 51 a significant measure of protection to BTNS IPsec nodes. A model of 52 of connection latching is given. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Conventions used in this document . . . . . . . . . . . . . 4 58 2. Connection Latching . . . . . . . . . . . . . . . . . . . . 5 59 2.1. Connection latch state machine . . . . . . . . . . . . . . . 8 60 2.2. Normative Model: ULP interfaces to the key manager . . . . . 9 61 2.3. Informative model: local packet tagging . . . . . . . . . . 13 62 2.4. Non-native mode IPsec . . . . . . . . . . . . . . . . . . . 14 63 2.5. Conflict Resolution . . . . . . . . . . . . . . . . . . . . 15 64 3. Optional protection . . . . . . . . . . . . . . . . . . . . 16 65 4. Simulataneous latch establishment . . . . . . . . . . . . . 17 66 5. Security Considerations . . . . . . . . . . . . . . . . . . 18 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19 68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 70 8.1. Normative References . . . . . . . . . . . . . . . . . . . . 21 71 8.2. Informative References . . . . . . . . . . . . . . . . . . . 21 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . 23 73 Intellectual Property and Copyright Statements . . . . . . . 24 75 1. Introduction 77 IPsec protects packets with little or no regard for stateful packet 78 flows associated with upper layer protocols (ULPs). This exposes 79 applications that rely on IPsec for session protection to risks 80 associated with changing IPsec configurations, configurations that 81 allow multiple peers access to the same addresses, and/or weak 82 association of peer IDs and their addresses. The latter can occur as 83 a result of "wildcard" matching in the IPsec Peer Authorization 84 Database (PAD), particularly when BTNS 85 [I-D.ietf-btns-prob-and-applic] is used. 87 Applications that wish to use IPsec may have to ensure that local 88 policy on the various end-points is configured appropriately 89 [I-D.bellovin-useipsec] [I-D.dondeti-useipsec-430x]. There are no 90 standard Application Programming Interfaces (APIs) to do this -- a 91 major consequence of which, for example, is that applications must 92 still use hostnames (and, e.g., the Domain Name System [RFC1034]) and 93 IP addresses in existing APIs and must depend on an IPsec 94 configuration that they may not be able to verify. In addition to 95 specifying aspects of required SPD configuration, application 96 specifications must also address PAD/SPD configuration to strongly 97 bind individual addresses to individual IPsec identities and 98 credentials (certificates, public keys, ...). 100 IPsec is, then, quite cumbersome for use by applications. To address 101 this we need APIs to IPsec. Not merely APIs for configuring IPsec, 102 but also APIs that are similar to the existing IP APIs (e.g., "BSD 103 sockets"), so that typical applications making use of UDP and TCP can 104 make use of IPsec with minimal changes. 106 This document describes the foundation for IPsec APIs that UDP and 107 TCP applications can use: a way to bind the traffic flows for, e.g., 108 TCP connections to security properties desired by the application. 109 We call these "connection latches" (and, in some contexts, "IPsec 110 channels"). The methods outlined below achieve this by interfacing 111 ULPs and applications to IPsec. 113 If widely adopted, connection latching could make application use of 114 IPsec much simpler, at least for certain classes of applications. 116 Note: the terms "connection latch" and "IPsec channel" are used 117 interchangeably below. The latter term relates to "channel binding" 118 [RFC5056]. Connection latching is suitable for use in channel 119 binding applications, or will be, at any rate, when the channel 120 bindings for IPsec channels are defined (the specification of IPsec 121 channel bindings is out of scope for this document). 123 1.1. Conventions used in this document 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in [RFC2119]. 129 2. Connection Latching 131 An "IPsec channel" is a packet flow associated with a ULP control 132 block, such as a TCP connection, where all the packets are protected 133 by IPsec SAs such that: 135 o the peer's identity is the same for the lifetime of the packet 136 flow 138 o the quality of IPsec protection used for the packet flow's 139 individual packets is the same for all of them for the lifetime of 140 the packet flow 142 An IPsec channel is created when the associated packet flow is 143 created. This can be the result of a local operation (e.g., a 144 connect()) that causes the initial outgoing packet for that flow to 145 be sent, or it can be the result of receiving the first/initiating 146 packet for that flow (e.g., a TCP SYN packet). 148 IPsec channels are created by "latching" various parameters listed 149 below to a ULP connection when the connections are created. The 150 REQUIRED set of parameters bound in IPsec channels is: 152 o Type of protection: confidentiality and/or integrity protection; 154 o Transport mode vs. tunnel mode; 156 o Quality of protection: cryptographic algorithm suites, key 157 lengths, and replay protection; 159 o Peer identity: peers' asserted and authorized IDs, as per the 160 IPsec processing model [RFC4301] and BTNS [I-D.ietf-btns-core]. 162 Additionally, there SHOULD be an optional way for applications to 163 specify the conflict resolution behaviour of an IPsec channel (see 164 description of the SUSPENDED and BROKEN connection latch states in 165 Section 2.1): whether to wait for the conflict to disappear, or 166 whether to break the channel. The default for this option SHOULD be 167 "break the channel", and MAY be configurable through local policy. 169 The SAs that protect an IPsec channel's packets need not be related 170 by anything other than the fact that they must be congruent to the 171 channel (i.e, the SAs' parameters must match those that are latched 172 into the channel). In particular, it is desirable that IPsec 173 channels survive the expiration of IKE_SAs and child SAs -- new ones 174 can be negotiated as necessary without compromising the security 175 guarantees of the channel -- because operational considerations of 176 the various key exchange protocols then cannot affect the design and 177 features of connection latching. 179 Implementations SHOULD provide applications with APIs for inquiring 180 whether a connection is latched and what the latched parameters are. 181 Implementations SHOULD provide applications with some control, 182 through application programming interfaces (APIs) 183 [I-D.ietf-btns-abstract-api], over what quality of protection, or the 184 expected identity of a peer. If an application does not use such 185 interfaces then it will obtain default quality of protection derived 186 from system policy. Implementations MAY create IPsec channels 187 automatically by default when the application does not request an 188 IPsec channel. 190 Requirements and recommendations: 192 o If an IPsec channel is desired then packets for a given connection 193 MUST NOT be sent until the channel is established. 195 o If an IPsec channel is desired then inbound packets for a given 196 connection MUST NOT be accepted until the channel is established. 197 I.e., inbound packets for a given connection arriving prior to the 198 establishment of the corresponding IPsec channel must be dropped 199 or the channel establishment must fail. 201 o Once an IPsec channel is established packets for the latched 202 connection MUST NOT be sent unprotected nor protected by an SA 203 that does not match the latched parameters. 205 o Once an IPsec channel is established packets for the latched 206 connection MUST NOT be accepted unprotected nor protected by an SA 207 that does not match the latched parameters. I.e., such packets 208 either must be dropped or must cause the channel to be terminated 209 and the application to be informed before data from such a packet 210 can be delivered to the application. 212 o Native implementations SHOULD provide programming interfaces for 213 inquiring the values of the parameters latched in a connection. 215 o Implementations that provide such programming interfaces MUST make 216 available to applications all relevant information about a peer's 217 ID, including authentication information. This includes the peer 218 certificate, when one is used, and the trust anchor that it was 219 validated to. 221 o Implementations that provide such programming interfaces SHOULD 222 make available to applications any available NAT-related 223 information about the peer: whether it is behind a NAT and, if it 224 is, the inner and outer tunnel addresses of the peer. 226 o Native implementations SHOULD provide programming interfaces for 227 setting the values of the parameters to be latched in a connection 228 that will be initiated or accepted, but these interfaces MUST 229 limit what values applications may request according to system 230 policy (i.e., the IPsec PAD and SPD) and the application's 231 privilege. 233 (Typical system policy may not allow applications any freedom 234 here. Policy extensions allowing for optional protection are 235 described in Section 3.) 237 o The parameters latched in an IPsec channel MUST remain unchanged 238 once the channel is established. 240 o Timeouts while establishing an SA with parameters that match a 241 those latched into an IPsec channel MUST be treated as packet loss 242 (as happens, for example, when a network partitions); normal ULP 243 and/or application timeout handling and retransmission 244 considerations apply. Failure to establish an appropriate SA for 245 an IPsec channel SHOULD be communicated to the ULP and 246 application, and MAY cause the IPsec channel to be broken (which 247 MUST be communicated to the ULP and application). 249 o Implementations that have a restartable key management process (or 250 "daemon") MUST arrange for existing latched connections to either 251 be broken and disconnected, or for them to survive the restart of 252 key exchange processes. (This is implied by the above 253 requirements.) For example, if such an implementation relies on 254 keeping some aspects of connection latch state in the restartable 255 key management process (e.g., potentially large values, such as 256 BTNS peer IDs), then either such state must be restored on restart 257 of such a process, or outstanding connection latches must be 258 transitioned to the CLOSED state. 260 o Dynamic IPsec policy related to connection latches MUST be torn 261 down when latched connections are torn down, even when the latter 262 is implied, such as at crash/halt/reboot time. 264 We describe two models (one normative) of IPsec channels for native 265 IPsec implementations. Both models should suffice for all-software 266 native implementations of IPsec. One, the other or both models 267 should be workable for most native implementations where part of the 268 IPsec stack is implemented in hardware. The normative model is based 269 on abstract programming interfaces between ULPs and the key 270 management component of IPsec. The second model is based on abstract 271 programming interfaces between ULPs and the IPsec (ESP/AH) layer in 272 the IP stack. 274 The two models given below are not, however, entirely equivalent. 275 One model cannot be implemented with NICs that offload ESP/AH but 276 which do not tag incoming packets passed to the host processor with 277 SA information, nor allow the host processor to so tag outgoing 278 packets. That same model can be extended to support connection 279 latching with unconnected datagram sockets, while the other model 280 cannot be so extended. There may be other minor differences between 281 the two models; rather than seek to prove equivalency for some set of 282 security guarantees we instead choose one model to be the normative 283 one. 285 We also provide a model for non-native implementations, such as bump- 286 in-the-stack (BITS) and SG implementations. The connection latching 287 model for non-native implementations is not full-featured as it 288 depends on estimating packet flow state, which may not always be 289 possible. Nor can non-native IPsec implementations be expected to 290 provide APIs related to connection latching (implementations that do 291 could be said to be native). As such this third model is not 292 suitable for channel binding applications [RFC5056]. 294 2.1. Connection latch state machine 296 Connection latches can exist in any of the following five states: 298 o LISTENER 300 o ESTABLISHED 302 o SUSPENDED (there exist conflicting SAs, waiting for them to expire 303 or be removed) 305 o BROKEN (conflicting SAs were created) 307 o CLOSED (by the ULP, the application or administratively) 309 and always have an associated owner, or holder, such as a ULP 310 transmission control block (TCB). 312 A connection latch can be born in the LISTENER state, which can 313 transition only to the CLOSED state. The LISTENER state corresponds 314 to LISTEN state of TCP sockets and is associated with IP 3-tuples, 315 and can give rise to new connection latches in the ESTABLISHED state. 317 A connection latch can also be born in the ESTABLISHED state, either 318 through the direct initiative of a ULP or when an event occurs that 319 causes a LISTENER latch to create an ESTABLISHED latch. This state 320 represents an active connection latch for a traffic flow's 5-tuple. 321 ESTABLISHED connection latches can transition to the SUSPENDED, 322 BROKEN, and CLOSED states. 324 Connection latches remain in the CLOSED state until their owners are 325 informed except where the ownser caused the transition, in which case 326 this state is fleeting. Transitions to the CLOSED state should 327 typically be initiated by latch owners, but implementations MAY 328 provide administrative interfaces through which to close active 329 latches. 331 Connection latches transition to either the SUSPENDED or BROKEN 332 states, according to application preference (or system policy), when 333 there exist SAs in the SAD whose traffic selectors encompass the 334 5-tuple bound by the latch, and whose peer and/or parameters conflict 335 with those bound by the latch. Transitions to the SUSPENDED always 336 cause the associated owner to be informed. Connection latches in the 337 SUSPENDED state may transition back to ESTABLISHED when the conflict 338 is cleared. Transitions to either state always cause the associated 339 owner to be notified. BROKEN connection latches can only transition 340 to CLOSED, but SUSPENDED latches can transition to either ESTABLISHED 341 or CLOSED (see above). 343 Most state transitions are the result of local actions of the latch 344 owners (ULPs). The only exceptions are: birth into the ESTABLISHED 345 state from a LISTENER latch, transitions to the SUSPENDED and BROKEN 346 states, and administrative transitions to the CLOSED state. 347 (Additionally, see the implementation note about restartable key 348 management processes in Section 2.) 350 The details of the transitions depend on the model of connection 351 latching followed by any given implementation. See the following 352 sections. 354 2.2. Normative Model: ULP interfaces to the key manager 356 This section is NORMATIVE. 358 In this section we describe connection latching in terms of an 359 interface between ULPs and the key manager component of a native 360 IPsec implementation. Abstract interfaces for creating, inquiring 361 about, and releasing IPsec channels are described. 363 This model adds a service to the IPsec key manager (i.e., the 364 component that manages the SAD and interfaces with, or implements, 365 key exchange protocols): management of connection latches. There is 366 also a new IPsec database, the Latch Database (LD), that contains all 367 connection latch objects. 369 The traditional IPsec processing model allows the concurrent 370 existence of SAs with different peers but overlapping traffic 371 selectors. Such behaviour, in this model, directly violates the 372 requirements for connection latching. We address this problem by 373 requiring that connection latches be broken (and holders informed) 374 when such conflicts arise. 376 The ULP interfaces to the IPsec PAD database are as follows: 378 o CREATE_LISTENER_LATCH(3-tuple, [type and quality of protection 379 parameters]) -> latch handle 381 If there is no conflicting connection latch object in the 382 LISTENER state for the given 3-tuple (local address, protocol 383 and local port number), and local policy permits it, then this 384 operation atomically creates a connection latch object in the 385 LISTENER state for the given 3-tuple. 387 When a child SA is negotiated that would match a listener 388 latch's 3-tuple then the key manager SHOULD narrow the child SA 389 so that its local address and port ranges do not include the 390 3-tuple or so that the SA has only one local address and port 391 number: the one from the tuple. 393 When a child SA is created that matches a listener latch's 394 3-tuple, but not any ESTABLISHED connection latch's 5-tuple 395 (local address, remote address, protocol, local port number and 396 remote port number), then the key manager creates a new 397 connection latch object in the ESTABLISHED state. The key 398 manager MUST inform the holder of the listener latch of 399 connection latches created as a result of the listener latch. 401 o CREATE_CONNECTION_LATCH(5-tuple, [type and quality of protection 402 parameters], [peer ID], [local ID]) -> latch handle 404 If no connection latch exists in the ESTABLISHED states with 405 the same 5-tuple, and if there exist no child SAs that match 406 the given 5-tuple, or all such SAs share the same type and 407 quality of protection parameters and the same peer then this 408 operation creates a connection latch object in the ESTABLISHED 409 state for the given 5-tuple. If the caller provided all the 410 optional arguments to this operation then the resulting 411 connection latch can be created in the ESTABLISHED state 412 directly. 414 If there exist no child SAs matching the given 5-tuple then the 415 key manager SHOULD try to create a pair of child SAs for that 416 5-tuple. In any case, the key manager can expect that the ULP 417 will send a packet that would trigger the creation of such SAs. 419 When the key manager tries to create child SAs it should narrow 420 the proposals so that their traffic selector match no 421 connection latches in the ESTABLISHED states, or so that they 422 match only the 5-tuple of a single such connection latch. 424 o RELEASE_LATCH(latch object handle) 426 Changes the state of the given connection latch to CLOSED; the 427 connection latch is then deleted. 429 The key manager SHOULD delete any existing child SAs that match 430 the given latch if it had been in the ESTABLISHED states. If 431 the key manager does delete such SAs then it SHOULD inform the 432 peer with an informational Delete payload (see IKEv2 433 [RFC4306]). 435 o INQUIRE_LATCH(latch object handle) -> latch state, latched 436 parameters 438 Returns all available information about the given latch. 440 Needless to say, the LD is updated whenever a connection latch object 441 is created, deleted or broken. 443 The API described above is a new service of the IPsec key manager. 444 In particular the IPsec key manager MUST prevent conflicts amongst 445 latches, and it MUST prevent conflicts between any latch and existing 446 or proposed child SAs as follows: 448 o Non-listener connection latches MUST NOT be created if there exist 449 conflicting SAs in the SAD at the time the connection latch is 450 requested or would be created (from a listener latch). A child SA 451 conflicts with another, in view of a latch, if and only if: a) its 452 traffic selectors and the conflicting SA's match the give latch's, 453 b) its peer, type of protection, or quality of protection 454 parameters differ from the conflicting SA. 456 o Child SA proposals that would conflict with an extant connection 457 latch and whose traffic selectors can be narrowed to avoid the 458 conflict MUST be narrowed (see section 2.9 of [RFC4306]); 460 o Where child SA proposals that would conflict with an extant 461 connection latch cannot be narrowed to avoid the conflict the key 462 manager MUST break the connection latch and inform the holder 463 (i.e., the ULP) prior to accepting the conflicting SAs. 465 Additionally, the key manager MUST protect latched connections 466 against SPD changes that would change the quality of protection 467 afforded to a latched connection's traffic, or which would bypass it. 468 When such a configuration change takes place the key manager MUST 469 either preserve a logical SPD entry such that the latched connection 470 continues to obtain the required protection, or the key manager MUST 471 break the latch and inform the latch holder (ULP) before the change 472 takes place. To do this the key manager can logically update the SPD 473 as if a PROTECT entry had been added at the head of the SPD-S with 474 traffic selectors matching only the latched connection's 5-tuple, and 475 with processing information taken from the actual SPD entry matched 476 by the connection (possibly augmented by the application's request 477 for additional protection). Such updates of the SPD MUST NOT survive 478 system crashes or reboots. 480 ULPs create latched connections by interfacing with IPsec below as 481 follows: 483 o For listening end-points the ULP will request a connection latch 484 listener object for the ULP listener's 3-tuple. Any latching 485 parameters requested by the application should be passed along. 487 o When the ULP receives a packet initiating a connection for a 488 5-tuple matching a 3-tuple listener latch, then the ULP will ask 489 the key manager whether a 5-tuple connection latch was created. 490 If not then the ULP will either reject the new connection or 491 accept it and inform the application that the new connection is 492 not latched (that it does not represent an IPsec channel). 494 o When initiating a connection the ULP will request a connection 495 latch object for the connection's 5-tuple. Any latching 496 parameters requested by the application should be passed along. 497 If no latch can be created then the ULP will either return an 498 error to the application or continue with the new connection and 499 inform the application that the new connection is not latched. 501 o When a latched connection is torn down and no further packets are 502 expected for it then the ULP will request that the connection 503 latch object be destroyed. 505 o When tearing down a listener the ULP will request that the 506 connection latch listener object be destroyed. 508 o When a ULP listener rejects connections the ULP will request the 509 destruction of any connection latch objects that may have been 510 created as a result of the peer's attempt to open the connection. 512 o When the key manager informs a ULP that a connection latch is no 513 longer valid then the ULP SHOULD reset or otherwise terminate the 514 connection and MUST inform the application. 516 The main benefit of this model of connection latching is that it 517 accommodates IPsec implementations where ESP/AH handling is 518 implemented in hardware (for all or a subset of the host's SAD), but 519 where the hardware does not support tagging inbound packets with the 520 indexes of SAD entries corresponding to the SAs that protected them. 522 Note that there is a race condition in this method of connection 523 latching: incoming packets may race with the ULP and the IPsec key 524 manager's manipulation of connection latch objects and SAD entries. 525 As a result ULPs may not be able to trust some packets even though a 526 suitable connection latch object may exist. Implementations MUST 527 prevent such races. One method to prevent these races is to tag 528 packets passed up by the ESP/AH layer with a key manager state 529 version number that is monotonically incremented every time that 530 connection latching state changes; this version number must be 531 incremented atomically relative to the SAD and the LD, including SAD 532 subsets stored on IPsec offload hardware. Other methods may be 533 possible, including dropping packets that arrive within a certain 534 amount of time since the creation/destruction of connection latch 535 objects (e.g., if the maximum latency within the key manager and IP 536 stack is known and guaranteed). 538 2.3. Informative model: local packet tagging 540 In this section we describe connection latching in terms of 541 interfaces between ULPs and IPsec based on tagging packets as they go 542 up and down the IP stack. 544 This section is INFORMATIVE. 546 The ULPs and IPsec interface through a local packet tagging scheme 547 (i.e., the tags don't appear on the wire): 549 o The IPsec layer tags all inbound protected packets addressed to 550 the host with the index of the SAD entry corresponding to the SA 551 that protected the packet. 553 o The IPsec layer understands two types of tags on outbound packets: 555 * a tag specifying a set of latched parameters (peer ID, quality 556 of protection, etc...) that the IPsec layer will use to find or 557 acquire an appropriate SA for protecting the outbound packet 558 (else IPsec will inform the ULP and drop the packet); 560 * a tag requesting feedback about the SA used to protect the 561 outgoing packet, if any. 563 ULPs create latched connections by interfacing with IPsec below as 564 follows: 566 o When the ULP passes a connection's initiating packet to IP the ULP 567 requests feedback about the SA used to protect the outgoing 568 packet, if any, and may specify latching parameters requested by 569 the application. If the packet is protected by IPsec then the ULP 570 records certain parameters of the SA used to protect it in the 571 connection's TCB. 573 o When a ULP receives a connection's initiating packet it processes 574 the IPsec tag of the packet, and it records in the connection's 575 TCB the parameters of the SA that should be latched. 577 Once SA parameters are recorded in a connection's TCB the ULP 578 enforces the connection's latch, or binding, to these parameters as 579 follows: 581 o The ULP processes the IPsec tag of all inbound packets for a given 582 connection and checks that the SAs used to protect input packets 583 match the connection latches recorded in the TCBs. Packets which 584 are not so protected are dropped (this corresponds to 585 transitioning the connection latch to the SUSPENDED state until 586 the next acceptable packet arrives, but in this model this 587 transition is imaginary), or cause the ULP to break the connection 588 latch and inform the application. 590 o The ULP always requests that outgoing packets be protected by SAs 591 that match the latched connection by appropriately tagging 592 outbound packets. 594 The receipt of a packet matching a latched connection's 5-tuple, but 595 protected by an SA with an inappropriate peer, SHOULD be taken as an 596 indication that the original peer is no longer at the original 597 address and that the connection SHOULD be reset, the application 598 informed, and the connection latch removed. 600 This model of connection latching may not be workable with ESP/AH 601 offload hardware that does not support the packet tagging scheme 602 described above. 604 Extending the ULP/IPsec interface to the application should enable 605 applications to use connection-less datagram transports and implement 606 connection latching at the application layer. 608 2.4. Non-native mode IPsec 610 Non-native IPsec implementations, primarily BITS and SG, can 611 implement connection latching too. One major distinction between 612 native IPsec and BITS/BITW/SG IPsec is the lack of APIs for 613 applications at the end-points in the case of the latter. As a 614 result there can be no uses of the latch management interfaces as 615 described in Section 2.2, not at the ULP end-points. Therefore BITS/ 616 BITW/SG implementations must discern ULP connection state from packet 617 inspection (which many firewalls can do) and emulate calls to the key 618 manager accordingly. 620 When a connection latch is broken a BITS/BITW/SG implementation may 621 have to fake a connection reset by sending appropriate packets (e.g., 622 TCP RST packets), for the affected connections. 624 As with all stateful middle-boxes this scheme suffers from the 625 inability of the middle-box to interact with the applications. For 626 example, connection death may be difficult to ascertain. Nor can 627 channel binding applications work with channels maintained by proxy 628 without being able to communicate (securely) about it with the 629 middle-box. 631 2.5. Conflict Resolution 633 Consider a system, say, an IMAP server, with an IPsec policy allowing 634 all peers with certificates issued by some CA to claim any 635 dynamically allocated address in a local network. 637 In such an environment a peer might appear using some address, then 638 disappear (e.g., a laptop whose battery runs out) and another peer 639 might later (after the first peer's DHCP lease expires) appear using 640 the same IP address as the first peer. The first peer might have had 641 a long-lived TCP connection open with the server. The new peer might 642 try to open a connection with the same server and with the same 643 5-tuple as the first peer. The new peer's TCP SYN packet will fail 644 to match the existing connection's latch. 646 In such cases implementations based on Section 2.2 and Section 2.4 647 will be unable to narrow the new peer's child SA proposals to avoid a 648 conflict, and must either reject them (and transition the existing 649 latch to SUSPENDED) or terminate the existing connection latch (i.e., 650 transition it to the BROKEN state). 652 Implementors MUST provide termination of the existing connection as 653 the default behaviour in such cases. Implementors MAY provide a 654 configuration option for selecting the other behaviours. 656 3. Optional protection 658 Given IPsec APIs an application could request that a connection's 659 packets be protected where they would otherwise be bypassed; that is, 660 applications could override BYPASS policy. Locally privileged 661 applications could request that their connections' packets be 662 bypassed rather than protected; that is, privileged applications 663 could override PROTECT policy. We call this "optional protection." 665 Both native IPsec models of connection latching can be extended to 666 support optional protection. With the model described in Section 2.3 667 optional protection comes naturally: the IPsec layer need only check 668 that the protection requested for outbound packets meets or exceeds 669 (as determined by local or system policy) the quality of protection, 670 if any, required by the SPD. Similarly, for the model described in 671 Section 2.2 the check that requested protection meets or exceeds that 672 required by the SPD is performed by the IPsec key manager when 673 creating connection latch and connection latch listener objects. 675 When an application requests, and IPsec permits, either additional 676 protection, or bypassing protection, then the SPD MUST be logically 677 updated such that there exists a suitable SPD entry protecting or 678 bypassing the exact 5-tuple recorded by the corresponding connection 679 latch. Such logical SPD updates MUST be made at connection latch 680 creation time, and MUST be made atomically (see the note about race 681 conditions in Section 2.2). Such updates of the SPD MUST NOT survive 682 system crashes or reboots. 684 4. Simulataneous latch establishment 686 Some connection-oriented ULPs, specifically TCP, support simulaneous 687 connections (where two clients connect to each other, using the same 688 5-tuple, at the same time). Connection latching supports 689 simultaneous latching as well, provided that the key exchange 690 protocol does not make it impossible. 692 Consider two applications doing a simultaneous TCP connect to each 693 other and requesting an IPsec channel. If they request the same 694 connection latching parameters, then the connection and channel 695 should be established as usual. Even if the key exchange protocol in 696 use doesn't support simultaneous IKE_SA and/or child SA 697 establishment, provided one peer's attempt to create the necessary 698 child SAs succeeds then the other peer should be able to notice the 699 new SAs immediately upon failure of its attempts to create the same. 701 If, however, the two peer applications were to request different 702 connection latching parameters, then the connection latch must fail 703 on one end (if the key exchange protocol does not support 704 simultaneous SA creation) or on both ends. 706 5. Security Considerations 708 Connection latching protects only individual connections from weak 709 peer ID<->address binding, IPsec configuration changes, and from 710 configurations that allow multiple peers to assert the same 711 addresses. But connection latching does not ensure that any two 712 connections with the same end-point addresses will have the same 713 latched peer IDs. In other words, applications that use multiple 714 concurrent connections between two given nodes are not protected any 715 more or less by use of IPsec connection latching than by use of IPsec 716 alone. Such multi-connection applications can, however, examine the 717 latched SA parameters of each connection to ensure that all 718 concurrent connections with the same end-point addresses also have 719 the same end-point IPsec IDs. 721 Applications which are sensitive to connection closure, such as the 722 Border Gateway Protocol (BGP), SHOULD set the conflict resolution 723 option for connection latching (e.g., in the case of BGP that option 724 should be set to "wait for the conflict to be resolved"). 726 IPsec channels are a pre-requisite for channel binding [RFC5056] to 727 IPsec. Connection latching provides such channels, but the process 728 of binding IPsec channels (latched connections) to authentication at 729 application layers is not specified herein. 731 Without IPsec APIs connection latching provides marginal security 732 benefits over traditional IPsec. Such APIs are not described herein; 733 see [I-D.ietf-btns-abstract-api]. 735 6. IANA Considerations 737 There are not IANA considerations for this document. 739 7. Acknowledgements 741 The author thanks Michael Richardson for all his help, as well as 742 Stephen Kent, Sam Hartman, Bill Sommerfeld, Dan McDonald, and many 743 others who've participated in the BTNS WG or who've answered 744 questions about IPsec, connection latching implementations, etc... 746 8. References 748 8.1. Normative References 750 [I-D.ietf-btns-core] 751 Williams, N. and M. Richardson, "Better-Than-Nothing- 752 Security: An Unauthenticated Mode of IPsec", 753 draft-ietf-btns-core-06 (work in progress), January 2008. 755 [I-D.ietf-btns-prob-and-applic] 756 Touch, J., Black, D., and Y. Wang, "Problem and 757 Applicability Statement for Better Than Nothing Security 758 (BTNS)", draft-ietf-btns-prob-and-applic-06 (work in 759 progress), October 2007. 761 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 762 Requirement Levels", BCP 14, RFC 2119, March 1997. 764 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 765 Internet Protocol", RFC 4301, December 2005. 767 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 768 RFC 4306, December 2005. 770 8.2. Informative References 772 [I-D.bellovin-useipsec] 773 Bellovin, S., "Guidelines for Mandating the Use of IPsec 774 Version 2", draft-bellovin-useipsec-07 (work in progress), 775 October 2007. 777 [I-D.dondeti-useipsec-430x] 778 Dondeti, L. and V. Narayanan, "Guidelines for using IPsec 779 and IKEv2", draft-dondeti-useipsec-430x-00 (work in 780 progress), October 2006. 782 [I-D.ietf-btns-abstract-api] 783 Richardson, M., "An interface between applications and 784 keying systems", draft-ietf-btns-abstract-api-00 (work in 785 progress), June 2007. 787 [IP_SEC_OPT.man] 788 Sun Microsystems, Inc., "Solaris ipsec(7P) manpage", 789 October 2006. 791 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 792 STD 13, RFC 1034, November 1987. 794 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 795 Channels", RFC 5056, November 2007. 797 Author's Address 799 Nicolas Williams 800 Sun Microsystems 801 5300 Riata Trace Ct 802 Austin, TX 78727 803 US 805 Email: Nicolas.Williams@sun.com 807 Full Copyright Statement 809 Copyright (C) The IETF Trust (2008). 811 This document is subject to the rights, licenses and restrictions 812 contained in BCP 78, and except as set forth therein, the authors 813 retain all their rights. 815 This document and the information contained herein are provided on an 816 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 817 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 818 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 819 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 820 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 821 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 823 Intellectual Property 825 The IETF takes no position regarding the validity or scope of any 826 Intellectual Property Rights or other rights that might be claimed to 827 pertain to the implementation or use of the technology described in 828 this document or the extent to which any license under such rights 829 might or might not be available; nor does it represent that it has 830 made any independent effort to identify any such rights. Information 831 on the procedures with respect to rights in RFC documents can be 832 found in BCP 78 and BCP 79. 834 Copies of IPR disclosures made to the IETF Secretariat and any 835 assurances of licenses to be made available, or the result of an 836 attempt made to obtain a general license or permission for the use of 837 such proprietary rights by implementers or users of this 838 specification can be obtained from the IETF on-line IPR repository at 839 http://www.ietf.org/ipr. 841 The IETF invites any interested party to bring to its attention any 842 copyrights, patents or patent applications, or other proprietary 843 rights that may cover technology that may be required to implement 844 this standard. Please address the information to the IETF at 845 ietf-ipr@ietf.org. 847 Acknowledgment 849 Funding for the RFC Editor function is provided by the IETF 850 Administrative Support Activity (IASA).