idnits 2.17.1 draft-ietf-netlmm-threats-00.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 527. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 504. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 511. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 517. ** 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 == Line 196 has weird spacing: '...ere, an attac...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 17, 2006) is 6578 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-01) exists of draft-kempf-netlmm-nohost-ps-00 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Kempf 3 Internet-Draft DoCoMo USA Labs 4 Expires: October 19, 2006 C. Vogt 5 Universitaet Karlsruhe (TH) 6 April 17, 2006 8 Security Threats to Network-based Localized Mobility Management 9 draft-ietf-netlmm-threats-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on October 19, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document discusses security threats to NETLMM-based mobility 43 management with a focus on threats on the interface between mobile 44 nodes and access routers. Threats to the NETLMM protocol itself, 45 which runs between the access routers and mobility anchor points, are 46 similar to those faced by other protocols between network entities 47 like routers. These threats are handled in the NETLMM protocol 48 specification. In contrast, threats on the interface between mobile 49 nodes and access routers are different, because the access routers 50 are presenting the NETLMM domain as a single subnet, in order to 51 allow mobile nodes to continue using the same IP address as they move 52 from one access router to another. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. NETLMM Architecture . . . . . . . . . . . . . . . . . . . . . 3 59 3. Outline of Threats . . . . . . . . . . . . . . . . . . . . . . 5 60 4. Threats to IPv6 Address to Mobile Node Identifier Mapping . . 6 61 4.1 Roaming at a Victim's Costs . . . . . . . . . . . . . . . 6 62 4.2 Off-Path Eavesdropping . . . . . . . . . . . . . . . . . . 7 63 4.3 Denial of Service . . . . . . . . . . . . . . . . . . . . 7 64 5. Threats to Access Router Functions . . . . . . . . . . . . . . 8 65 6. Threats to Location Privacy . . . . . . . . . . . . . . . . . 8 66 6.1 Threats from Nodes within the NETLMM Domain . . . . . . . 9 67 6.2 Threats from Nodes At Any Location . . . . . . . . . . . . 10 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 69 8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 11 70 9. Informative References . . . . . . . . . . . . . . . . . . . . 12 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 72 Intellectual Property and Copyright Statements . . . . . . . . 14 74 1. Introduction 76 The NETLMM architecture supports movement of IPv6 mobile nodes within 77 a localized mobility management domain with minimal involvement on 78 the part of the mobile node itself. In contrast to architectures 79 where there is no localized mobility management support or where 80 localized mobility management support is provided by a host-based 81 solution, in the NETLMM architecture, the mobile node is able to keep 82 its IP address constant within the localized mobility management 83 domain as it moves, avoiding the signaling overhead required to 84 change the address. Software specifically for localized mobility 85 management is not required on the mobile node, though software for IP 86 link movement detection may be needed and of course driver software 87 for link layer movement is always required. More on the localized 88 mobility management problem can be found in [3]. 90 In this document, threats to the protocols involved in implementing 91 the NETLMM architecture are discussed. The document focuses on 92 threats on the mobile node to access router interface. Threats to 93 the NETLMM protocol itself, which runs on the access router to 94 mobility anchor point interface are briefly described, but detailed 95 requirements and solutions for security for the NETLMM protocol are 96 handled in the requirements and NETLMM protocol specification 97 documents [1][4]. While a default IP-based protocol for the 98 interface between mobile nodes and access routers has been specified 99 [2], that interface is the focus of this document because the 100 protocol running across it can potentially be completely handled by 101 the wireless link protocol without any IP involvement. This document 102 is intended to provide guidance to developers linking the NETLMM 103 protocol to such wireless link protocols so that they know what the 104 potential security threats are. 106 1.1 Terminology 108 Mobility terminology in this document follows that in [5], with those 109 revisions and additions from [3] and [4]. 111 2. NETLMM Architecture 113 Figure 1 depicts the NETLMM architecture. A mobility anchor point 114 (MAP) manages routing for packets to mobile nodes as they move 115 through the NETLMM domain. The MAP communicates with a collection of 116 access routers (AR_1 through AR_n in Figure 1). Each access router 117 is connected to a collection of wireless access points (AP_1 through 118 AP_m in Figure 1) that provide wireless access links to mobile nodes. 120 The access routers handle routing updates to the MAP when a new 121 mobile node moves onto the IP link controlled by the access router. 122 In order for the mobile node to keep its address constant across the 123 NETLMM domain, the access routers must all advertise the same IPv6 124 subnet prefixes to mobile nodes on their link, and the internal 125 gateway protocol (IGP) used to distribute routes to routers 126 throughout the IGP routing domain must target the MAP as the last hop 127 router for those IPv6 subnet prefixes that span IP links in the 128 NETLMM domain. The MAP tunnels packets to and from the access 129 routers, changing to a new access router when a routing update from a 130 new access router indicates that an mobile node has moved. 132 NETLMM Domain 134 +-------+ 135 | MAP | 136 +-------+ 137 @ @ 138 @ @ 139 @ @ 140 @ AR-MAP @ 141 @ Interface @ 142 @ @ 143 +------+ +------+ 144 | AR_1 | ... | AR_n | 145 +------+ +------+ 146 * * 147 * * MN-AR * 148 * * Interface * 149 * * * 150 * * * 151 * * * 152 /\ /\ /\ 153 / \ ... / \ ... / \ 154 / AP \ / AP \ / AP \ 155 / AP_1 \ / AP_i \ / AP_m \ 156 -------- -------- -------- 158 +--+ +--+ +--+ 159 |MN|----->|MN|----->|MN|-----> 160 +--+ +--+ +--+ 162 Figure 1: Protocol Interfaces in the NETLMM Architecture 164 3. Outline of Threats 166 The threats for the NETLMM architecture break down into two parts: 168 o Threats on the interface between mobile nodes and access routers. 169 o Threats on the interface between the access routers and a MAP. 171 Threats on the interface between mobile nodes and access routers are, 172 in many respects, similar to threats [6] against the IPv6 Neighbor 173 Discovery protocol, except that rather than being confined to a 174 single IP link, the threat potential is distributed across the last 175 hops of the NETLMM domain. The interface between mobile nodes and 176 access routers may run the default IP protocol [2], or it may run a 177 wireless link technology-specific protocol. Threats on this 178 interface are discussed in detail in the following sections. 180 The threats on the interface between access routers and a MAP are of 181 the same nature as the threats that an IGP for routing faces. 182 Specifically, a rogue MAP or a rouge access router can end up 183 injecting incorrect tunnels or host routes for mobile nodes. This 184 may result in traffic being siphoned off, facilitating impersonation 185 of the mobile node or the mobile node's peer, or in traffic being 186 dropped, resulting in a DoS attack on the mobile node. 188 Rouge access routers and MAPs can be handled with the same security 189 measures used by IGPs for standard IP routing. Since these threats 190 are specific to the NETLMM protocol, which runs across the interface 191 between the access routers and a MAP, they are discussed in the 192 NETLMM protocol specification [1]. The document also identifies 193 specific security measures for the NETLMM protocol. 195 Another threat on the interface between access routers and the MAP is 196 DoS against network entities. Here, an attacker manages to obtain a 197 globally routable IP address of an access router, a MAP, or some 198 other network entity, and perpetrates a DoS attack against that IP 199 address. In general, NETLMM-based mobility management is somewhat 200 more resistant to DoS attacks than host-based localized mobility 201 management because nodes within the domain need never obtain a 202 globally routable IP address of any entity within the NETLMM domain. 203 As a consequence, a compromised node cannot pass such an IP address 204 off to an attacker, limiting the ability of an attacker to extract 205 information on the topology of the NETLMM domain. It is still 206 possible for an attacker to perform address scanning if access 207 routers and MAPs have globally routable IP addresses, or for a 208 compromise to happen in another way, but the much larger IPv6 address 209 space makes address scanning considerably more time consuming. 210 Network operators need to take these considerations into account, and 211 ensure that their internal network topologies are sparsely populated. 213 4. Threats to IPv6 Address to Mobile Node Identifier Mapping 215 A mobile node identifies itself to the NETLMM domain based on an 216 identifier that is conceptually independent of its IP and link-layer 217 addresses. For packets to be later recognized as coming from the 218 mobile node, the mobile node's identity is tied to its IP address, or 219 possibly to any other identifier which shows up in the packets (e.g., 220 the link-layer address or an IPsec SPI), during the initial 221 authentication procedure. Without lack of generality, it is assumed 222 in the following that the mobile node's IP address is used for this 223 purpose. 225 Per se, a mapping between the mobile-node identifier and the IP 226 address is insufficient to protect the mobile node against 227 impersonation by a third party. Specifically, the following attacks 228 are conceivable. 230 4.1 Roaming at a Victim's Costs 232 Given that regular IP packets do not carry a signature of the mobile 233 node or a comparable proof of origin, an attacker may trick the 234 NETLMM domain into accepting packets, sent by the attacker from the 235 mobile node's IP address, and charging any forwarding services or 236 other due services to the mobile node's account. This allows the 237 attacker to roam across the entire NETLMM domain and communicate at 238 the mobile node's costs. 240 The attacker not necessarily needs to be a customer of the NETLMM 241 domain since it does not have to authenticate itself to the NETLMM 242 domain. It rather waits for the mobile node to accomplish the 243 authentication procedure. The attacker must also record the mobile 244 node's IP address so that it can later forge packets that appear to 245 be coming from the mobile node. The attack may or may not overlap 246 with a period during which the mobile node itself communicates, and 247 the attacker may or may not be on the same link as the mobile node 248 while the attack proceeds. The duration of the attack depends on how 249 long a refresh interval the NETLMM domain imposes on the mobile 250 node's authentication. 252 This threat can be eliminated if appropriate per-packet 253 authentication is used for packets that the mobile node sends. The 254 packets can be authenticated either on the link layer or on the IP 255 layer, provided that the IP address, based on which the NETLMM domain 256 identifies the packets as coming from the mobile node, is covered by 257 the protection and securely bound to the authentication context. 259 A possible mechanism for link-layer authentication is a combination 260 of IEEE 802.11i technology and a function in the access router that 261 verifies whether or not an inbound packet's IP source address is 262 bound to the link-layer encryption keys. At the IP layer, IPsec AH 263 provides appropriate protection. Note that IPsec ESP is not 264 sufficient as it does not cover a packet's IP header. 266 A related attack shows the importance of a secure binding between a 267 mobile node's IP address and the keys it uses for per-packet 268 authentication: Failure to provide such a binding allows an 269 attacker, who is itself a customer of the NETLMM domain, to 270 authenticate to the NETLMM domain, obtain the keys for per-packet 271 authentication, and then spoof its IP source address to be the 272 address of some third node. The attacker can thus roam and 273 communicate at its victim's costs. 275 4.2 Off-Path Eavesdropping 277 If an attacker can forge a victim's mobile-node identifier or 278 generate packets that appear to originate from the victim, the 279 attacker can siphon off packets meant for the victim and redirect 280 them to its own location. The perpetrator can inspect these packets, 281 effectively waging an "off-path" eavesdropping attack. However, it 282 is impossible for the attacker to forward the packets on to the 283 victim given that the attacker and the victim use the same IP 284 address. The compromised communication session is therefore highly 285 likely to abort before the attack causes significant damage. 287 The described redirection attack resembles a related man-in-the- 288 middle attack identified in [8]. In that attack, the impersonator 289 manages to redirect packets exchanged between a victim and the 290 victim's peer via itself. Packets thus eventually reach their 291 intended destination, although the attacker can eavesdrop on them or 292 modify them on the fly. The triangular routing becomes possible 293 because the attacker uses a different IP address than its victim. 294 The NETLMM architecture mitigates this attack to some extent in that 295 the attacker cannot redirect a third node's packets unless it somehow 296 duplicates that node's IP address. 298 4.3 Denial of Service 300 A similar attack strategy to the one described in Section 4.2 causes 301 denial of service to a victim. Again, the attacker forges the 302 victim's mobile-node identifier or generates packets that appear to 303 originate from the victim, and it thereby redirects the packets meant 304 for the victim to its own location. Any request that the victim 305 sends to nodes located elsewhere than its local link will 306 consequently solicit responses that the NETLMM domain will route to 307 the attacker's location. As a result, the victim is unable to 308 communicate. 310 This attack is limited in that the attacker can only redirect the 311 victim's packets to its own location because it must obtain the 312 victim's IP address. This is a natural limitation of the NETLMM 313 architecture because packets are only forwarded to links where the 314 destination node is known (or believed) to be present. 316 5. Threats to Access Router Functions 318 An attacker that is able to set up a bogus access router can trick 319 mobile nodes into sending their packets to the attacker. The 320 attacker can thus act as an active or passive man in the middle, 321 possibly forwarding the victim's packets to their actual destination 322 via a path outside the NETLMM domain. 324 Return packets sent by the victim's peer are likely to be delivered 325 through the NETLMM domain, however. The attacker may hence not be 326 able to manipulate those packets, although it may still read them. 328 A more sophisticated attacker can impersonate an access router and 329 act as a NAT box at the same time. It tricks a victim into accepting 330 it as its default router and forwards the victim's packets, after 331 manipulation, with an IP source address through which it is itself 332 reachable. Unless the victim's peer expects a particular IP address, 333 it will send any responses "back" to the attacker. The attacker can 334 read and/or manipulate these packets and finally deliver them to the 335 victim. 337 Essentially, a NETLMM domain is subject to attacks against access 338 routers in the same way as any conventional IPv6 domain. These 339 threats are due to vulnerabilities of the IPv6 Neighbor Discovery 340 protocol, and are as such identified in [6]. In particular, 341 impersonating an access router requires the attacker to send spoofed 342 Router Advertisement messages, which can be precluded, or at least 343 mitigated to a reasonable extent, by SeND [7]. 345 6. Threats to Location Privacy 347 The location privacy of mobile nodes may be compromised if their 348 identities can somehow be associated to their IP or MAC addresses. 349 This may happen if mobile-node identifiers can be read from the 350 protocol executed on the interface between mobile nodes and access 351 routers, if the NETLMM protocol run between access routers and the 352 MAP leaks the mobile-node identifiers, or if an attacker manages to 353 steal confidential information from a NETLMM database. Certainly, an 354 attacker may also be able to infer a mobile node's identity from 355 other sources, e.g., from information extracted from application- 356 layer payloads sent or received by the mobile node. But those 357 attacks are not specific to NETLMM and hence outside the scope of 358 this document. 360 Threats to location privacy that are specific to NETLMM can 361 conceptually be separated into threats that emanate from nodes which 362 are themselves within the NETLMM domain and threats that may also 363 come from nodes outside the NETLMM domain. 365 6.1 Threats from Nodes within the NETLMM Domain 367 An attacker within the localized mobility management domain can 368 obtain location information through the usual IPv6 Neighbor Discovery 369 mechanisms. E.g., the attacker can obtain the IP address of a victim 370 within the localized mobility management domain and multicasts a 371 Neighbor Solicitation message to resolve this IP address to the 372 victim's link-layer address. If the attacker receives a Neighbor 373 Advertisement message in response, it knows that the victim is 374 present somewhere in the NETLMM domain. 376 The obtained location information may be more precise depending on 377 how far beyond the local link IPv6 Neighbor Discovery messages are 378 forwarded by the NETLMM routing fabric. In case such messages are 379 kept link-local, the attacker can even conclude from a received 380 Neighbor Advertisement message that the victim is on the same link. 382 Likewise, the attacker can use Duplicate Address Detection to 383 determine whether another node is within the localized mobility 384 management domain or on the local link. The attacker multicasts a 385 Neighbor Solicitation message to the solicited-node multicast address 386 for the victim's address. If a Neighbor Advertisement message 387 returns, the attacker knows that the victim is somewhere in the 388 localized mobility management domain or on the local link, depending 389 on whether or not NETLMM routers forward Duplicate Address Detection 390 signaling. 392 IPv6 Neighbor Discovery messages are normally of link-local scope and 393 as such not forwarded by routers. This is based on the prerequisite 394 that prefix sets of different links are disjunct. However, links 395 within a NETLMM domain all use the same set of prefixes. While this 396 does not necessarily imply that address-resolution messages need to 397 be distributed across an entire NETLMM domain (link-local redirects 398 may also be feasible), it does imply that messages exchanged for the 399 purpose of Duplicate Address Detection would have to. 401 More precise location information can only be acquired from a 402 position where the links incoming to and outgoing from the MAP can be 403 monitored. An attacker in this position can listen to the NETLMM 404 protocol traffic between the MAP and the different access routers and 405 thus derive the link where its victim is currently attached to. The 406 attacker may even be able to reasonably track its victim if it has 407 access to only a subset of the links to and from the MAP. 409 6.2 Threats from Nodes At Any Location 411 Furthermore, a mobile node's presence within the NETLMM domain is 412 also implied by the prefix of its IP source address. Correspondent 413 nodes can identify the NETLMM domain and coarsely localize the mobile 414 node based on this address, as they could do with any other IP node. 416 The NETLMM architecture blurs the resolution of such location 417 information to some extent in that the IP source address does not 418 contain information about the link within the NETLMM domain where the 419 mobile node currently is. Tracing tools such as "traceroute" may 420 allow the correspondent node (or any other node with the mobile 421 node's IP address) to obtain the IP addresses of some routers on the 422 path to the mobile node. But since packets are tunneled on the sub- 423 path between the MAP and the mobile node's current access router, the 424 acquired information may not be sufficient to actually locate the 425 mobile node. 427 The location tracker does not necessarily have to be a correspondent 428 node of its victim. The attacker may also be another node, both 429 outside and within the NETLMM domain, provided that it has somehow 430 obtained the victim's IP address. 432 This threat can be eliminated by filtering tracing attempts at the 433 NETLMM domain gateways. 435 7. Security Considerations 437 This document deals with the security of the NETLMM architecture. 439 8. Acknowledgment 441 The authors would like to thank Phil Roberts for his comments and 442 suggestions regarding the initial version of this document. 444 9. Informative References 446 [1] "NETLMM Protocol Specification (TBD)", IETF Working Group Item 447 (work in progress). 449 [2] "NETLMM Mobile-Node Access-Router Protocol Specification (TBD)", 450 IETF Working Group Item (work in progress). 452 [3] Kempf, J., "Problem Statement for IP Local Mobility", 453 IETF Internet Draft draft-kempf-netlmm-nohost-ps-00.txt (work in 454 progress), June 2005. 456 [4] Kempf, J., "Requirements and Gap Analysis for IP Local 457 Mobility", IETF Internet Draft 458 draft-kempf-netlmm-nohost-req-00.txt (work in progress), 459 July 2005. 461 [5] Manner, J. and M. Kojo, "Mobility Related Terminology", 462 IETF Request for Comments 3753, June 2004. 464 [6] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 465 Discovery (ND) Trust Models and Threats", IETF Request for 466 Comments 3756, May 2004. 468 [7] Aura, T., "Cryptographically Generated Addresses (CGA)", 469 IETF Request for Comments 3972, March 2005. 471 [8] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. 472 Nordmark, "Mobile IP Version 6 Route Optimization Security 473 Design Background", IETF Request for Comments 4225, 474 December 2005. 476 Authors' Addresses 478 James Kempf 479 DoCoMo USA Labs 480 181 Metro Drive, Suite 300 481 San Jose, CA 95110 482 USA 484 Phone: +1 408 451 4711 485 Email: kempf@docomolabs-usa.com 486 Christian Vogt 487 Institute of Telematics 488 Universitaet Karlsruhe (TH) 489 P.O. Box 6980 490 76128 Karlsruhe 491 Germany 493 Email: chvogt@tm.uka.de 495 Intellectual Property Statement 497 The IETF takes no position regarding the validity or scope of any 498 Intellectual Property Rights or other rights that might be claimed to 499 pertain to the implementation or use of the technology described in 500 this document or the extent to which any license under such rights 501 might or might not be available; nor does it represent that it has 502 made any independent effort to identify any such rights. Information 503 on the procedures with respect to rights in RFC documents can be 504 found in BCP 78 and BCP 79. 506 Copies of IPR disclosures made to the IETF Secretariat and any 507 assurances of licenses to be made available, or the result of an 508 attempt made to obtain a general license or permission for the use of 509 such proprietary rights by implementers or users of this 510 specification can be obtained from the IETF on-line IPR repository at 511 http://www.ietf.org/ipr. 513 The IETF invites any interested party to bring to its attention any 514 copyrights, patents or patent applications, or other proprietary 515 rights that may cover technology that may be required to implement 516 this standard. Please address the information to the IETF at 517 ietf-ipr@ietf.org. 519 Disclaimer of Validity 521 This document and the information contained herein are provided on an 522 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 523 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 524 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 525 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 526 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 527 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 529 Copyright Statement 531 Copyright (C) The Internet Society (2006). This document is subject 532 to the rights, licenses and restrictions contained in BCP 78, and 533 except as set forth therein, the authors retain all their rights. 535 Acknowledgment 537 Funding for the RFC Editor function is currently provided by the 538 Internet Society.