idnits 2.17.1 draft-ietf-send-psreq-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 418: '...ance optimization, and a SHOULD in the...' 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 (April 14, 2003) is 7683 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: '1' is defined on line 965, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 977, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 988, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2284 (ref. '1') (Obsoleted by RFC 3748) -- Obsolete informational reference (is this intentional?): RFC 2402 (ref. '2') (Obsoleted by RFC 4302, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2461 (ref. '3') (Obsoleted by RFC 4861) -- Obsolete informational reference (is this intentional?): RFC 2462 (ref. '4') (Obsoleted by RFC 4862) -- Obsolete informational reference (is this intentional?): RFC 2472 (ref. '5') (Obsoleted by RFC 5072, RFC 5172) == Outdated reference: A later version (-02) exists of draft-arkko-icmpv6-ike-effects-01 == Outdated reference: A later version (-02) exists of draft-arkko-manual-icmpv6-sas-01 Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Secure Neighbor Discovery Working P. Nikander (editor) 3 Group Ericsson Research Nomadic Lab 4 Internet-Draft J. Kempf 5 Expires: October 13, 2003 DoCoMo USA Labs 6 E. Nordmark 7 Sun Microsystems Laboratories 8 April 14, 2003 10 IPv6 Neighbor Discovery trust models and threats 11 draft-ietf-send-psreq-03 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at http:// 28 www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on October 13, 2003. 35 Copyright Notice 37 Copyright (C) The Internet Society (2003). All Rights Reserved. 39 Abstract 41 The existing IETF standards specify that IPv6 Neighbor Discovery and 42 Address Autoconfiguration mechanisms may be protected with IPsec AH. 43 However, the current specifications limit the security solutions to 44 manual keying due to practical problems faced with automatic key 45 management. This document specifies three different trust models and 46 discusses the threats pertinent to IPv6 Neighbor Discovery. The 47 purpose of this discussion is to define the requirements for Securing 48 IPv6 Neighbor Discovery. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1 Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Previous Work . . . . . . . . . . . . . . . . . . . . . . . 5 55 3. Trust models . . . . . . . . . . . . . . . . . . . . . . . . 6 56 3.1 Corporate Intranet Model . . . . . . . . . . . . . . . . . . 6 57 3.2 Public Wireless Network with an Operator . . . . . . . . . . 8 58 3.3 Ad Hoc Network . . . . . . . . . . . . . . . . . . . . . . . 9 59 4. Threats on a (Public) Multi-Access Link . . . . . . . . . . 10 60 4.1 Non router/routing related threats . . . . . . . . . . . . . 10 61 4.1.1 Neighbor Solicitation/Advertisement Spoofing . . . . . . . . 10 62 4.1.2 Neighbor Unreachability Detection (NUD) failure . . . . . . 12 63 4.1.3 Duplicate Address Detection DoS Attack . . . . . . . . . . . 12 64 4.2 Router/routing involving threats . . . . . . . . . . . . . . 13 65 4.2.1 Malicious Last Hop Router . . . . . . . . . . . . . . . . . 13 66 4.2.2 Default router is 'killed' . . . . . . . . . . . . . . . . . 14 67 4.2.3 Good Router Goes Bad . . . . . . . . . . . . . . . . . . . . 15 68 4.2.4 Spoofed Redirect Message . . . . . . . . . . . . . . . . . . 15 69 4.2.5 Bogus On-Link Prefix . . . . . . . . . . . . . . . . . . . . 16 70 4.2.6 Bogus Address Configuration Prefix . . . . . . . . . . . . . 17 71 4.2.7 Parameter Spoofing . . . . . . . . . . . . . . . . . . . . . 18 72 4.3 Replay attacks and remotely exploitable attacks . . . . . . 19 73 4.3.1 Replay attacks . . . . . . . . . . . . . . . . . . . . . . . 19 74 4.3.2 Neighbor Discovery DoS Attack . . . . . . . . . . . . . . . 19 75 4.4 Summary of the attacks . . . . . . . . . . . . . . . . . . . 20 76 5. Security Considerations . . . . . . . . . . . . . . . . . . 22 77 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 78 References (Informative) . . . . . . . . . . . . . . . . . . 24 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 25 80 A. Changes between versions . . . . . . . . . . . . . . . . . . 26 81 Intellectual Property and Copyright Statements . . . . . . . 28 83 1. Introduction 85 The IPv6 Neighbor Discovery RFC2461 [3] and Address Autoconfiguration 86 RFC2462 [4] mechanisms are used by nodes in an IPv6 network to learn 87 the local topology, including the IP to MAC address mappings for the 88 local nodes, the IP and MAC addresses of the routers present in the 89 local network, and the routing prefixes served by the local routers. 90 The current specifications suggest that IPsec AH RFC2402 [2] may be 91 used to secure the mechanisms, but does not specify how. It appears 92 that using current AH mechanisms is problematic due to key management 93 problems [11]. 95 To solve the problem, the Secure Neighbor Discovery (SEND) working 96 group was chartered in fall 2002. The goal of the working group is 97 to define protocol support for securing IPv6 Neighbor Discovery 98 without requiring excessive manual keying. 100 The purpose of this document is to define the types of networks in 101 which the Secure IPv6 Neighbor Discovery mechanisms are expected to 102 work, and the threats that the security protocol(s) must address. To 103 fulfill this purpose, this document first defines three different 104 trust models, roughly corresponding to secured corporate intranets, 105 public wireless access networks, and pure ad hoc networks. After 106 that, a number of threats are discussed in the light of these trust 107 models. The threat catalog is aimed to be exhaustive, but it is 108 likely that some threats are still missing. Thus, ideas for new 109 threats to consider are solicited. 111 1.1 Remarks 113 Note that the SEND WG charter limits the scope of the working group 114 to secure Neighbor Discovery functions. Furthermore, the charter 115 explicitly mentions zero configuration as a fundamental goal behind 116 Neighbor Discovery. Network access authentication and access control 117 are outside the scope of this work. 119 During the discussions while preparing this document, the following 120 aspects that may help to evaluate the eventual solutions were 121 mentioned. 123 Zero configuration 125 Interaction with access control solutions 127 Scalability 129 Efficiency 131 However, the main evaluation criteria are formed by the trust models 132 and threat lists. In other words, the solutions are primarily 133 evaluated by seeing how well they secure the networks against the 134 identified threats, and only secondarily from the configuration, 135 access control, scalability, and efficiently point of view. 137 IMPORTANT. This document occasionally discusses solution proposals, 138 such as CGA [10] and ABK [9]. However, such discussion is solely for 139 illustrative purposes. Its purpose is to give the readers a more 140 concrete idea of *some* possible solutions. Such discussion does NOT 141 indicate any preference on solutions on the behalf of the authors or 142 the working group. 144 It should be noted that the term "trust" is used in this document in 145 a rather non-technical manner. The most appropriate interpretation 146 is to consider it as an expression of an organizational or collective 147 belief, i.e., an expression of commonly shared beliefs about the 148 future behavior of the other involved parties. Conversely, the term 149 "trust relationship" denotes a mutual a priori relationship between 150 the involved organizations or parties where the parties believe that 151 the other parties will behave correctly even in the future. A trust 152 relationship makes it possible to configure authentication and 153 authorization information between the parties, while the lack of such 154 a relationship makes it impossible to pre-configure such information. 156 2. Previous Work 158 The RFCs that specify the IPv6 Neighbor Discovery and Address 159 Autoconfiguration protocols [3][4] contain the required discussion of 160 security in a Security Considerations section. Some of the threats 161 identified in this document were raised in the original RFCs. The 162 recommended remedy was to secure the involved packets with an IPsec 163 AH [2] header. However, that recommendation oversimplifies the 164 problem by leaving the AH key management for future work. For 165 example, a host attempting to gain access to a Public Access network 166 may or may not have the required IPsec security associations set up 167 with the network. In a roaming (but not necessarily mobile) 168 situation, where a user is currently accessing the network through a 169 service provider different from the home provider, it is not likely 170 that the host will have been preconfigured with the proper mutual 171 trust relationship for the foreign provider's network, allowing it to 172 directly authenticate the network and get itself authenticated. 174 As of today, any IPsec security association between the host and the 175 last hop routers or other hosts on the link would need to be 176 completely manually preconfigured, since the Neighbor Discovery and 177 Address Autoconfiguration protocols deal to some extent with how a 178 host obtains initial access to a link. Thus, if a security 179 association is required for initial access and the host does not have 180 that association, there is currently no standard way that the host 181 can dynamically configure itself with that association, even if it 182 has the necessary minimum prerequisite keying material. This 183 situation could induce administration hardships when events such as 184 re-keying occur. 186 In addition, Neighbor Discovery and Address Autoconfiguration use a 187 few fixed multicast addresses plus a range of 16 million "solicited 188 node" multicast addresses. A naive application of pre-configured SAs 189 would require pre-configuring an unmanageable number of SAs on each 190 host and router just in case a given solicited node multicast address 191 is used. Preconfigured SAs are impractical for securing such a large 192 potential address range. 194 3. Trust models 196 When considering various security solutions for the IPv6 Neighbor 197 Discovery (ND) [3], it is important to keep in mind the underlying 198 trust models. The trust models defined in this section are used 199 later in this document, when discussing specific threats. 201 In the following, the RFC2461/RFC2462 mechanisms are loosely divided 202 into two categories: Neighbor Discovery (ND) and Router Discovery 203 (RD). The former denotes operations that do not primarily involve 204 routers while the operations in the latter category do. 206 Three different trust models are specified: 208 1. A model where all authenticated nodes trust each other to behave 209 correctly at the IP layer and not to send any ND or RD messages 210 that contain false information. This model is thought to 211 represent a situation where the nodes are under a single 212 administration and form a closed or semi-closed group. A 213 corporate intranet is a good example. 215 2. A model where there is a router trusted by the other nodes in the 216 network to be a legitimate router that faithfully routes packets 217 between the local network and any connected external networks. 218 Furthermore, the router is trusted to behave correctly at the IP 219 layer and not to send any ND or RD messages that contain false 220 information. 222 This model is thought to represent a public network run by an 223 operator. The clients pay to the operator, have its credentials, 224 and trust it to provide the IP forwarding service. The clients 225 do not trust each other to behave correctly; any other client 226 node must be considered able to send falsified ND and RD 227 messages. 229 3. A model where the nodes do not directly trust each other at the 230 IP layer. This model is considered suitable for e.g., ad hoc 231 networks. 233 Note that even though the nodes are assumed to trust each other in 234 the first trust model (corporate intranet), it is still desirable to 235 limit the extent of damage a node is able to inflict to the local 236 network if it becomes compromised. 238 3.1 Corporate Intranet Model 240 In a corporate intranet or other network where all nodes are under 241 one administrative domain, the nodes may be considered to be reliable 242 at the IP layer. Thus, once a node has been accepted to be a member 243 of the network, it is assumed to behave in a trustworthy manner. 245 Under this model, if the network is physically secured or if the link 246 layer is cryptographically secured to the extent needed, no other 247 protection is needed for IPv6 ND, as long as none of the nodes become 248 compromised. For example, a wired LAN with 802.1x access control or 249 a WLAN with 802.11i Robust Security Network (RSN) with AES encryption 250 may be considered secure enough, requiring no further protection 251 under this trust model. On the other hand, ND security would add 252 protection depth even under this model (see below). Furthermore, one 253 should not overestimate the level of security any L2 mechanism is 254 able to provide. 256 If the network is not physically secured and the link layer does not 257 have cryptographic protection, or if the cryptographic protection is 258 not secure enough (e.g., just 802.1x and not 802.11i in a WLAN), the 259 nodes in the network may be vulnerable to some or all of the threats 260 outlined in Section 4. In such a case some protection is desirable to 261 secure ND. Providing such protection falls within the main initial 262 focus of the SEND working group. 264 Furthermore, it is desirable to limit the amount of potential damage 265 in the case a node becomes compromised. For example, it might still 266 be acceptable that a compromised node is able to launch a 267 denial-of-service attack, but it is undesirable if it is able to 268 hijack existing connections or establish man-in-the-middle attacks on 269 new connections. 271 As mentioned in Section 2, one possibility to secure ND would be to 272 use IPsec AH with symmetric shared keys, known by all trusted nodes 273 and by no outsiders. However, none of the currently standardized 274 automatic key distribution mechanisms work right out-of-the-box. For 275 further details, see [11]. Furthermore, using a shared key would not 276 protect against a compromised node. 278 More specifically, the currently used key agreement protocol, IKE, 279 suffers from a chicken-and-egg problem [11]: one needs and IP address 280 to run IKE, IKE is needed to establish IPsec SAs, and IPsec SAs are 281 required to configure an IP address. Furthermore, there does not seem 282 to be any easy and efficient ways of securing ND with symmetric key 283 cryptography. The required number of security associations would be 284 very large [12]. 286 As an example, one possible approach to overcome this limitation is 287 to use public key cryptography, and to secure ND packets directly 288 with public key signatures. 290 3.2 Public Wireless Network with an Operator 292 A scenario where an operator runs a public wireless (or wireline) 293 network, e.g., a WLAN in a hotel, airport, or cafe, has a different 294 trust model. Here the nodes may be assumed to trust the operator to 295 provide the IP forwarding service in a trustworthy manner, and not to 296 disrupt or misdirect the clients' traffic. However, the clients do 297 not usually trust each other. Typically the router (or routers) fall 298 under one administrative domain, and the client nodes each fall under 299 their own administrative domain. 301 It is assumed that under this scenario the operator authenticates all 302 the client nodes, or at least requires authorization in the form of a 303 payment. At the same time, the clients must be able to authenticate 304 the router and make sure that it belongs to the trusted operator. 305 Depending on the link layer authentication protocol and its 306 deployment, the link layer may take care of the mutual 307 authentication. The link layer authentication protocol may allow the 308 client nodes and the access router to create a security association. 309 Note that there exist authentication protocols, e.g., variants of 310 EAP, that do not create secure keying material and/or do not allow 311 the client to authenticate the network. 313 In this scenario, cryptographically securing the link layer does not 314 necessarily block all the threats outlined in Section 4; see the 315 individual threat descriptions. Specifically, even in 802.11i RSN 316 with EAS encryption the broadcast and multicast keys are shared 317 between all nodes. Even if the underlying link layer was aware of 318 all the nodes' link layer addresses, and were able to check that no 319 source addresses were falsified, there would still be 320 vulnerabilities. 322 One should also note that link layer security and IP topology do not 323 necessarily match. For example, the wireless access point may not be 324 visible at the IP layer at all. In such a case cryptographic 325 security at the link layer does not provide any security with regard 326 to IP Neighbor Discovery. 328 There seems to be at least two ways to bring in security into this 329 scenario. One possibility seems to be to enforce strong security 330 between the clients and the access router, and make the access router 331 aware of the IP and link layer layer protocol details. That is, the 332 router would check ICMPv6 packet contents, and filter packets that 333 contain information which does not match the network topology. The 334 other possibly looking way is to add cryptographic protection to the 335 ICMPv6 packets carrying ND messages. 337 3.3 Ad Hoc Network 339 In an ad hoc network, or any network without a trusted operator, none 340 of the nodes trust each other. In a generic case, the nodes meet 341 each other for the first time, and there are no guarantees that the 342 other nodes would behave correctly at the IP layer. They must be 343 considered suspectible to send falsified ND and RD messages. 345 Since there are no a priori trust relationships, the nodes cannot 346 rely on traditional authentication. That is, the traditional 347 authentication protocols rely on some existing relationship between 348 the parties. The relationship may be direct or indirect. The 349 indirect case relies on one or more trusted third parties, thereby 350 creating a chain of trust relationships between the parties. 352 In the generic ad hoc network case, there are no trusted third 353 parties, nor do the parties trust each other directly. Thus, the 354 traditional means of first authenticating and then authorizing the 355 users (to use their addresses) do not work. 357 It is still possible to use self-identifying mechanisms, such as 358 Cryptographically Generated Addresses (CGA) [10]. These allow the 359 nodes to ensure that they are talking to the same nodes (as before) 360 at all times, and that each of the nodes indeed have generated their 361 IP address themselves and not "stolen" someone else's address. It 362 may also be possible to learn the identities of any routers using 363 various kinds of heuristics, such as testing the node's ability to 364 convey cryptographically protected traffic towards a known and 365 trusted node somewhere in the Internet. Methods like these seem to 366 mitigate (but not completely block) some of the attacks outlined in 367 the next section. 369 4. Threats on a (Public) Multi-Access Link 371 In this section we discuss threats against the current IPv6 Neighbor 372 Discovery mechanisms, when used in multi-access links. The threats 373 are discussed in the light of the trust models defined in the 374 previous section. 376 There are three general types of threats: 378 1. Redirect attacks in which a malicious node redirects packets away 379 from the last hop router or other legitimate receiver to another 380 node on the link. 382 2. Denial-of-Service (DoS) attacks, in which a malicious node 383 prevents communication between the node under attack and all 384 other nodes, or a specific destination address. 386 3. Flooding Denial-of-Service (DoS) attacks, in which a malicious 387 node redirects other hosts's traffic to a victim node, and 388 thereby creates a flood of bogus traffic at the victim host. 390 A redirect attack can be used for DoS purposes by having the node to 391 which the packets were redirected drop the packets, either completely 392 or by selectively forwarding some of them and not others. 394 The subsections below identify specific threats for IPv6 network 395 access. The threat descriptions are organized in three subsections. 396 We first consider threats that do not involve routers or routing 397 information. We next consider threats that do involve routers or 398 routing information. Finally, we consider replay attacks and threats 399 that are remotely exploitable. All threats are discussed in the 400 light of the trust models. 402 4.1 Non router/routing related threats 404 In this section we discuss attacks against "pure" Neighbor Discovery 405 functions, i.e., Neighbor Discovery (ND), Neighbor Unreachability 406 Detection (NUD), and Duplicate Address Detection (DAD) in Address 407 Autoconfiguration. 409 4.1.1 Neighbor Solicitation/Advertisement Spoofing 411 Nodes on the link use Neighbor Solicitation and Advertisement 412 messages to creat bindings between IP addresses and MAC addresses. 413 More specifically, there are two cases when a node creates neighbor 414 cache entries upon receiving Soliciations: 416 1. A router receives an Router Solicitation that contains a node's 417 address. The router can use that to populate its neighbor cache. 418 This is basically a performance optimization, and a SHOULD in the 419 base documents. 421 2. During Duplicate Address Detection (DAD), if a node receives a 422 Neighbor Solicitation for the same address it is soliciting for, 423 the situation is considered a collision, and the node must cease 424 to solicit for the said address. 426 In constrast to solicitation messages that create state only in these 427 specific occasions, state is usually created whenever a node receives 428 an advertisement message. 430 An attacking node can cause packets for legitimate nodes, both hosts 431 and routers, to be sent to some other link-layer address. This can 432 be done by either sending a Neighbor Solicitation with a different 433 source link-layer address option, or sending a Neighbor Advertisement 434 with a different target link-layer address option. 436 The attacks succeed because the Neighbor Cache entry with the new 437 link-layer address overwrites the old. If the spoofed link-layer 438 address is a valid one, as long as the attacker responds to the 439 unicast Neighbor Solicitation messages sent as part of the Neighbor 440 Unreachability Detection, packets will continue to be redirected. 441 This is a redirect/DoS attack. 443 This mechanism can be used for a DoS attack by specifying an unused 444 link-layer address; however, this DoS attack is of limited duration 445 since after 30-50 seconds (with default timer values) the Neighbor 446 Unreachability Detection mechanism will discard the bad link-layer 447 address and multicast anew to discover the link-layer address. As a 448 consequence, the attacker will need to keep responding with 449 fabricated link layer addresses if it wants to maintain the attack 450 beyond the timeout. 452 This threat involves Neighbor Solicitation and Neighbor Advertisement 453 messages. 455 This attack is not a concern if access to the link is restricted to 456 trusted nodes; if a trusted node is compromised, the other nodes are 457 exposed to this threat. In the case just the operator is trusted, 458 the nodes may rely on the operator to certify the address bindings 459 for other local nodes. From the security point of view, the router 460 may act as a trusted proxy for the other nodes. This assumes that the 461 router can be trusted to represent correctly the other nodes on the 462 link. In the ad hoc network case, and optionally in the other two 463 cases, the nodes may use self certifying techniques (e.g., CGA) to 464 authorize address bindings. 466 Additionally, as possible advice considering implementations, already 467 now some implementations log an error and refuse to accept ND 468 overwrites, instead requiring the old entry to time out first. 470 4.1.2 Neighbor Unreachability Detection (NUD) failure 472 Nodes on the link monitor the reachability of local destinations and 473 routers with the Neighbor Unreachability Detection procedure [3]. 474 Normally the nodes rely on upper-layer information to determine 475 whether peer nodes are still reachable. However, if there is a 476 sufficiently long delay on upper-layer traffic, or if the node stops 477 receiving replies from a peer node, the NUD procedure is invoked. 478 The node sends a targeted NS to the peer node. If the peer is still 479 reachable, it will reply with a NA. However, if the soliciting node 480 receives no reply, it tries a few more times, eventually deleting the 481 neighbor cache entry. If needed, this triggers the standard address 482 resolution protocol to learn the new MAC address. No higher level 483 traffic can proceed if this procedure flushes out neighbor cache 484 entries after determining (perhaps incorrectly) that the peer is not 485 reachable. 487 A malicious node may keep sending fabricated NAs in response to NUD 488 NS messages. Unless the NA messages are somehow protected, the 489 attacker may be able to extend the attack for a long time using this 490 technique. The actual consequences depend on why the node become 491 unreachable for the first place, and how the target node would behave 492 if it knew that the node has become unreachable. This is a DoS 493 attack. 495 This threat involves Neighbor Solicitation/Advertisement messages. 497 This attack is not a concern if access to the link is restricted to 498 trusted nodes; if a trusted node is compromised, the other nodes are 499 exposed to this DoS threat. Under the two other trust models, a 500 solution requires that the node performing NUD is able to make a 501 distinction between genuine and fabricated NA responses. 503 4.1.3 Duplicate Address Detection DoS Attack 505 In networks where the entering hosts obtain their addresses using 506 stateless address autoconfiguration [4], an attacking node could 507 launch a DoS attack by responding to every duplicate address 508 detection attempt made by an entering host. If the attacker claims 509 the address, then the host will never be able to obtain an address. 510 The attacker can claim the address in two ways: it can either reply 511 with an NS, simulating that it is performing DAD, too, or it can 512 reply with an NA, simulating that it has already taken the address 513 into use. This threat was identified in RF2462 [4]. This is a DoS 514 attack. 516 This threat involves Neighbor Solicitation/Advertisement messages. 518 This attack is not a concern if access to the link is restricted to 519 trusted nodes; if a trusted node is compromised, the other nodes 520 become exposed to this DoS threat. Under the two other trust models, 521 a solution requires that the node performing DAD is able to verify 522 whether the sender of the NA response is authorized to use the given 523 IP address or not. In the trusted operator case, the operator may 524 act as an authorizer, keeping track of allocated addresses and making 525 sure that no node has allocated more than a few (hundreds of) 526 addresses. On the other hand, it may be detrimental to adopt such a 527 practice, since there may be situations where it is desirable for one 528 node to have a large number of addresses, e.g, creating a separate 529 address per TCP connection, or when running an ND proxy. Thus, it 530 may be inappropriate to suggest that ISPs could control how many 531 addresses a legitimate host can have; the discussion above must be 532 considered only as examples, as stated in the beginning of this 533 draft. 535 In the ad hoc network case one may want to structure the addresses in 536 such a way that self authorization is possible. 538 4.2 Router/routing involving threats 540 In this section we consider threats pertinent to router discovery or 541 other router assisted/related mechanisms. 543 4.2.1 Malicious Last Hop Router 545 This threat was identified in [7] but was classified as a general 546 IPv6 threat and not specific to Mobile IPv6. It is also identified 547 in RFC2461 [3]. This threat is a redirect/DoS attack. 549 An attacking node on the same subnet as a host attempting to discover 550 a legitimate last hop router could masquerade as an IPv6 last hop 551 router by multicasting legitimate-looking IPv6 Router Advertisements 552 or unicasting Router Advertisements in response to multicast Router 553 Advertisement Solicitations from the entering host. If the entering 554 host selects the attacker as its default router, the attacker has the 555 opportunity to siphon off traffic from the host, or mount a 556 man-in-the-middle attack. The attacker could ensure that the 557 entering host selected itself as the default router by multicasting 558 periodic Router Advertisements for the real last hop router having a 559 lifetime of zero. This may spoof the entering host into believing 560 that the real access router is not willing to take any traffic. Once 561 accepted as a legitimate router, the attacker could send Redirect 562 messages to hosts, then disappear, thus covering its tracks. 564 This threat is partially mitigated in RFC2462; in Section 5.5.3 of 565 RFC2462 it is required that if the advertised prefix lifetime is less 566 than 2 hours and less than the stored lifetime, the stored lifetime 567 is not reduced unless the packet was authenticated. However, the 568 default router selection procedure, as defined in Section 6.3.6. of 569 RFC2461, does not contain such a rule. 571 This threat involves Router Advertisement and Router Advertisement 572 Solicitation messages. 574 This attack is not a concern if access to the link is restricted to 575 trusted nodes; if a trusted node is compromised, the other nodes are 576 exposed to this threat. However, the threat can be partially 577 mitigated through a number of means, for example, by configuring the 578 nodes to prefer existing routers over new ones. Note that this 579 approach does not necessarily prevent one from introducing new 580 routers into the network, depending on the details of implementation. 581 At minimum, it just makes the existing nodes to prefer the existing 582 routers over the new ones. 584 In the case of a trusted operator, there must be a means for the 585 nodes to make a distinction between trustworthy routers, run by the 586 operator, and other nodes. There are currently no widely accepted 587 solutions for the ad hoc network case, and the issue remains as a 588 research question. 590 4.2.2 Default router is 'killed' 592 In this attack, an attacker 'kills' the default router(s), thereby 593 making the nodes on the link to assume that all nodes are local. In 594 Section 5.2 of RFC2461 [3] it is stated that "[if] the Default Router 595 List is empty, the sender assumes that the destination is on-link." 596 Thus, if the attacker is able to make a node to believe that there 597 are no default routers on the link, the node will try to send the 598 packets directly, using Neighbor Discovery. After that the attacker 599 can use NS/NA spoofing even against off-link destinations. 601 There are a few identified ways how an attacker can 'kill' the 602 default router(s). One is to launch a classic DoS attack against the 603 router so that it does not appear responsive any more. The other is 604 to send a spoofed Router Advertisement with a zero Router Lifetime 605 (see Section 6.3.4 of RFC2461 [3]). However, see also the discussion 606 in Section 4.2.1, above. 608 This threat involves Router Advertisement messages. One variant of 609 this threat may be possible by overloading the router, without using 610 any ND/RD messages. 612 This attack is not a concern if access to the link is restricted to 613 trusted nodes; if a trusted node is compromised, the other nodes are 614 exposed to this threat. In the case of a trusted operator, there 615 must be a means for the nodes to make a distinction between 616 trustworthy routers, run by the operator, and other nodes. That 617 protects against spoofed Router Advertisements, but it does not 618 protect against router overloading. There are currently no widely 619 accepted solutions for the ad hoc network case, and the issue remains 620 as a research question. 622 Thanks to Alain Durand for identifying this threat. 624 4.2.3 Good Router Goes Bad 626 In this attack, a router that previously was trusted is compromised. 627 The attacks available are the same as those discussed in Section 628 4.2.1. This is a redirect/DoS attack. 630 There are currently no known solutions for any of the presented three 631 trust models. On the other hand, on a multi-router link one could 632 imagine a solution involving revocation of router rights. The 633 situation remains as a research question. 635 4.2.4 Spoofed Redirect Message 637 The Redirect message can be used to send packets for a given 638 destination to any link-layer address on the link. The attacker uses 639 the link-local address of the current first-hop router in order to 640 send a Redirect message to a legitimate host. Since the host 641 identifies the message by the link-local address as coming from its 642 first hop router, it accepts the Redirect. As long as the attacker 643 responds to Neighbor Unreachability Detection probes to the link- 644 layer address, the Redirect will remain in effect. This is a 645 redirect/DoS attack. 647 This threat involves Redirect message. 649 This attack is not a concern if access to the link is restricted to 650 trusted nodes; if a trusted node is compromised, the other nodes are 651 exposed to this threat. In the case of a trusted operator, there 652 must be a means for the nodes to make a distinction between 653 trustworthy routers, run by the operator, and other nodes. There are 654 currently no widely accepted solutions for the ad hoc network case, 655 and the issue remains as a research question. 657 4.2.5 Bogus On-Link Prefix 659 An attacking node can send a Router Advertisement message specifying 660 that some prefix of arbitrary length is on-link. If a sending host 661 thinks the prefix is on-link, it will never send a packet for that 662 prefix to the router. Instead, the host will try to perform address 663 resolution by sending Neighbor Solicitations, but the Neighbor 664 Solicitations will not result in a response, denying service to the 665 attacked host. This is a DoS attack. 667 The attacker can use an arbitrary lifetime on the bogus prefix 668 advertisement. If the lifetime is infinity, the sending host will be 669 denied service until it loses the state in its prefix list e.g., by 670 rebooting, or after the same prefix is advertised with a zero 671 lifetime. The attack could also be perpetrated selectively for 672 packets destined to a particular prefix by using 128 bit prefixes, 673 i.e. full addresses. 675 Additionally, the attack may cause a denial-of-service by flooding 676 the routing table of the node. The node would not be able to 677 differentiate between legitimate on-link prefixes and bogus ones when 678 making decisions as to which ones are kept and which are dropped. 679 Inherently, any finite system must have some point at which new 680 received prefixes must be dropped rather than accepted. 682 This attack can be extended into a redirect attack if the attacker 683 replies to the Neighbor Solicitations with spoofed Neighbor 684 Advertisements, thereby luring the nodes on the link to send the 685 traffic to it or to some other node. 687 This threat involves Router Advertisement message. The extended 688 attack combines the attack defined in Section 4.1.1 and in this 689 section, and involves Neighbor Solicitation, Neighbor Advertisement, 690 and Router Advertisement messages. 692 This attack is not a concern if access to the link is restricted to 693 trusted nodes; if a trusted node is compromised, the other nodes are 694 exposed to this threat. In the case of a trusted operator, there 695 must be a means for the nodes to make a distinction between 696 trustworthy routers, run by the operator, and other nodes. There are 697 currently no known solutions for the ad hoc network case, and the 698 issue remains as a research question. 700 As an example, one possible approach to limiting the damage of this 701 attack is to require advertised on-link prefixes be /64s (otherwise 702 it's easy to advertise something short like 0/0 and this attack is 703 very easy). 705 4.2.6 Bogus Address Configuration Prefix 707 An attacking node can send a Router Advertisement message specifying 708 an invalid subnet prefix to be used by a host for address 709 autoconfiguration. A host executing the address autoconfiguration 710 algorithm uses the advertised prefix to construct an address [4], 711 even though that address is not valid for the subnet. As a result, 712 return packets never reach the host because the host's source address 713 is invalid. This is a DoS attack. 715 This attack has the potential to propagate beyond the immediate 716 attacked host if the attacked host performs a dynamic update to the 717 DNS based on the bogus constructed address. DNS update [6] causes 718 the bogus address to be added to the host's address record in the 719 DNS. Should this occur, applications performing name resolution 720 through the DNS obtain the bogus address and an attempt to contact 721 the host fails. However, well-written applications will fall back 722 and try the other addresses registered in DNS, which may be correct. 724 A distributed attacker can make the attack more severe by creating a 725 falsified reverse DNS entry that matches with the dynamic DNS entry 726 created by the target. Consider an attacker who has legitimate 727 access to a prefix , and a target who has an interface 728 ID . The attacker creates a reverse DNS entry for 729 :, pointing to the real domain name of the 730 target, e.g., "secure.target.com". Next the attacker advertises the 731 prefix at the target's link. The target will create an 732 address :, and update its DNS entry so that 733 "secure.target.com" points to :. 735 At this point "secure.target.com" points to 736 :, and : points to 737 "secure.target.com". This threat is mitigated by the fact that the 738 attacker can be traced since the owner of the is 739 available at the registries. 741 There is also a related possibility of advertising a target prefix as 742 an autoconfiguration prefix on a busy link, and then have all nodes 743 on this link try to communicate to the external world with this 744 address. If the local router doesn't have ingress filtering on, then 745 the target link will get all the replies for those initial 746 communication attempts. 748 This threat involves Router Advertisement message. The extended 749 attack scenarios involve the DNS, too. 751 This attack is not a concern if access to the link is restricted to 752 trusted nodes; if a trusted node is compromised the other nodes are 753 exposed to this threat. In the case of a trusted operator, there 754 must be a means for the nodes to make a distinction between 755 trustworthy routers, run by the operator, and other nodes. There are 756 currently no known solutions for the ad hoc network case, and the 757 issue remains as a research question. 759 4.2.7 Parameter Spoofing 761 IPv6 Router Advertisements contain a few parameters used by hosts 762 when they send packets and to tell hosts whether or not they should 763 perform stateful address configuration [3]. An attacking node could 764 send out a valid-seeming Router Advertisement that duplicates the 765 Router Advertisement from the legitimate default router, except the 766 included parameters are designed to disrupt legitimate traffic. This 767 is a DoS attack. 769 Specific attacks include: 771 1. The attacker includes a Current Hop Limit of one or another small 772 number which the attacker knows will cause legitimate packets to 773 be dropped before they reach their destination. 775 2. The attacker implements a bogus DHCPv6 server or relay and the 776 'M' and/or 'O' flag is set, indicating that stateful address 777 configuration and/or stateful configuration of other parameters 778 should be done. The attacker is then in a position to answer the 779 stateful configuration queries of a legitimate host with its own 780 bogus replies. 782 This threat involves Router Advertisement message. 784 Note that securing DHCP alone does not resolve this problem. There 785 are two reasons for this. Firstly, the attacker may prevent the node 786 from using DHCP in the first place. Secondly, depending on the 787 node's local configuration, the attacker may spoof the node to use a 788 less trusted DHCP server. (The latter is a variant of the so called 789 "bidding down" or "down grading" attacks.) 791 As an example, one possible approach to mitigate this threat is to 792 ignore very small hop limits. The nodes could implement a 793 configurable minimum hop limit, and ignore attempts to set it below 794 said limit. 796 This attack is not a concern if access to the link is restricted to 797 trusted nodes; if a trusted node is compromised the other nodes are 798 exposed to this treat. In the case of a trusted operator, there must 799 be a means for the nodes to make a distinction between trustworthy 800 routers, run by the operator, and other nodes. There are currently 801 no known solutions for the ad hoc network case, and the issue remains 802 as a research question. 804 4.3 Replay attacks and remotely exploitable attacks 806 4.3.1 Replay attacks 808 All Neighbor Discovery and Router Discovery messages are prone to 809 replay attacks. That is, even if they were cryptographically 810 protected so that their contents cannot be forged, an attacker would 811 be able to capture valid messages and replay them later. Thus, 812 independent on what mechanism is selected to secure the messages, 813 that mechanism must be protected against replay attacks. 815 Fortunately it is fairly easy to defeat most replay attacks. In 816 request-reply exchanges, such as Solicitation-Advertisement, the 817 request may contain a nonce that must appear also in the reply. 818 Thus, old replies are not valid since they do not contain the right 819 nonce. Correspondingly, standalone messages, such as unsolicitated 820 Advertisements or Redirect messages, may be protected with timestamps 821 or counters. In practise, roughly synchronized clocks and timestamps 822 seem to work well, since the recipients may keep track of the 823 difference between the clocks of different nodes, and make sure that 824 all new messages are newer than the last seen message. 826 4.3.2 Neighbor Discovery DoS Attack 828 In this attack, the attacking node begins fabricating addresses with 829 the subnet prefix and continuously sending packets to them. The last 830 hop router is obligated to resolve these addresses by sending 831 neighbor solicitation packets. A legitimate host attempting to enter 832 the network may not be able to obtain Neighbor Discovery service from 833 the last hop router as it will be already busy with sending other 834 solicitations. This DoS attack is different from the others in that 835 the attacker may be off-link. The resource being attacked in this 836 case is the conceptual neighbor cache, which will be filled with 837 attempts to resolve IPv6 addresses having a valid prefix but invalid 838 suffix. This is a DoS attack. 840 This threat involves Neighbor Solicitation message. 842 This attack does not directly involve the trust models presented. 843 However, if access to the link is restricted to registered nodes, and 844 the access router keeps track of nodes that have registered for 845 access on the link, the attack may be trivially plugged. However, no 846 such mechanisms are currently standardized. 848 In a way, this problem is fairly similar to the TCP SYN flooding 849 problem. For example, rate limiting Neighbor Solicitations, 850 restricting the amount of state reserved for unresolved 851 solicitations, and clever cache management may be applied. 853 It should be noted that both hosts and routers need to worry about 854 this problem. The router case was discussed above. Hosts are also 855 vulnerable since the neighbor discovery process can potentially be 856 abused by an application that is tricked into sending packets to 857 arbitrary on-link destinations. 859 At the publication of this document, it is still an open question 860 whether the SEND WG should address this threat or not, to be decided 861 later by the working group. However, the current efforts do not 862 consider this problem. 864 4.4 Summary of the attacks 866 Columns: 868 N/R Neighbor Discovery (ND) or Router Discovery (RD) attack 870 R/D Redirect/DoS (Redir) or just DoS attack 872 Msgs Messages involved in the attack: NA, NS, RA, RS, Redir 874 1 Present in trust model 1 (corporate intranet) 876 2 Present in trust model 2 (public operator run network) 878 3 Present in trust model 3 (ad hoc network) 880 Symbols in trust model columns: 882 - The threat is not present or not a concern. 884 + The threat is present and at least one solution is known. 886 R The threat is present but solving it is a research problem. 888 Note that the plus sign '+' in the table does not mean that there is 889 a ready-to-be-applied, standardized solution. If solutions existed, 890 this document would be unnecessary. Instead, it denotes that in the 891 authors' opinion the problem has been solved in principle, and there 892 exist a publication that describes some approach to solve the 893 problem, or a solution may be produced by straightforward application 894 of known research and/or engineering results. 896 In the other hand, and 'R' indicates that the authors' are not aware 897 of any publication describing a solution to the problem, and cannot 898 at the time of writing think about any simple and easy extension of 899 known research and/or engineering results to solve the problem. 901 +-------+----------------------+-----+-------+-------+---+---+---+ 902 | Sec | Attack name | N/R | R/D | Msgs | 1 | 2 | 3 | 903 +-------+----------------------+-----+-------+-------+---+---+---+ 904 | 4.1.1 | NS/NA spoofing | ND | Redir | NA NS | + | + | + | 905 | 4.1.2 | NUD failure | ND | DoS | NA NS | - | + | + | 906 | 4.1.3 | DAD DoS | ND | DoS | NA NS | - | + | + | 907 +-------+----------------------+-----+-------+-------+---+---+---+ 908 | 4.2.1 | Malicious router | RD | Redir | RA RS | + | + | R | 909 | 4.2.2 | Default router killed| RD | Redir | RA |+/R|+/R| R | 1) 910 | 4.2.3 | Good router goes bad | RD | Redir | RA RS | R | R | R | 911 | 4.2.4 | Spoofed redirect | RD | Redir | Redir | + | + | R | 912 | 4.2.5 | Bogus on-link prefix | RD | DoS | RA | - | + | R | 2) 913 | 4.2.6 | Bogus address config | RD | DoS | RA | - | + | R | 3) 914 | 4.2.7 | Parameter spoofing | RD | DoS | RA | - | + | R | 915 +-------+----------------------+-----+-------+-------+---+---+---+ 916 | 4.3.1 | Replay attacks | All | Redir | All | + | + | + | 917 | 4.3.2 | Remote ND DoS | ND | DoS | NS | + | + | + | 918 +------------------------------+-----+-------+-------+---+---+---+ 920 Figure 1 922 1. It is possible to protect the Router Advertisements, thereby 923 closing one variant of this attack. However, closing the other 924 variant (overloading the router) does not seem to be plausible 925 within the scope of this working group. 927 2. Note that the extended attack defined in Section 4.2.5 combines 928 sending a bogus on-link prefix and performing NS/NA spoofing as 929 per Section 4.1.1 Thus, if the NA/NS exchange is secured, the 930 ability to use Section 4.2.5 for redirect is most probably 931 blocked, too. 933 3. The bogus DNS registration resulting from blindly registering the 934 new address via DNS update [6] is not considered an ND security 935 issue here. However, it should be noted as a possible 936 vulnerability in implementations. 938 For a slightly different approach, see also Section 7 in [12]. 939 Especially the table in Section 7.7 of [12] is very good. 941 5. Security Considerations 943 This document discusses security threats to network access in IPv6. 944 As such, it is concerned entirely with security. 946 6. Acknowledgements 948 Thanks to Alper Yegin of DoCoMo Communications Laboratories USA for 949 identifying the Neighbor Discovery DoS attack. We would also like to 950 thank Tuomas Aura and Michael Roe of Microsoft Research Cambridge as 951 well as Jari Arkko and Vesa-Matti Mantyla of Ericsson Research 952 Nomadiclab for discussing some of the threats with us. 954 Thanks to Alper Yegin, Pekka Savola, Bill Sommerfeld, Vijay 955 Devaparalli, Dave Thaler, and Alain Durand for their constructive 956 comments. 958 Thanks to Craig Metz for his numerous very good comments, and 959 especially for more material of implementations that refuse to accept 960 ND overrides, for the bogus on-link prefix threat, and for reminding 961 us about replay attacks. 963 References (Informative) 965 [1] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication 966 Protocol (EAP)", RFC 2284, March 1998. 968 [2] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, 969 November 1998. 971 [3] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery 972 for IP Version 6 (IPv6)", RFC 2461, December 1998. 974 [4] Thomson, S. and T. Narten, "IPv6 Stateless Address 975 Autoconfiguration", RFC 2462, December 1998. 977 [5] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, 978 December 1998. 980 [6] Wellington, B., "Secure Domain Name System (DNS) Dynamic 981 Update", RFC 3007, November 2000. 983 [7] Mankin, A., "Threat Models introduced by Mobile IPv6 and 984 Requirements for Security in Mobile IPv6", 985 draft-ietf-mobileip-mipv6-scrty-reqts-02 (work in progress), 986 November 2001. 988 [8] Droms, R., "Dynamic Host Configuration Protocol for IPv6 989 (DHCPv6)", draft-ietf-dhc-dhcpv6-28 (work in progress), 990 November 2002. 992 [9] Kempf, J., Gentry, C. and A. Silverberg, "Securing IPv6 993 Neighbor Discovery Using Address Based Keys (ABKs)", 994 draft-kempf-secure-nd-01 (work in progress), June 2002. 996 [10] Roe, M., "Authentication of Mobile IPv6 Binding Updates and 997 Acknowledgments", draft-roe-mobileip-updateauth-02 (work in 998 progress), March 2002. 1000 [11] Arkko, J., "Effects of ICMPv6 on IKE and IPsec Policies", 1001 draft-arkko-icmpv6-ike-effects-01 (work in progress), June 1002 2002. 1004 [12] Arkko, J., "Manual SA Configuration for IPv6 Link Local 1005 Messages", draft-arkko-manual-icmpv6-sas-01 (work in progress), 1006 June 2002. 1008 Authors' Addresses 1010 Pekka Nikander (editor) 1011 Ericsson Research Nomadic Lab 1013 JORVAS FIN-02420 1014 FINLAND 1016 Phone: +358 9 299 1 1017 EMail: pekka.nikander@nomadiclab.com 1019 James Kempf 1020 DoCoMo USA Labs 1021 181 Metro Drive, Suite 300 1022 San Jose, CA 95110 1023 USA 1025 Phone: +1 408 451 4711 1026 EMail: kempf@docomolabs-usa.com 1028 Erik Nordmark 1029 Sun Microsystems Laboratories 1030 29, Chemin du Vieux Chene 1031 Meylan 38240 1032 France 1034 Phone: +33 4 76 18 88 03 1035 EMail: erik.nordmark@sun.com 1037 Appendix A. Changes between versions 1039 (To be removed before publication.) 1041 -00 to -01 1043 Added text to Section 4.2.5 to explained the combined NS/NA 1044 spoofing + Bogus On-Link Prefix attack (suggested by Pekka 1045 Savola). 1047 Added text to Section 4.2.6 to describe how it can be extended to 1048 include a valid reverse DNS mapping (suggested by Pekka Savola). 1050 Added text to Section 4.2.6 to consider its potential flooding 1051 effects (suggested by Jari Arkko). 1053 Added text through the document to trust model 1, considering what 1054 happens if a previously trusted node becomes compromised 1055 (suggested by Pekka Savola and Bill Sommerfeld). 1057 Changed the summary table in Section 4.4 so that the redirect 1058 threats should be considered even in the corporate intranet case. 1060 Added qualifying text to all occasions where a node is said to 1061 trust another node, and even to some cases where a node is said 1062 not to trust another node. 1064 Added footnotes 1) and 2) to Figure 1 1066 Added more discussion to threat Section 4.3.2 noting that it is 1067 similar to TCP SYN flooding, and that also hosts need to worry 1068 about it. 1070 Converted to xml2rfc. 1072 -01 to -02 1074 Editorial changes 1076 Changed all references to be informative 1078 Addressed the issues raised during the WG LC, as indicated in the 1079 issue list at http://www.tml.hut.fi/~pnr/SEND/issues.html 1081 Removed [[brackets]] as agreed as San Francisco meeting. 1083 -02 to -03 1084 Editorial changes 1086 Added threat Section 4.2.2. 1088 Intellectual Property Statement 1090 The IETF takes no position regarding the validity or scope of any 1091 intellectual property or other rights that might be claimed to 1092 pertain to the implementation or use of the technology described in 1093 this document or the extent to which any license under such rights 1094 might or might not be available; neither does it represent that it 1095 has made any effort to identify any such rights. Information on the 1096 IETF's procedures with respect to rights in standards-track and 1097 standards-related documentation can be found in BCP-11. Copies of 1098 claims of rights made available for publication and any assurances of 1099 licenses to be made available, or the result of an attempt made to 1100 obtain a general license or permission for the use of such 1101 proprietary rights by implementors or users of this specification can 1102 be obtained from the IETF Secretariat. 1104 The IETF invites any interested party to bring to its attention any 1105 copyrights, patents or patent applications, or other proprietary 1106 rights which may cover technology that may be required to practice 1107 this standard. Please address the information to the IETF Executive 1108 Director. 1110 Full Copyright Statement 1112 Copyright (C) The Internet Society (2003). All Rights Reserved. 1114 This document and translations of it may be copied and furnished to 1115 others, and derivative works that comment on or otherwise explain it 1116 or assist in its implementation may be prepared, copied, published 1117 and distributed, in whole or in part, without restriction of any 1118 kind, provided that the above copyright notice and this paragraph are 1119 included on all such copies and derivative works. However, this 1120 document itself may not be modified in any way, such as by removing 1121 the copyright notice or references to the Internet Society or other 1122 Internet organizations, except as needed for the purpose of 1123 developing Internet standards in which case the procedures for 1124 copyrights defined in the Internet Standards process must be 1125 followed, or as required to translate it into languages other than 1126 English. 1128 The limited permissions granted above are perpetual and will not be 1129 revoked by the Internet Society or its successors or assignees. 1131 This document and the information contained herein is provided on an 1132 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1133 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1134 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1135 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1136 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1138 Acknowledgement 1140 Funding for the RFC Editor function is currently provided by the 1141 Internet Society.