idnits 2.17.1 draft-ietf-btns-connection-latching-04.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 670. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 681. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 688. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 694. 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 (December 9, 2007) is 5981 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) == Unused Reference: 'I-D.bellovin-useipsec' is defined on line 632, but no explicit reference was found in the text == Unused Reference: 'RFC4322' is defined on line 642, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-ietf-btns-abstract-api-00 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-btns-abstract-api' == Outdated reference: A later version (-07) exists of draft-ietf-btns-core-05 == Outdated reference: A later version (-07) exists of draft-ietf-btns-prob-and-applic-05 ** Downref: Normative reference to an Informational draft: draft-ietf-btns-prob-and-applic (ref. 'I-D.ietf-btns-prob-and-applic') ** Downref: Normative reference to an Informational RFC: RFC 2367 ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) == Outdated reference: A later version (-10) exists of draft-bellovin-useipsec-06 Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 8 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: June 11, 2008 December 9, 2007 6 IPsec Channels: Connection Latching 7 draft-ietf-btns-connection-latching-04.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 June 11, 2008. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2007). 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 . . . . . . . . . . . . . 3 58 2. Connection Latching . . . . . . . . . . . . . . . . . . . . 4 59 2.1. Normative Model: ULP interfaces to the key manager . . . . . 7 60 2.2. Informative model: local packet tagging . . . . . . . . . . 10 61 2.3. Non-native mode IPsec . . . . . . . . . . . . . . . . . . . 12 62 2.4. Conflict Resolution . . . . . . . . . . . . . . . . . . . . 12 63 3. Optional protection . . . . . . . . . . . . . . . . . . . . 14 64 4. Security Considerations . . . . . . . . . . . . . . . . . . 15 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16 66 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 68 7.1. Normative References . . . . . . . . . . . . . . . . . . . . 18 69 7.2. Informative References . . . . . . . . . . . . . . . . . . . 18 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . 19 71 Intellectual Property and Copyright Statements . . . . . . . 20 73 1. Introduction 75 IPsec protects packets with little or no regard for stateful packet 76 flows associated with upper layer protocols (ULPs). This exposes 77 applications that rely on IPsec for session protection to risks 78 associated with changing IPsec configurations, configurations that 79 allow multiple peers access to the same addresses, and/or weak 80 association of peer IDs and their addresses. The latter can occur as 81 a result of "wildcard" matching in the IPsec Peer Authorization 82 Database (PAD), particularly when BTNS 83 [I-D.ietf-btns-prob-and-applic] is used. 85 A method is desired for creating "IPsec channels," that is, packet 86 flows predictably protected for their duration, even in the face of 87 IPsec reconfiguration or weak association of peer IDs and addresses. 88 The methods outlined below achieve this by interfacing ULPs and 89 applications to IPsec and using these interfaces to bind ("latch") 90 connections to peer IDs and SA parameters. 92 1.1. Conventions used in this document 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [RFC2119]. 98 2. Connection Latching 100 An "IPsec channel" is a packet flow associated with a ULP control 101 block, such as a TCP connection, where all the packets are protected 102 by IPsec SAs such that: 104 o the peer's identity is the same for the lifetime of the packet 105 flow 107 o the quality of IPsec protection used for the packet flow's 108 individual packets is the same for all of them for the lifetime of 109 the packet flow 111 An IPsec channel is created when the associated packet flow is 112 created. This can be the result of a local operation (e.g., a 113 connect()) that causes the initial outgoing packet for that flow to 114 be sent, or it can be the result of receiving the first/initiating 115 packet for that flow (e.g., a TCP SYN packet). 117 IPsec channels are created by "latching" various parameters listed 118 below to a ULP connection when the connections are created. The 119 REQUIRED set of parameters bound in IPsec channels is: 121 o Type of protection: confidentiality and/or integrity protection; 123 o Transport mode vs. tunnel mode; 125 o Quality of protection: cryptographic algorithm suites, key 126 lengths, and replay protection; 128 o Peer identity: peers' asserted and authorized IDs, as per the 129 IPsec processing model [RFC4301] and BTNS [I-D.ietf-btns-core]. 131 Implementations SHOULD provide applications with APIs for inquiring 132 whether a connection is latched and what the latched parameters are. 133 Implementations SHOULD provide applications with some control, 134 through application programming interfaces (APIs) 135 [I-D.ietf-btns-abstract-api], over what quality of protection, or the 136 expected identity of a peer. If an application does not use such 137 interfaces then it will obtain default quality of protection derived 138 from system policy. Implementations MAY create IPsec channels 139 automatically by default when the application does not request an 140 IPsec channel. 142 IPsec channels can have the following states: 144 o LISTENER 145 o LARVAL (in the process of being established) 147 o ESTABLISHED 149 o BROKEN 151 o CLOSED 153 and always have an associated owner, or holder, such as a ULP 154 transmission control block (TCB). 156 Requirements and recommendations: 158 o If an IPsec channel is desired then packets for a given connection 159 MUST NOT be sent until the channel is established. 161 o If an IPsec channel is desired then inbound packets for a given 162 connection MUST NOT be accepted (they MUST be dropped) until the 163 channel is established. 165 o Once an IPsec channel is established packets for the latched 166 connection MUST NOT be sent unprotected nor protected by an SA 167 that does not match the latched parameters. 169 o Once an IPsec channel is established packets for the latched 170 connection MUST NOT be accepted unprotected nor protected by an SA 171 that does not match the latched parameters (i.e., such packets 172 MUST be dropped). 174 o Native implementations SHOULD provide programming interfaces for 175 inquiring the values of the parameters latched in a connection. 177 o Implementations that provide such programming interfaces MUST make 178 available to applications all relevant information about a peer's 179 ID, including authentication information. This includes the peer 180 certificate, when one is used, and the trust anchor that it was 181 validated to. 183 o Implementations that provide such programming interfaces SHOULD 184 make available to applications any available NAT-related 185 information about the peer: whether it is behind a NAT and, if it 186 is, the inner and outer tunnel addresses of the peer. 188 o Native implementations SHOULD provide programming interfaces for 189 setting the values of the parameters to be latched in a connection 190 that will be initiated or accepted, but these interfaces MUST 191 limit what values applications may request according to system 192 policy (i.e., the IPsec PAD and SPD) and the application's 193 privilege. 195 (Typical system policy may not allow applications any freedom 196 here. Policy extensions allowing for optional protection are 197 described in Section 3.) 199 o The parameters latched in an IPsec channel MUST remain unchanged 200 once the channel is established. 202 o Timeouts while establishing an SA with parameters that match a 203 those latched into an IPsec channel MUST be treated as packet loss 204 (as happens, for example, when a network partitions); normal ULP 205 and/or application timeout handling and retransmission 206 considerations apply. Failure to establish an appropriate SA for 207 an IPsec channel MAY be communicated to the ULP and application 208 (e.g., as though the connection had been reset) 210 o Implementations that have a restartable key management process (or 211 "daemon") MUST arrange for existing latched connections to either 212 be reset and disconnected, or for them to survive the restart of 213 key exchange processes. (This is implied by the above 214 requirements.) IPsec state related to connection latches MUST be 215 torn down when latched connections are torn down, even when the 216 latter is implied, such as at crash/halt/reboot time. 218 We describe two models (one normative) of IPsec channels for native 219 IPsec implementations. Both models should suffice for all-software 220 native implementations of IPsec. One, the other or both models 221 should be workable for most native implementations where part of the 222 IPsec stack is implemented in hardware. The normative model is based 223 on abstract programming interfaces between ULPs and the key 224 management component of IPsec. The second model is based on abstract 225 programming interfaces between ULPs and the IPsec (ESP/AH) layer in 226 the IP stack. Both models imply extensions to any PF_KEY-like 227 protocols [RFC2367] that may be used internally by the 228 implementation. 230 We also provide a model for non-native implementations, such as bump- 231 in-the-stack (BITS) and SG implementations. The connection latching 232 model for non-native implementations is not full-featured as it 233 depends on estimating packet flow state, which may not always be 234 possible. Nor can non-native IPsec implementations be expected to 235 provide APIs related to connection latching (implementations that do 236 could be said to be native). As such this third model is not 237 suitable for channel binding applications 238 [I-D.williams-on-channel-binding]. 240 2.1. Normative Model: ULP interfaces to the key manager 241 This section is NORMATIVE. 243 In this section we describe connection latching in terms of an 244 interface between ULPs and the key manager component of a native 245 IPsec implementation. Abstract interfaces for creating, inquiring 246 about, and releasing IPsec channels are described. 248 This model adds a service to the IPsec key manager: management of 249 connection latches. There is also a new IPsec database, the Latch 250 Database (LD), that contains all connection latch objects. 252 The traditional IPsec processing model allows the concurrent 253 existence of SAs with different peers but overlapping traffic 254 selectors. Such behaviour, in this model, directly violates the 255 requirements for connection latching. We address this problem by 256 requiring that connection latches be broken (and holders informed) 257 when such conflicts arise. 259 The ULP interfaces to the IPsec PAD database are as follows: 261 o CREATE_LISTENER_LATCH(3-tuple, [type and quality of protection 262 parameters]) -> latch handle 264 If there is no conflicting connection latch object in the 265 LISTENER state for the given 3-tuple (local address, protocol 266 and local port number), and local policy permits it, then this 267 operation atomically creates a connection latch object in the 268 LISTENER state for the given 3-tuple. 270 When a child SA is negotiated that would match a listener 271 latch's 3-tuple then the key manager SHOULD narrow the child SA 272 so that its local address and port ranges do not include the 273 3-tuple or so that the SA has only one local address and port 274 number: the one from the tuple. 276 When a child SA is created that matches a listener latch's 277 3-tuple, but not any ESTABLISHED connection latch's 5-tuple 278 (local address, remote address, protocol, local port number and 279 remote port number), then the key manager creates a new 280 connection latch object in the ESTABLISHED state. The key 281 manager MUST inform the holder of the listener latch of 282 connection latches created as a result of the listener latch. 284 o CREATE_CONNECTION_LATCH(5-tuple, [type and quality of protection 285 parameters], [peer ID], [local ID]) -> latch handle 287 If no connection latch exists in the LARVAL or ESTABLISHED 288 states with the same 5-tuple, and if there exist no child SAs 289 that match the given 5-tuple, or all such SAs share the same 290 type and quality of protection parameters and the same peer 291 then this operation creates a connection latch object in the 292 LARVAL state for the given 5-tuple. If the caller provided all 293 the optional arguments to this operation then the resulting 294 connection latch can be created in the ESTABLISHED state 295 directly. 297 If there exist no child SAs matching the given 5-tuple then the 298 key manager SHOULD try to create a pair of child SAs for that 299 5-tuple. In any case, the key manager can expect that the ULP 300 will send a packet that would trigger the creation of such SAs. 302 When the key manager tries to create child SAs it should narrow 303 the proposals so that their traffic selector match no 304 connection latches in the LARVAL or ESTABLISHED states, or so 305 that they match only the 5-tuple of a single such connection 306 latch. 308 o RELEASE_LATCH(latch object handle) 310 Changes the state of the given connection latch to CLOSED; the 311 connection latch is then deleted. 313 The key manager SHOULD delete any existing child SAs that match 314 the given latch if it had been in the LARVAL or ESTABLISHED 315 states. If the key manager does delete such SAs then it SHOULD 316 inform the peer with an informational Delete payload (see IKEv2 317 [RFC4306]). 319 o INQUIRE_LATCH(latch object handle) -> latch state, latched 320 parameters 322 Returns all available information about the given latch. 324 Needless to say, the LD is updated whenever a connection latch object 325 is created, deleted or broken. 327 The API described above is a new service of the IPsec key manager. 328 In particular the IPsec key manager MUST prevent conflicts amongst 329 latches, and it MUST prevent conflicts between any latch and existing 330 or proposed child SAs as follows: 332 o Non-listener connection latches MUST NOT be created if there exist 333 conflicting SAs in the SAD at the time the connection latch is 334 requested or would be created (from a listener latch). A child SA 335 conflicts with another, in view of a latch, if and only if: a) its 336 traffic selectors and the conflicting SA's match the give latch's, 337 b) its peer, type of protection, or quality of protection 338 parameters differ from the conflicting SA. 340 o Child SA proposals that would conflict with an extant connection 341 latch and whose traffic selectors can be narrowed to avoid the 342 conflict MUST be narrowed (see section 2.9 of [RFC4306]); 344 o Where child SA proposals that would conflict with an extant 345 connection latch cannot be narrowed to avoid the conflict the key 346 manager MUST break the connection latch and inform the holder (the 347 ULP) prior to accepting the conflicting SAs. 349 Additionally, the key manager MUST protect latched connections 350 against SPD changes that would change the quality of protection 351 afforded to a latched connection's traffic, or which would bypass it. 352 When such a configuration change takes place the key manager MUST 353 either preserve a logical SPD entry such that the latched connection 354 continues to obtain the required protection, or the key manager MUST 355 break the latch and inform the latch holder (ULP) before the change 356 takes place. To do this the key manager can logically update the SPD 357 as if a PROTECT entry had been added at the head of the SPD-S with 358 traffic selectors matching only the latched connection's 5-tuple, and 359 with processing information taken from the actual SPD entry matched 360 by the connection (possibly augmented by the application's request 361 for additional protection). Such updates of the SPD MUST NOT survive 362 system crashes or reboots. 364 ULPs create latched connections by interfacing with IPsec below as 365 follows: 367 o For listening end-points the ULP will request a connection latch 368 listener object for the ULP listener's 3-tuple. Any latching 369 parameters requested by the application should be passed along. 371 o When the ULP receives a packet initiating a connection for a 372 5-tuple matching a 3-tuple listener latch, then the ULP will ask 373 the key manager whether a 5-tuple connection latch was created. 374 If not then the ULP will either reject the new connection or 375 accept it and inform the application that the new connection is 376 not latched (that it does not represent an IPsec channel). 378 o When initiating a connection the ULP will request a connection 379 latch object for the connection's 5-tuple. Any latching 380 parameters requested by the application should be passed along. 381 If no latch can be created then the ULP will either return an 382 error to the application or continue with the new connection and 383 inform the application that the new connection is not latched. 385 o When a latched connection is torn down and no further packets are 386 expected for it then the ULP will request that the connection 387 latch object be destroyed. 389 o When tearing down a listener the ULP will request that the 390 connection latch listener object be destroyed. 392 o When a ULP listener rejects connections the ULP will request the 393 destruction of any connection latch objects that may have been 394 created as a result of the peer's attempt to open the connection. 396 o When the key manager informs a ULP that a connection latch is no 397 longer valid then the ULP will reset or otherwise terminate the 398 connection and inform the application. 400 The main benefit of this model of connection latching is that it 401 accommodates IPsec implementations where ESP/AH handling is 402 implemented in hardware (for all or a subset of the host's SAD), but 403 where the hardware does not support tagging inbound packets with the 404 indexes of SAD entries corresponding to the SAs that protected them. 406 Note that there is a race condition in this method of connection 407 latching: incoming packets may race with the ULP and the IPsec key 408 manager's manipulation of connection latch objects and SAD entries. 409 As a result ULPs may not be able to trust some packets even though a 410 suitable connection latch object may exist. Implementations MUST 411 prevent such races. One method to prevent these races is to tag 412 packets passed up by the ESP/AH layer with a key manager state 413 version number that is monotonically incremented every time that 414 connection latching state changes; this version number must be 415 incremented atomically relative to the SAD and the LD, including SAD 416 subsets stored on IPsec offload hardware. Other methods may be 417 possible, including dropping packets that arrive within a certain 418 amount of time since the creation/destruction of connection latch 419 objects (e.g., if the maximum latency within the key manager and IP 420 stack is known and guaranteed). 422 2.2. Informative model: local packet tagging 424 In this section we describe connection latching in terms of 425 interfaces between ULPs and IPsec based on tagging packets as they go 426 up and down the IP stack. 428 This section is INFORMATIVE. 430 The ULPs and IPsec interface through a local packet tagging scheme 431 (the tags don't appear on the wire): 433 o The IPsec layer tags all inbound protected packets addressed to 434 the host with the index of the SAD entry corresponding to the SA 435 that protected the packet. 437 o The IPsec layer understands two types of tags on outbound packets: 439 * a tag specifying a set of latched parameters (peer ID, quality 440 of protection, etc...) that the IPsec layer will use to find or 441 acquire an appropriate SA for protecting the outbound packet 442 (else IPsec will drop the packet; 444 * a tag requesting feedback about the SA used to protect the 445 outgoing packet, if any. 447 ULPs create latched connections by interfacing with IPsec below as 448 follows: 450 o When the ULP passes a connection's initiating packet to IP the ULP 451 requests feedback about the SA used to protect the outgoing 452 packet, if any, and may specify latching parameters requested by 453 the application. If the packet is protected by IPsec then the ULP 454 records certain parameters of the SA used to protect it in the 455 connection's TCB. 457 o When a ULP receives a connection's initiating packet it processes 458 the IPsec tag of the packet, and it records in the connection's 459 TCB the parameters of the SA that should be latched. 461 Once SA parameters are recorded in a connection's TCB the ULP 462 enforces the connection's latch, or binding, to these parameters as 463 follows: 465 o The ULP processes the IPsec tag of all inbound packets for a given 466 connection and checks that the SAs used to protect input packets 467 match the connection latches recorded in the TCBs; packets which 468 are not so protected are dropped. 470 o The ULP always requests that outgoing packets be protected by SAs 471 that match the latched connection by appropriately tagging 472 outbound packets. 474 The receipt of a packet matching a latched connection's 5-tuple, but 475 protected by an SA with an inappropriate peer, should be taken as an 476 indication that the original peer is no longer at the original 477 address and that the connection should be reset, the application 478 informed, and the connection latch removed. 480 This model of connection latching may not be workable with ESP/AH 481 offload hardware that does not support the packet tagging scheme 482 described above. 484 2.3. Non-native mode IPsec 486 Non-native IPsec implementations, primarily BITS and SG, can 487 implement connection latching too. One major distinction between 488 native IPsec and BITS/BITW/SG IPsec is the lack of APIs for 489 applications at the end-points in the case of the latter. As a 490 result there can be no uses of the latch management interfaces as 491 described in Section 2.1, not at the ULP end-points. Therefore BITS/ 492 BITW/SG implementations must discern ULP connection state from packet 493 inspection (which many firewalls can do) and emulate calls to the key 494 manager accordingly. 496 When a connection latch is broken a BITS/BITW/SG implementation may 497 have to fake a connection reset by sending appropriate packets (e.g., 498 TCP RST packets), for the affected connections. 500 As with all stateful middle-boxes this scheme suffers from the 501 inability of the middle-box to interact with the applications. For 502 example, connection death may be difficult to ascertain. Nor can 503 channel binding applications work with channels maintained by proxy 504 without being able to communicate (securely) about it with the 505 middle-box. 507 2.4. Conflict Resolution 509 Consider a system, say, an IMAP server, with an IPsec policy allowing 510 all peers with certificates issued by some CA to claim any 511 dynamically allocated address in a local network. 513 In such an environment a peer might appear using some address, then 514 disappear (e.g., a laptop whose battery runs out) and another peer 515 might later (after the first peer's DHCP lease expires) appear using 516 the same IP address as the first peer. The first peer might have had 517 a long-lived TCP connection open with the server. The new peer might 518 try to open a connection with the same server and with the same 519 5-tuple as the first peer. The new peer's TCP SYN packet will fail 520 to match the existing connection's latch. 522 In such cases implementations based on Section 2.1 and Section 2.3 523 will be unable to narrow the new peer's child SA proposals to avoid a 524 conflict, and must either reject them or terminate the existing 525 connection. Implementations based on Section 2.2 must either drop 526 the new peer's TCP SYN packet, respond with a TCP RST packet, or 527 terminate the existing connection. 529 Implementors MUST provide termination of the existing connection as 530 the default behaviour in such cases. Implementors MAY provide a 531 configuration option for selecting the other behaviours. 533 3. Optional protection 535 Given IPsec APIs an application could request that a connection's 536 packets be protected where they would otherwise be bypassed; that is, 537 applications could override BYPASS policy. Locally privileged 538 applications could request that their connections' packets be 539 bypassed rather than protected; that is, privileged applications 540 could override PROTECT policy. We call this "optional protection." 542 Both native IPsec models of connection latching can be extended to 543 support optional protection. With the model described in Section 2.2 544 optional protection comes naturally: the IPsec layer need only check 545 that the protection requested for outbound packets meets or exceeds 546 the quality of protection, if any, required by the SPD. Similarly, 547 for the model described in Section 2.1 the check that requested 548 protection meets or exceeds that required by the SPD is performed by 549 the IPsec key manager when creating connection latch and connection 550 latch listener objects. 552 When an application requests, and IPsec permits, either additional 553 protection, or bypassing protection, then the SPD MUST be logically 554 updated such that there exists a suitable SPD entry protecting or 555 bypassing the exact 5-tuple recorded by the corresponding connection 556 latch. Such logical SPD updates MUST be made at connection latch 557 creation time, and MUST be made atomically (see the note about race 558 conditions in Section 2.1). Such updates of the SPD MUST NOT survive 559 system crashes or reboots. 561 4. Security Considerations 563 Connection latching protects only individual connections from weak 564 peer ID<->address binding, IPsec configuration changes, and from 565 configurations that allow multiple peers to assert the same 566 addresses. But connection latching does not ensure that any two 567 connections with the same end-point addresses will have the same 568 latched peer IDs. In other words, applications that use multiple 569 concurrent connections between two given nodes are not protected any 570 more or less by use of IPsec connection latching than by use of IPsec 571 alone. Such multi-connection applications can, however, examine the 572 latched SA parameters of each connection to ensure that all 573 concurrent connections with the same end-point addresses also have 574 the same end-point IPsec IDs. 576 IPsec channels are a pre-requisite for channel binding 577 [I-D.williams-on-channel-binding] to IPsec. Connection latching 578 provides such channels, but the process of binding IPsec channels 579 (latched connections) to authentication at application layers is not 580 specified herein. 582 Without IPsec APIs connection latching provides marginal security 583 benefits over traditional IPsec. Such APIs are not described herein; 584 see [I-D.ietf-btns-abstract-api]. 586 5. IANA Considerations 588 There are not IANA considerations for this document. 590 6. Acknowledgements 592 The author thanks Michael Richardson for all his help, as well as 593 Stephen Kent, Sam Hartman, Bill Sommerfeld, Dan McDonald, and many 594 others who've participated in the BTNS WG or who've answered 595 questions about IPsec, connection latching implementations, etc... 597 7. References 599 7.1. Normative References 601 [I-D.ietf-btns-abstract-api] 602 Richardson, M., "An interface between applications and 603 keying systems", draft-ietf-btns-abstract-api-00 (work in 604 progress), June 2007. 606 [I-D.ietf-btns-core] 607 Williams, N. and M. Richardson, "Better-Than-Nothing- 608 Security: An Unauthenticated Mode of IPsec", 609 draft-ietf-btns-core-05 (work in progress), 610 September 2007. 612 [I-D.ietf-btns-prob-and-applic] 613 Touch, J., "Problem and Applicability Statement for Better 614 Than Nothing Security (BTNS)", 615 draft-ietf-btns-prob-and-applic-05 (work in progress), 616 February 2007. 618 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 619 Requirement Levels", BCP 14, RFC 2119, March 1997. 621 [RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key 622 Management API, Version 2", RFC 2367, July 1998. 624 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 625 Internet Protocol", RFC 4301, December 2005. 627 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 628 RFC 4306, December 2005. 630 7.2. Informative References 632 [I-D.bellovin-useipsec] 633 Bellovin, S., "Guidelines for Mandating the Use of IPsec", 634 draft-bellovin-useipsec-06 (work in progress), 635 February 2007. 637 [I-D.williams-on-channel-binding] 638 Williams, N., "On the Use of Channel Bindings to Secure 639 Channels", draft-williams-on-channel-binding-04 (work in 640 progress), August 2007. 642 [RFC4322] Richardson, M. and D. Redelmeier, "Opportunistic 643 Encryption using the Internet Key Exchange (IKE)", 644 RFC 4322, December 2005. 646 Author's Address 648 Nicolas Williams 649 Sun Microsystems 650 5300 Riata Trace Ct 651 Austin, TX 78727 652 US 654 Email: Nicolas.Williams@sun.com 656 Full Copyright Statement 658 Copyright (C) The IETF Trust (2007). 660 This document is subject to the rights, licenses and restrictions 661 contained in BCP 78, and except as set forth therein, the authors 662 retain all their rights. 664 This document and the information contained herein are provided on an 665 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 666 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 667 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 668 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 669 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 670 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 672 Intellectual Property 674 The IETF takes no position regarding the validity or scope of any 675 Intellectual Property Rights or other rights that might be claimed to 676 pertain to the implementation or use of the technology described in 677 this document or the extent to which any license under such rights 678 might or might not be available; nor does it represent that it has 679 made any independent effort to identify any such rights. Information 680 on the procedures with respect to rights in RFC documents can be 681 found in BCP 78 and BCP 79. 683 Copies of IPR disclosures made to the IETF Secretariat and any 684 assurances of licenses to be made available, or the result of an 685 attempt made to obtain a general license or permission for the use of 686 such proprietary rights by implementers or users of this 687 specification can be obtained from the IETF on-line IPR repository at 688 http://www.ietf.org/ipr. 690 The IETF invites any interested party to bring to its attention any 691 copyrights, patents or patent applications, or other proprietary 692 rights that may cover technology that may be required to implement 693 this standard. Please address the information to the IETF at 694 ietf-ipr@ietf.org. 696 Acknowledgment 698 Funding for the RFC Editor function is provided by the IETF 699 Administrative Support Activity (IASA).