idnits 2.17.1 draft-ietf-btns-connection-latching-02.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 550. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 561. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 568. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 574. 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 (September 12, 2007) is 6064 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: 'RFC4306' is defined on line 507, but no explicit reference was found in the text == Unused Reference: 'RFC4322' is defined on line 510, but no explicit reference was found in the text == Unused Reference: 'I-D.bellovin-useipsec' is defined on line 516, 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) ** Downref: Normative reference to an Informational RFC: RFC 4322 == Outdated reference: A later version (-10) exists of draft-bellovin-useipsec-06 Summary: 5 errors (**), 0 flaws (~~), 9 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: March 15, 2008 September 12, 2007 6 IPsec Channels: Connection Latching 7 draft-ietf-btns-connection-latching-02.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 March 15, 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 based on a modification to the child SA 53 authorization process is given. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.1. Conventions used in this document . . . . . . . . . . . . . 4 59 2. Connection Latching . . . . . . . . . . . . . . . . . . . . 5 60 2.1. Normative Model: ULP interfaces to the key manager and 61 child SA authorization process extensions . . . . . . . . . 7 62 2.2. Using Intimate Interfaces Between ULPs and IPsec . . . . . . 10 63 2.3. Non-native mode IPsec . . . . . . . . . . . . . . . . . . . 11 64 3. Optional protection . . . . . . . . . . . . . . . . . . . . 12 65 4. Security Considerations . . . . . . . . . . . . . . . . . . 13 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14 67 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 69 7.1. Normative References . . . . . . . . . . . . . . . . . . . . 16 70 7.2. Informative References . . . . . . . . . . . . . . . . . . . 16 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . 17 72 Intellectual Property and Copyright Statements . . . . . . . 18 74 1. Introduction 76 IPsec protects packets with little or no regard for stateful packet 77 flows associated with upper layer protocols (ULPs). This exposes 78 applications that rely on IPsec for session protection to risks 79 associated with changing IPsec configurations, configurations that 80 allow multiple peers access to the same addresses, and/or weak 81 association of peer IDs and their addresses. The latter can occur as 82 a result of "wildcard" matching in the IPsec Peer Authorization 83 Database (PAD), particularly when BTNS 84 [I-D.ietf-btns-prob-and-applic] is used. 86 A method is desired for creating "IPsec channels," that is, packet 87 flows predictably protected for their duration, even in the face of 88 IPsec reconfiguration or weak association of peer IDs and addresses. 89 The methods outlined below achieve this by interfacing ULPs and 90 applications to IPsec and using these interfaces to bind ("latch") 91 connections to peer IDs and SA parameters. 93 1.1. Conventions used in this document 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119]. 99 2. Connection Latching 101 An "IPsec channel" is a packet flow associated with a ULP control 102 block, such as a TCP connection, where all the packets are protected 103 by IPsec SAs such that: 105 o the peer's identity is the same for the lifetime of the packet 106 flow 108 o the quality of IPsec protection used for the packet flow's 109 individual packets is the same for all of them for the lifetime of 110 the packet flow 112 An IPsec channel is created when the associated packet flow is 113 created. This can be the result of a local operation (e.g., a 114 connect()) that causes the initial outgoing packet for that flow to 115 be sent, or it can be the result of receiving the first/initiating 116 packet for that flow (e.g., a TCP SYN packet). 118 IPsec channels are created by "latching" various parameters listed 119 below to a ULP connection when the connections are created. The 120 REQUIRED set of parameters bound in IPsec channels is: 122 o Type of protection: confidentiality and/or integrity protection; 124 o Transport mode vs. tunnel mode; 126 o Quality of protection: cryptographic algorithm suites, key 127 lengths, and replay protection; 129 o Peer identity: peers' asserted and authorized IDs, as per the 130 IPsec processing model [RFC4301] and BTNS [I-D.ietf-btns-core]. 132 Implementations SHOULD provide applications with APIs for inquiring 133 whether a connection is latched and what the latched parameters are. 134 Implementations SHOULD provide applications with some control, 135 through application programming interfaces (APIs) 136 [I-D.ietf-btns-abstract-api], over what quality of protection, or the 137 expected identity of a peer. If an application does not use such 138 interfaces then it will obtain default quality of protection derived 139 from system policy. Implementations MAY create IPsec channels 140 automatically by default when the application does not request an 141 IPsec channel. 143 IPsec channels have the following states: 145 o Listener 146 o Larval (in the process of being established) 148 o Established 150 o Failed 152 Requirements and recommendations: 154 o If an IPsec channel is desired then packets for a given connection 155 MUST NOT be sent until the channel is established. 157 o If an IPsec channel is desired then inbound packets for a given 158 connection MUST NOT be accepted (they must be dropped) until the 159 channel is established. 161 o Once an IPsec channel is established packets for the latched 162 connection MUST NOT be sent unprotected nor protected by an SA 163 that does not match the latched parameters. 165 o Once an IPsec channel is established packets for the latched 166 connection MUST NOT be accepted unprotected nor protected by an SA 167 that does not match the latched parameters (i.e., such packets 168 must be dropped). 170 o Native implementations SHOULD provide programming interfaces for 171 inquiring the values of the parameters latched in a connection. 173 o Implementations that provide such programming interfaces MUST make 174 available to applications all relevant information about a peer's 175 ID, including authentication information. This includes the peer 176 certificate, when one is used, and the trust anchor that it was 177 validated to. 179 o Implementations that provide such programming interfaces MUST make 180 available to applications NAT-related information about the peer: 181 whether it is behind a NAT and, if it is, the inner and outer 182 tunnel addresses of the peer. 184 o Native implementations SHOULD provide programming interfaces for 185 setting the values of the parameters to be latched in a connection 186 that will be initiated or accepted, but these interfaces MUST 187 limit what values applications may request according to system 188 policy (i.e., the IPsec PAD and SPD) and the application's 189 privilege. 191 (Typical system policy may not allow applications any freedom 192 here. Policy extensions allowing for optional protection are 193 described in Section 3.) 195 o The parameters latched in an IPsec channel MUST remain unchanged 196 once the channel is established. 198 o Timeouts while establishing an SA with parameters that match a 199 those latched into an IPsec channel MUST be treated as packet loss 200 (as happens, for example, when a network partitions); normal ULP 201 and/or application timeout handling and retransmission 202 considerations apply. Failure to establish an appropriate SA for 203 an IPsec channel MAY be communicated to the ULP and application 204 (e.g., as though the connection had been reset) 206 o Implementations that have a restartable key management process (or 207 "daemon") MUST arrange for existing latched connections to either 208 be reset and disconnected, or for them to survive the restart of 209 key exchange processes. (This is implied by the above 210 requirements.) 212 o Any IPsec channel created with a given peer while another 213 distinct, established IPsec channel exists with the same source 214 and destination addresses SHOULD be bound to the same peer. 216 We describe two models (one normative) of IPsec channels for native 217 IPsec implementations. Both models should suffice for all-software 218 native implementations of IPsec. One the other or both models should 219 be workable for most native implementations where part of the IPsec 220 stack is implemented in hardware. The normative model is based on 221 abstract programming interfaces between ULPs and the key management 222 component of IPsec, plus a modification to the child SA authorization 223 process. The second model is based on abstract programming 224 interfaces between ULPs and the ESP/AH layer in the IP stack. Both 225 models imply extensions to any PF_KEY-like protocols [RFC2367] that 226 may be used internally by the implementation. 228 We also provide a model for non-native implementations, such as bump- 229 in-the-stack (BITS) and SG implementations. The connection latching 230 model for non-native implementations is not full-featured as it 231 depends on estimating packet flow state, which may not always be 232 possible. Nor can non-native IPsec implementations be expected to 233 provide APIs related to connection latching. As such this third 234 model is not suitable for channel binding applications 235 [I-D.williams-on-channel-binding]. 237 2.1. Normative Model: ULP interfaces to the key manager and child SA 238 authorization process extensions 240 This section is NORMATIVE. 242 In this section we describe connection latching in terms of an 243 interface between ULPs and the key manager component of a native 244 IPsec implementation. Abstract interfaces for creating, inquiring 245 about, and releasing IPsec channels are described. 247 This model requires an extension to the IPsec child SA authorization 248 process such that no SAs conflicting with a connection latch are 249 allowed. Normally the IPsec processing model does allow SAs with 250 different peers but overlapping traffic selectors -- behaviour that, 251 in this model, directly violates the requirements for connection 252 latching. 254 The ULP interfaces to the IPsec PAD database are as follows: 256 o Create a connection latch listener object for a ULP 3-tuple (local 257 address, protocol and local port number). This operation succeeds 258 whenever there are no other connection latch listeners for the 259 same 3-tuple. Connection latch listener objects can result in 260 connection latch objects when a child SA is created whose traffic 261 selectors encompass the given 3-tuple. 263 o Create a connection latch object for a ULP 5-tuple (local and 264 remote address, protocol and local and remote port numbers). This 265 operation succeeds when no conflicting connection latch objects 266 exist and when there exist no child SAs encompassing the given 267 5-tuple or when all such SAs are with the same peer and equal 268 quality of protection. 270 o Destroy a connection latch listener object. 272 o Destroy a connection latch object. 274 o Inquire whether a connection latch exists for a given 5-tuple, its 275 state, and its latched parameters. 277 The IPsec processing model is modified as follows: 279 1. The API described above is a new service of the IPsec key 280 manager. In particular the IPsec key manager has to reject new 281 connection latches that conflict with others or with current SAD 282 state. 284 2. At child SA creation time the IPsec key manager MUST reject child 285 SA proposals that would conflict with an established connection 286 latch, or else it MUST narrow such proposed child SAs such that 287 the resulting SAs do not conflict with established connection 288 latches. 290 Implementations SHOULD provide a flag for PAD entries such that PAD 291 entries so flagged will result in the key manager rejecting any 292 connection latch requests with remote addresses which peers matching 293 those PAD entries may assert. This flag makes it possible to 294 preserve traditional IPsec child SA authorization semantics where 295 desired. Alternatively implementations MAY provide a flag to disable 296 or enable connection latching altogether. 298 ULPs create latched connections by interfacing with IPsec below as 299 follows: 301 o For listening end-points the ULP will request a connection latch 302 listener object for the ULP listener's 3-tuple. Any latching 303 parameters requested by the application should be passed along. 305 o When initiating a connection the ULP will request a connection 306 latch object for the connection's 5-tuple. Any latching 307 parameters requested by the application should be passed along. 309 o When a latched connection is torn down and no further packets are 310 expected for it then the ULP will request that the connection 311 latch object be destroyed. 313 o When tearing down a listener the ULP will request that the 314 connection latch listener object be destroyed. 316 o When a ULP listener rejects connections for non-existent 317 connections the ULP will request the destruction of any connection 318 latch objects that may have been created as a result of the peer's 319 attempt to open the connection. 321 The main benefit of this model of connection latching is that it 322 accommodates IPsec implementations where ESP/AH handling is 323 implemented in hardware (for all or a subset of the host's SAD), but 324 where the hardware does not support tagging inbound packets with the 325 SAD entries corresponding to the SAs that protected them. 327 Note that there is a race condition in this method of connection 328 latching: packets may race with the ULP and the IPsec key manager's 329 manipulation of connection latch objects and SAD entries. As a 330 result ULPs may not be able to trust some packets even though a 331 suitable connection latch object may exist. Implementations MUST 332 prevent such races. One method to prevent these races is to tag 333 packets passed up by the ESP/AH layer with a key manager state 334 version number that is monotonically incremented every time that 335 connection latching state changes; this version number must be 336 incremented atomically relative to the SAD, including SAD subsets 337 stored on IPsec offload hardware. Other methods may be possible, 338 including dropping packets that arrive within a certain amount of 339 time since the creation/destruction of connection latch objects 340 (e.g., if the maximum latency within the key manager and IP stack is 341 known and guaranteed). 343 2.2. Using Intimate Interfaces Between ULPs and IPsec 345 In this section we describe connection latching in terms of 346 interfaces between ULPs and IPsec based on tagging packets as they go 347 up and down the IP stack. 349 This section is INFORMATIVE. 351 The ULPs and IPsec interface through a local packet tagging scheme 352 (the tags don't appear on the wire): 354 o The IPsec layer tags all inbound protected packets addressed to 355 the host with the index of the SAD entry corresponding to the SA 356 that protected the packet. 358 o The IPsec layer understands two types of tags on outbound packets: 360 * a tag specifying a set of latched parameters (peer ID, quality 361 of protection, etc...) that the IPsec layer will use to find or 362 acquire an appropriate SA for protecting the outbound packet 363 (else IPsec will drop the packet; 365 * a tag requesting feedback about the SA used to protect the 366 outgoing packet, if any. 368 ULPs create latched connections by interfacing with IPsec below as 369 follows: 371 o When the ULP passes a connection's initiating packet to IP the ULP 372 requests feedback about the SA used to protect the outgoing 373 packet, if any, and may specify latching parameters requested by 374 the application. If the packet is protected by IPsec then the ULP 375 records certain parameters of the SA used to protect it in the 376 connection's transmission control block (TCB). 378 o When a ULP receives a connection's initiating packet it processes 379 the IPsec tag of the packet, and it records in the connection's 380 TCB the parameters of the SA that should be latched. 382 Once SA parameters are recorded in a connection's TCB the ULP 383 enforces the connection's latch, or binding, to these parameters as 384 follows: 386 o The ULP processes the IPsec tag of all inbound packets for a given 387 connection and checks that the SAs used to protect input packets 388 match the connection latches recorded in the TCBs; packets which 389 are not so protected are dropped. 391 o The ULP always requests that outgoing packets be protected by SAs 392 that match the latched connection by appropriately tagging 393 outbound packets. 395 The main benefit of this model of connection latching is its 396 simplicity. For example, no changes need be made to the child SA 397 authorization process. However, this model of connection latching is 398 not workable with ESP/AH offload hardware that does not support the 399 packet tagging scheme described above. 401 2.3. Non-native mode IPsec 403 [Fill this out. Basically, for BITS/BITW/SG implementations 404 connection latching requires inspecting packets to discern ULP 405 connection state, recording such state, and establishing associated 406 connection latches. Like all stateful middle-boxes this suffers from 407 the inability of the middle-box to interact with the applications. 408 For example, connection death may be difficult to ascertain. Nor can 409 channel binding applications work with channels maintained by proxy 410 without being able to communicate (securely) about it with the 411 proxy.] 413 [Sam requested this section offline, and believe we need a PAD entry 414 flag to indicate which PAD entries' addresses (child SA constraints) 415 are subject to connection latching, and which are not. Sam believes 416 this is needed in the native IPsec model based on extending the child 417 SA authorization process; I disagree. -Nico] 419 3. Optional protection 421 Given IPsec APIs an application could request that a connection's 422 packets be protected where they would otherwise be bypassed; that is, 423 applications could override BYPASS policy. Locally privileged 424 applications could request that their connections' packets be 425 bypassed rather than protected; that is, privileged applications 426 could override PROTECT policy. We call this "optional protection." 427 Note that optional protection as described here does not provide a 428 way to override DISCARD policy. 430 Both native IPsec models of connection latching can be extended to 431 support optional protection. With the model described in Section 2.2 432 optional protection comes naturally: the IPsec layer need only check 433 that the protection requested for outbound packets meets or exceeds 434 the quality of protection, if any, required by the SPD. Similarly, 435 for the model described in Section 2.1 the check that requested 436 protection meets or exceeds that required by the SPD is performed by 437 the IPsec key manager when creating connection latch and connection 438 latch listener objects. 440 4. Security Considerations 442 Connection latching protects only individual connections from weak 443 peer ID<->address binding, IPsec configuration changes, and from 444 configurations that allow multiple peers to assert the same 445 addresses, but it does not ensure that any two connections with the 446 same end-point addresses, even if one established while the other is 447 alive, will have the same latched peer IDs. In other words, 448 applications that use multiple concurrent connections between two 449 given nodes are not protected any more or less by use of IPsec 450 connection latching than by use of IPsec alone. Such multi- 451 connection applications can, however, examine the latched SA 452 parameters of each connection to ensure that each every connection 453 with the same end-point addresses also has the same end-point IPsec 454 IDs. 456 IPsec channels are a pre-requisite for channel binding 457 [I-D.williams-on-channel-binding] to IPsec. Connection latching 458 provides such channels, but the process of binding IPsec channels 459 (latched connections) to authentication at application layers is not 460 specified herein. 462 Without IPsec APIs connection latching provides marginal security 463 benefits over traditional IPsec. Such APIs are not described herein; 464 see [I-D.ietf-btns-abstract-api]. 466 5. IANA Considerations 468 There are not IANA considerations for this document. 470 6. Acknowledgements 472 The author thanks Michael Richardson for all his help, as well as 473 Stephen Kent, Sam Hartman, Bill Sommerfeld, Dan McDonald, and many 474 others who've participated in the BTNS WG or who've answered 475 questions about IPsec, connection latching implementations, etc... 477 7. References 479 7.1. Normative References 481 [I-D.ietf-btns-abstract-api] 482 Richardson, M., "An interface between applications and 483 keying systems", draft-ietf-btns-abstract-api-00 (work in 484 progress), June 2007. 486 [I-D.ietf-btns-core] 487 Williams, N. and M. Richardson, "Better-Than-Nothing- 488 Security: An Unauthenticated Mode of IPsec", 489 draft-ietf-btns-core-05 (work in progress), 490 September 2007. 492 [I-D.ietf-btns-prob-and-applic] 493 Touch, J., "Problem and Applicability Statement for Better 494 Than Nothing Security (BTNS)", 495 draft-ietf-btns-prob-and-applic-05 (work in progress), 496 February 2007. 498 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 499 Requirement Levels", BCP 14, RFC 2119, March 1997. 501 [RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key 502 Management API, Version 2", RFC 2367, July 1998. 504 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 505 Internet Protocol", RFC 4301, December 2005. 507 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 508 RFC 4306, December 2005. 510 [RFC4322] Richardson, M. and D. Redelmeier, "Opportunistic 511 Encryption using the Internet Key Exchange (IKE)", 512 RFC 4322, December 2005. 514 7.2. Informative References 516 [I-D.bellovin-useipsec] 517 Bellovin, S., "Guidelines for Mandating the Use of IPsec", 518 draft-bellovin-useipsec-06 (work in progress), 519 February 2007. 521 [I-D.williams-on-channel-binding] 522 Williams, N., "On the Use of Channel Bindings to Secure 523 Channels", draft-williams-on-channel-binding-04 (work in 524 progress), August 2007. 526 Author's Address 528 Nicolas Williams 529 Sun Microsystems 530 5300 Riata Trace Ct 531 Austin, TX 78727 532 US 534 Email: Nicolas.Williams@sun.com 536 Full Copyright Statement 538 Copyright (C) The IETF Trust (2007). 540 This document is subject to the rights, licenses and restrictions 541 contained in BCP 78, and except as set forth therein, the authors 542 retain all their rights. 544 This document and the information contained herein are provided on an 545 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 546 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 547 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 548 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 549 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 550 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 552 Intellectual Property 554 The IETF takes no position regarding the validity or scope of any 555 Intellectual Property Rights or other rights that might be claimed to 556 pertain to the implementation or use of the technology described in 557 this document or the extent to which any license under such rights 558 might or might not be available; nor does it represent that it has 559 made any independent effort to identify any such rights. Information 560 on the procedures with respect to rights in RFC documents can be 561 found in BCP 78 and BCP 79. 563 Copies of IPR disclosures made to the IETF Secretariat and any 564 assurances of licenses to be made available, or the result of an 565 attempt made to obtain a general license or permission for the use of 566 such proprietary rights by implementers or users of this 567 specification can be obtained from the IETF on-line IPR repository at 568 http://www.ietf.org/ipr. 570 The IETF invites any interested party to bring to its attention any 571 copyrights, patents or patent applications, or other proprietary 572 rights that may cover technology that may be required to implement 573 this standard. Please address the information to the IETF at 574 ietf-ipr@ietf.org. 576 Acknowledgment 578 Funding for the RFC Editor function is provided by the IETF 579 Administrative Support Activity (IASA).