idnits 2.17.1 draft-haddad-mipshop-optisend-01.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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 506. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 483. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 490. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 496. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (March 6, 2006) is 6625 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) -- Looks like a reference, but probably isn't: '0' on line 240 ** Downref: Normative reference to an Informational RFC: RFC 3792 (ref. 'CGA') -- Possible downref: Normative reference to a draft: ref. 'FMIPv6' == Outdated reference: A later version (-11) exists of draft-ietf-ipv6-2461bis-05 -- Possible downref: Non-RFC (?) normative reference: ref. 'OWHC' Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Haddad 3 Internet-Draft S. Krishnan 4 Expires: September 7, 2006 Ericsson Research 5 J. Choi 6 Samsung AIT 7 March 6, 2006 9 Secure Neighbor Discovery (SEND) Optimization and Adaptation for 10 Mobility: The OptiSEND Protocol 11 draft-haddad-mipshop-optisend-01 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on September 7, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 This memo describes a new set of mechanisms, which aims to increase 45 the Secure Neighbor Discovery (SEND) protocol usability by reducing 46 the required processing power on small devices and adapting it to 47 mobile environment requirements while maintaining its efficiency. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Conventions used in this document . . . . . . . . . . . . . . 3 53 3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 4. Problem and Motivation . . . . . . . . . . . . . . . . . . . . 4 55 5. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 6 56 6. Overview of One-Way Hash Chain . . . . . . . . . . . . . . . . 6 57 7. Overview of OptiSEND . . . . . . . . . . . . . . . . . . . . . 6 58 8. New Options and Messages Formats . . . . . . . . . . . . . . . 9 59 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 60 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 61 11. Normative References . . . . . . . . . . . . . . . . . . . . . 10 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 63 Intellectual Property and Copyright Statements . . . . . . . . . . 13 65 1. Introduction 67 Securing Neighbor Protocol (SEND) has been designed to mitigate 68 potential threats against the IPv6 Neighbor Discovery Protocol (NDP). 69 [SEND] protocol is based uniquely on the Cryptographically Generated 70 Address (CGA). 72 Consequently, SEND relies heavily on using RSA signature, which in 73 turn may severely limit its usability and deployment in the wireless 74 world, due to the fact that the majority of small mobile devices are 75 very limited in terms of processing power and battery consumption. 77 This memo describes a new protocol (OptiSEND), which aims to optimize 78 SEND by reducing the required processing power on small devices and 79 adapting it to mobile environment while maintaining its efficiency. 80 OptiSEND is built on top of the SEND protocol. 82 2. Conventions used in this document 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in [TERM]. 88 3. Glossary 90 Access Router (AR) 92 The Access Router is the mobile node's default router. 94 Oustide Node (ON) 96 An outside node (ON) is a node, which is already attached to the 97 infrastructure via one or many Access Router(s). An ON can be 98 static or mobile. 100 Selected Access Router (sAR) 102 A selected AR is the AR chosen by the MN as the destination node 103 for its RtSol message signed with CGA technology. 105 Soliciting Node (SN) 107 A soliciting node is a node, which has started the procedure to 108 attach itself to the infrastructure by sending a RtSol message 109 signed with CGA technology to a selected AR (sAR). 111 One-Way Chain 113 A one way chain (Vo...Vn) is a collection of values such that each 114 value Vi (except the last value Vn) is a one-way function of the 115 next value Vi+1. In particular, we have Vi = H(Vi+1), for i 116 belonging to [0,n[. For clarity purpose and to avoid confusion, 117 we'll use in the rest of this document the notation V[i] instead 118 of Vi, which means V[i+1] points to Vi+1... 120 Neighbors 122 Nodes attached to the same link. 124 For more details about the one-way chain, please refer to [OWHC]. 126 4. Problem and Motivation 128 SEND protocol has been designed to secure the exchange of the IP 129 address(es) and routing information between different nodes as 130 described in the Neighbor Discovery [ND] and the IPv6 Stateless 131 Address Autoconfiguration [STAT] Protocols. Such exchange is 132 required in two different scenarios. The first one is when a mobile/ 133 static node requests routing, network parameters and IP layer address 134 configuration(s) information from the infrastructure. This is done 135 via sending and/or receiving information from one or many access 136 router(s) (AR). The second scenario occurs when different nodes 137 located on the same link exchange their IP and MAC addresses between 138 themselves. 140 [ND_T] describes different threats, which may appear if/when NDP is 141 applied without any protection (e.g., in a public network). These 142 threats cover both scenarios and may severely disrupt the exchange of 143 information on one particular link, e.g., by launching DoS attacks 144 against one or many nodes. In order to address these issues, SEND 145 relies solely on the Cryptographically Generated Addresses technology 146 (described in [CGA]) to provide a proof of ownership, and 147 consequently to build a form of trust relationship betweeen different 148 nodes. For this purpose, SEND is highly recommended when outside 149 nodes (ONs) are using NDP to talk to the infrastructure and between 150 themselves (i.e., if they are neighbors). 152 When the SEND protocol is used between the nodes and the 153 infrastructure, an AR is expected to use the CGA technology in all 154 messages sent to any node trying to attach itself to the 155 infrastructure. As already mentioned, CGA technology allows the AR 156 to provide a proof of ownership of its claimed IP address(es) and 157 enables the receiving node(s), i.e., ON(s), to validate all 158 information carried in these messages. Note that in this particular 159 scenario, the ON is not required to use SEND when sending a router 160 solicitation (RtSol) message to the AR(s). 161 Similarly, applying SEND protocol between a set of nodes attached to 162 the same AR(s), enables each node and by always relying on the CGA 163 technology, to provide a proof of ownership of its newly configured 164 IP address(es) and to defend its uniqueness on one particular link, 165 during a duplicate address detection (DAD) procedure. 167 However, SEND reliance on the RSA signature (as inherent part of the 168 CGA technology) is raising questions concerning the cost and scale of 169 its usability and deployment. These questions become more pertinent 170 when the mobility aspect is added to the original problem related to 171 limited processing and battery power devices. In fact, each time the 172 MN switches to a new access point (AP), i.e., perform a link layer 173 handoff, it has to check if it is still attached to the 174 infrastructure via the same AR(s) or if it needs to attach to another 175 part or simply a new one. Consequently, a fast moving node will have 176 to dedicate a considerable amount of its power processing cycles to 177 process RSA signatures in order to validate RtAdv messages sent by 178 previous and new AR(s). Similarly, after configuring a new IP 179 address, the mobile node (MN) has to use SEND to exchange NDP 180 messages with other nodes. Note that the presence of at least one 181 malicious node on the same link can strongly and easily contribute in 182 exhausting the processing power of the targeted MN and may add 183 significant delay during handoff procedures. 185 In order to enable seamless mobility while running time sensitive 186 applications, a new protocol Fast Mobile IPv6 ([FMIPv6]), has been 187 standardized and is currently under review. FMIPv6 relies on 188 involving the infrastructure in the handoff process by requiring from 189 the previous AR (pAR) and new AR (nAR) to exchange signaling 190 information upon receiving a trigger message from the MN (i.e., when 191 starting the handoff procedure). Consequently, using RSA signature 192 during this critical phase may add significant delay to the handoff 193 procedure (note that the situation gets quickly worse in the presence 194 of malicious node(s)). 196 The main goal of this document is to provide an alternative solution 197 to the RSA signature, which optimizes the use of SEND by reducing the 198 power processing cost, increasing the scale of deployability and 199 addressing mobility requirements from an early design stage by 200 providing a simple way to forward shared secrets between pAR and 201 nAR(s). However, our current design is limited to the exchange of ND 202 messages between ON and the infrastructure and does not cover yet the 203 exchange of ND messages between neighbors only. Our future work will 204 address these particular scenarios. 206 5. Protocol Requirements 208 OptiSEND does not require major change in the ND protocol. But it 209 requires that all AR(s) rely on the one-way hash chains and shared 210 secrets to authenticate the RtAdv messages. Moreover, OptiSEND 211 requires that ONs authenticate a special set of messages by using a 212 shared secret obtained from using CGA technology when exchanging one 213 particular message with AR. Finally, OptiSEND requires also that ON 214 auto-configures additional IPv6 addresses (if/when needed) by using 215 the shared secret and other parameters to compute the new interface 216 identifier(s) (IID(s)). 218 OptiSEND protocol introduces new messages in addition to the existing 219 set of messages defined in the ND protocol. The new messages are 220 required to distribute identification and security parameters between 221 different ARs. 223 6. Overview of One-Way Hash Chain 225 When the one way function H() is a cryptographic hash function, then 226 the chain is called one-way hash chain (OWHC). For the setup of the 227 one-way hash chain, the generator chooses randomly the root or seed 228 of the chain, i.e., the value V[n] (i.e., Vn), and derives all 229 previous values V[i] by iteratively applying the hash function H(). 230 The value V[0], which is considered the end-value, is normally made 231 public, and potentially linked to the identity of the user processing 232 the corresponding root value. 234 In order to verify a one way hash chain values, we assume that the 235 ONs attached to the infrastructure know an authentic value of the 236 generator's one-way chain (which can be the end-value V[0] or the 237 last "disclosed value" V[d]). To verify an input value V[i] of a 238 hash chain, the verifier iteratively applies the one-way function H() 239 i times and compares the result to the trusted value V[0], i.e., 240 verify that H(V[i]) if applied i times is equal to V[0]. If the 241 computed and known values are equal, then the input value is said to 242 be authentic. Note that if another value V[j], for j < i, is already 243 known, then it suffices to iteratively apply the one-way function 244 some i-k times to the input value, and compare the result to this 245 intermediate value. 247 7. Overview of OptiSEND 249 The main goal behind designing OptiSEND protocol is to eliminate the 250 use of RSA signature whenever possible and/or significantly reduce 251 its use, without amplifying existing threats nor introducing new ones 252 nor reducing the level of security introduced by the SEND protocol. 253 Another important futur goal is to reduce as much as possible the use 254 of any authentication mechanism(s) between an ON and its neighbors. 255 In addition, OptiSEND protocol incorporates a solution, which enables 256 the MN to perform secure and fast mobility. 257 In order to achieve its purposes, OptiSEND protocol addresses 258 separately the issue of an outside node talking to the infrastructure 259 and the one where an ON is talking with its neighbors. The current 260 proposal deals only with the first scenario. 262 For the first case, OptiSEND uses the one way hash chain to allow the 263 AR(s) to authenticate their RtAdv messages. By relying on such 264 technique, OptiSEND enables all ONs attached to the infrastructure to 265 continue validating the RtAdv messages without having to use 266 extensive processing power on validating RSA signature(s). 267 In order to achieve such goal, OptiSEND requires that the ON uses CGA 268 technology to send its first RtSol message only. When a particular 269 AR gets a RtSol message signed with CGA, i.e., thus becoming a 270 selected AR (sAR), it generates a neighbor shared secret (Ks) and 271 sends it to the SN along with the hash of the next value (i.e., yet 272 undisclosed) in its one way chain in a unicast RtAdv message. 273 For clarity purpose, we call the next value to be disclosed in the 274 next multicast RtAdv message V[i+1]. Consequently, the sAR MUST send 275 in the unicast RtAdv message Hash(V[i+1]) = V[i] (where V[i] is the 276 last disclosed value). 277 The goal behind inserting the hash of the next one way hash chain 278 value in the unicast RtAdv message sent to an SN is to enable it to 279 hook itself to the different one-way hash chains used by ARs thus 280 enabling it to follow and authenticate new values sent by different 281 ARs in subsequent multicast RtAdv messages. 282 Note that after sending a RtSol message signed with CGA, the SN may 283 receive more than one RtAdv message from multiple ARs attached to the 284 same link. However, the SN may also receive RtAdv messages before 285 sending its RtSol message. In the first scenario, and in order to 286 avoid having each AR generating one shared secret and sending it to 287 the node in a unicast RtAdv message, ARs SHOULD be able to select one 288 AR to generate Ks and then distribute it to them along with the SN 289 data. In the latter case, a node SHOULD select one particular AR and 290 sends it a RtSol message signed with CGA. In such case, the selected 291 AR (sAR) will generate the neighbor shared secret (Ks) and sends it 292 to SN in a unicast RtAdv message. 294 The neighbor shared secret MUST be encrypted with the MN's CGA public 295 key and the unicast RtAdv message MUST be signed with CGA. In 296 addition, the sAR MUST insert in the unicast RtAdv message the set of 297 the last disclosed OWHC values used by other ARs attached to the same 298 link. For these purposes, the sAR MUST insert new options in the 299 RtAdv message. 301 After receiving the unicast RtAdv message, the ON decrypts Ks and 302 uses the one-way hash chain to check the authenticity of subsequent 303 multicast RtAdv messages via authenticating the OWHC value carried in 304 the RtAdv message. In fact, each multicast RtAdv message MUST carry 305 one new value from the AR's one-way hash chain. Consequently, upon 306 receiving a multicast RtAdv message, the ON should check first the 307 authenticity of the value carried in the multicast RtAdv message 308 before processing or dropping the message. For this purpose the ON 309 should hash the value carried in the RtAdv message and compares it to 310 the one disclosed in the last RtAdv message received by the ON. Note 311 that in case the ON misses one RtAdv message and before it re-sends a 312 new RtSol message signed with CGA to request a fresh value, it SHOULD 313 hash the value disclosed in the latest RtAdv message a maximum X 314 times and compares each value to the one stored in its cache entry. 315 If after X attempts, the obtained value does not match the stored 316 one, then the ON SHOULD re-send a RtSol message signed with CGA in 317 order to request a new value and re-synchronize itself. The ON 318 SHOULD silently discard any RtAdv message carrying a value, which has 319 already been disclosed in a previous RtAdv message or which is simply 320 not authentic. 321 The ON SHOULD also authenticate any unicast message sent to an AR 322 with its Ks and the AR SHOULD authenticate any unicast message sent 323 to one particular ON with its corresponding Ks. The ON will also use 324 Ks for other purposes, e.g., obtaining new end value(s) for new one- 325 way hash chain(s), generate new 64-bit interface identifiers (IIDs). 326 Another goal is the fast mobility (described below). Other goals 327 will be described in a futur work. Note that the lifetime for Ks is 328 set to 24 hours, after which the ON SHOULD repeat the procedure 329 described above in order to refresh its Ks. 331 Note that when all values of a particular OWHC have been disclosed, 332 the corresponding AR can signal to its visitors (i.e., ONs) the 333 availability of a new OWHC by sending a multicast RtAdv message 334 signed with CGA and without any value. Upon receiving such message, 335 each ON SHOULD send a unicast RtSol message to the AR to request one 336 value (e.g., the end value) in order to hook itself to the new OWHC. 337 Note that the ON MUST authenticate the unicast RtSol message with its 338 Ks. 339 When an AR receives a RtSol message signed with one Ks, it MUST send 340 back a unicast RtAdv message, which carries the last disclosed value 341 (Vi) of its OWHC. The sAR MUST encrypt Vi and authenticate the RtAdv 342 message. 344 In parallel to sending a unicast RtAdv message to the SN, the sAR 345 MUST update all other ARs attached to the same link with the new ON 346 parameters, which MUST include its MAC address, the shared secret 347 (Ks), the IPv6 64-bit interface identifier (IID) and its lifetime. 348 For this purpose, the sAR SHOULD send a multicast Binding 349 Advertisement (BdAdv) message to the ARs to request creating a 350 visitor cache entry (VCE) for the new ON. Upon receiving a BdAdv 351 message, each AR checks its VCE for an existing entry, which contains 352 the corresponding ON's MAC address(es). If a VCE exists, then the AR 353 updates it with the new Ks and its lifetime. Otherwise, the AR 354 SHOULD create a new one. Note that the BdAdv message MUST be 355 encrypted with the AR's CGA private key. 357 For the fast mobility, e.g., [FMIPv6] protocol, OptiSEND protocol 358 delegates additional responsibilities to the infrastructure in order 359 to address security requirements related to FMIPv6. For this 360 purpose, OptiSEND enables the infrastructure to provide security 361 assistance to the MN when switching to a new AR by enabling the 362 infrastructure to seamlessly forward security credentials to new 363 AR(s), in parallel with the moving node, thus enabling the MN to keep 364 authenticating its mobility signaling messages with the same key as 365 long as such key remains valid. In the FMIPv6 scenario, this is 366 achieved by allowing the previous AR (pAR) to send the MN's Ks, MAC 367 address and other parameters to the new Access Router (nAR), upon 368 receiving a hint from the MN, e.g., a Fast Binding Update (FBU) 369 message signaling an imminent handoff. The pAR may also send a 370 multicast BdAdv message to nAR(s) without waiting for such hint to be 371 send by the MN, e.g., case of network triggered handover. By 372 seamlessly forwarding Ks to new AR(s), the MN will be able to secure 373 its critical mobility signaling messages by using the same key. 374 Moreover, using symetric cryptography allows the MN to keep using 375 FMIPv6 procedure even if the nAR/pAR does not recognize the identity 376 of one particular AP, e.g., case of a malicious AP(s). 378 8. New Options and Messages Formats 380 TBD 382 9. Security Considerations 384 This memo introduces a new protocol, which is built on top of SEND. 385 There are two main goals behind the OptiSEND design. The first one 386 is to alleviate the processing power required to validate RSA 387 signature without amplifying existing threats nor adding new ones. 388 The second goal is to widen the usability scope to include other 389 features, which impact the neighbor discovery and the fast mobility 390 protocols by fully exploiting the form of trust built between the 391 infrastructure and the ON upon attaching to the sAR. 393 To achieve the first goal, OptiSEND protocol is built on the 394 fundamental assumption that when an operator cares about providing 395 both secure access and secure fast mobility, then the operator's 396 infrastructure itself should be already secure. This means that it 397 is assumed in this memo that all links between AR(s) are secure and 398 all links between AR(s) and AP(s) are secure. Consequently, the 399 vulnerability to man-in-the-middle attacks is eliminated or 400 significantly reduced since using man-in-the middle rogue AP(s) must 401 not be possible. 403 The second goal is achieved as a direct result from the first one as 404 long as the foreign infrastructure(s) remains secure. In such case, 405 OptiSEND does not introduce nor amplify new/existing threats. 407 10. Acknowledgments 409 Authors would like to thank Pekka Nikander for his valuable input at 410 the early stage of this work. 412 11. Normative References 414 [CGA] Aura, T., "Cryptographically Generated Addresses (CGA)", 415 RFC 3792, March 2005. 417 [FMIPv6] Koodli, R., "Fast Handovers for Mobile IPv6", Internet 418 Draft, draft-koodli-mipshop-rfc4068bis-00.txt, 419 October 2005. 421 [ND] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 422 "Neighbor Discovery for IP Version 6 (IPv6)", Internet 423 Draft, draft-ietf-ipv6-2461bis-05.txt, October 2005. 425 [ND_T] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 426 Discovery (ND) Trust Model and Threats", RFC 3756, 427 May 2004. 429 [OWHC] Hu, Y., Jakobsson, M., and A. Perrig, "Efficient 430 Constructions for One-Way Hash Chains", ACNS Conference, 431 June 2005. 433 [SEND] Arkko, J., Kempf, J., Sommerfield, B., Zill, B., and P. 434 Nikander, "Secure Neighbor Discovery (SEND)", RFC 3971, 435 March 2005. 437 [STAT] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 438 Address Autoconfiguration", Internet 439 Draft, draft-ietf-ipv6-rfc2462bis-08.txt, May 2005. 441 [TERM] Bradner, S., "Key Words for Use in RFCs to Indicate 442 Requirement Levels", RFC 2119, BCP , March 1997. 444 Authors' Addresses 446 Wassim Haddad 447 Ericsson Research 448 8400 Decarie Blvd. 449 Town of Mount Royal, QC 450 Canada 452 Phone: +1 514 345 7900 #2334 453 Email: Wassim.Haddad@ericsson.com 455 Suresh Krishnan 456 Ericsson Research 457 8400 Decarie Blvd. 458 Town of Mount Royal, QC 459 Canada 461 Phone: +1 514 345 7900 462 Email: Suresh.Krishnan@ericsson.com 464 JinHyeock Choi 465 Samsung AIT 466 Communication & N/W Lab 467 Suwon 440-600 468 P.O. Box 111 469 KOREA 471 Phone: +82 31 280 9233 472 Email: jinchoe@samsung.com 474 Intellectual Property Statement 476 The IETF takes no position regarding the validity or scope of any 477 Intellectual Property Rights or other rights that might be claimed to 478 pertain to the implementation or use of the technology described in 479 this document or the extent to which any license under such rights 480 might or might not be available; nor does it represent that it has 481 made any independent effort to identify any such rights. Information 482 on the procedures with respect to rights in RFC documents can be 483 found in BCP 78 and BCP 79. 485 Copies of IPR disclosures made to the IETF Secretariat and any 486 assurances of licenses to be made available, or the result of an 487 attempt made to obtain a general license or permission for the use of 488 such proprietary rights by implementers or users of this 489 specification can be obtained from the IETF on-line IPR repository at 490 http://www.ietf.org/ipr. 492 The IETF invites any interested party to bring to its attention any 493 copyrights, patents or patent applications, or other proprietary 494 rights that may cover technology that may be required to implement 495 this standard. Please address the information to the IETF at 496 ietf-ipr@ietf.org. 498 Disclaimer of Validity 500 This document and the information contained herein are provided on an 501 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 502 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 503 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 504 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 505 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 506 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 508 Copyright Statement 510 Copyright (C) The Internet Society (2006). This document is subject 511 to the rights, licenses and restrictions contained in BCP 78, and 512 except as set forth therein, the authors retain all their rights. 514 Acknowledgment 516 Funding for the RFC Editor function is currently provided by the 517 Internet Society.