idnits 2.17.1 draft-ietf-v6ops-rogue-ra-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 25, 2010) is 4930 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3736 (Obsoleted by RFC 8415) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations T. Chown 3 Internet-Draft University of Southampton 4 Intended status: Informational S. Venaas 5 Expires: April 28, 2011 Cisco Systems 6 October 25, 2010 8 Rogue IPv6 Router Advertisement Problem Statement 9 draft-ietf-v6ops-rogue-ra-02 11 Abstract 13 When deploying IPv6, whether IPv6-only or dual-stack, routers are 14 configured to send IPv6 Router Advertisements to convey information 15 to nodes that enable them to autoconfigure on the network. This 16 information includes the implied default router address taken from 17 the observed source address of the Router Advertisement (RA) message, 18 as well as on-link prefix information. However, unintended 19 misconfigurations by users or administrators, or possibly malicious 20 attacks on the network, may lead to bogus RAs being present, which in 21 turn can cause operational problems for hosts on the network. In 22 this draft we summarise the scenarios in which rogue RAs may be 23 observed and present a list of possible solutions to the problem. We 24 focus on the unintended causes of rogue RAs in the text. The goal of 25 this text is to be Informational, and as such to present a framework 26 around which solutions can be proposed and discussed. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 28, 2011. 45 Copyright Notice 47 Copyright (c) 2010 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 This document may contain material from IETF Documents or IETF 61 Contributions published or made publicly available before November 62 10, 2008. The person(s) controlling the copyright in some of this 63 material may not have granted the IETF Trust the right to allow 64 modifications of such material outside the IETF Standards Process. 65 Without obtaining an adequate license from the person(s) controlling 66 the copyright in such materials, this document may not be modified 67 outside the IETF Standards Process, and derivative works of it may 68 not be created outside the IETF Standards Process, except to format 69 it for publication as an RFC or to translate it into languages other 70 than English. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 2. Bogus RA Scenarios . . . . . . . . . . . . . . . . . . . . . . 4 76 2.1. Administrator misconfiguration . . . . . . . . . . . . . . 5 77 2.2. User misconfiguration . . . . . . . . . . . . . . . . . . 5 78 2.3. Malicious misconfiguration . . . . . . . . . . . . . . . . 5 79 3. Methods to Mitigate against Rogue RAs . . . . . . . . . . . . 6 80 3.1. Manual configuration . . . . . . . . . . . . . . . . . . . 6 81 3.2. Introduce RA snooping . . . . . . . . . . . . . . . . . . 6 82 3.3. Use ACLs on Managed Switches . . . . . . . . . . . . . . . 7 83 3.4. Secure Neighbor Discovery (SeND) . . . . . . . . . . . . . 7 84 3.5. Router Preference Option . . . . . . . . . . . . . . . . . 8 85 3.6. Rely on Layer 2 admission control . . . . . . . . . . . . 8 86 3.7. Use host-based packet filters . . . . . . . . . . . . . . 8 87 3.8. Use an 'intelligent' deprecation tool . . . . . . . . . . 8 88 3.9. Use Layer 2 Partitioning . . . . . . . . . . . . . . . . . 9 89 3.10. Add Default Gateway/Prefix Options to DHCPv6 . . . . . . . 9 90 4. Scenarios and mitigations . . . . . . . . . . . . . . . . . . 10 91 5. Other related considerations . . . . . . . . . . . . . . . . . 11 92 5.1. Unicast RAs . . . . . . . . . . . . . . . . . . . . . . . 11 93 5.2. The DHCP vs RA threat model . . . . . . . . . . . . . . . 11 94 5.3. IPv4-only networks . . . . . . . . . . . . . . . . . . . . 12 95 5.4. Network monitoring tools . . . . . . . . . . . . . . . . . 12 96 5.5. Recovering from bad configuration state . . . . . . . . . 12 97 5.6. Isolating the offending rogue RA source . . . . . . . . . 13 98 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 13 99 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 100 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 101 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 102 10. Informative References . . . . . . . . . . . . . . . . . . . . 14 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 105 1. Introduction 107 The Neighbor Discovery protocol [RFC4861] describes the operation of 108 IPv6 Router Advertisements (RAs) which are used to determine node 109 configuration information during the IPv6 autoconfiguration process, 110 whether that node's configuration is stateful via Dynamic Host 111 Configuration Protocol for IPv6 (DHCPv6) [RFC3315] or stateless, as 112 per [RFC4862], possibly in combination with DHCPv6 Light [RFC3736]. 114 In observing the operation of deployed IPv6 networks, it is apparent 115 that there is a problem with undesired or 'bogus' IPv6 Router 116 Advertisements (RAs) appearing on network links or subnets. By 117 'bogus' we mean RAs that were not the intended configured RAs, rather 118 RAs that have appeared for some other reason. While the problem 119 appears more common in shared wireless environments, it is also seen 120 on wired enterprise networks. 122 The problem with rogue RAs is that they can cause partial or complete 123 failure of operation of hosts on an IPv6 link. For example, the 124 default router address is drawn directly from the source address of 125 the RA message. In addition, rogue RAs can cause hosts to assume 126 wrong prefixes to be used for stateless address autoconfiguration. 127 In a case where there may be mixing of 'good' and 'bad' RAs, a host 128 might keep on using the 'good' default gateway, but pick a wrong 129 source address, leading to egress filtering problems. As such, rogue 130 RAs are an operational issue for which solution(s) are required, and 131 for which best practice needs to be conveyed. This not only includes 132 preventing or detecting rogue RAs, but also where necessary ensuring 133 the network (and hosts on the network) have the ability to quickly 134 recover from a state where host configuration is incorrect as a 135 result of processing such an RA. 137 In the next section, we discuss the scenarios that may give rise to 138 rogue RAs being present. In the following section we present some 139 candidate solutions for the problem, some of which may be more 140 practical to deploy than others. This document focuses on 141 'accidental' rogue RAs; while malicious RAs are of course also 142 possible, the common problem today lies with unintended RAs. In 143 addition a network experiencing malicious attack of this kind is 144 likely to also experience malicious Neighbour Advertisement (NA) and 145 related messages also. 147 2. Bogus RA Scenarios 149 There are three broad classes of scenario in which bogus RAs may be 150 introduced to an IPv6 network. 152 2.1. Administrator misconfiguration 154 Here an administrator incorrectly configures RAs on a router 155 interface, causing incorrect RAs to appear on links and hosts to 156 generate incorrect or unintended IPv6 address, gateway or other 157 information. In such a case the default gateway may be correct, but 158 a host might for example become multi-addressed, possibly with a 159 correct and incorrect address based on a correct and incorrect 160 prefix. There is also the possibility of other configuration 161 information being misconfigured, such as the lifetime option. 163 In the case of a Layer 2 IEEE 802.1Q Virtual LAN (VLAN) 164 misconfiguration, RAs may 'flood' to unintended links, causing hosts 165 or more than one link to potentially become incorrectly 166 multiaddressed, with possibly two different default routers 167 available. 169 2.2. User misconfiguration 171 In this case a user's device 'accidentally' transmits RAs onto the 172 local link, potentially adding an additional default gateway and 173 associated prefix information. 175 This seems to typically be seen on wireless (though sometimes wired) 176 networks where a laptop has enabled the Windows Internet Connection 177 Sharing service (ICS) which turns a host into a 6to4 [RFC3056] 178 gateway; this can be a useful feature, unless of course it is run 179 when not intended. This service can also cause IPv4 problems too, as 180 it will typically start a 'rogue' DHCPv4 server on the host. 182 We have also had reports that hosts may not see genuine IPv6 RAs on a 183 link due to host firewalls, causing them to turn on a connection 184 sharing service and 6to4 as a result. In some cases more technical 185 users may also use a laptop as a home gateway (e.g. again a 6to4 186 gateway) and then connect to another network forgetting their 187 previous gateway configuration is still active. 189 There are also reported incidents in enterprise networks of users 190 physically plugging Ethernet cables into the wrong sockets and 191 bridging two subnets together, causing a problem similar to VLAN 192 flooding. 194 2.3. Malicious misconfiguration 196 Here an attacker is deliberately generating RAs on the local network 197 in an attempt to perform some form of denial of service or man-in- 198 the-middle attack. 200 As stated above, while this is a genuine concern for network 201 administrators, there have been few if any reports of such activity, 202 while in contrast reports of accidental rogue RAs are very 203 commonplace. In writing this text, and with the feedback of the 204 v6ops WG, we came to the conclusion that the issue of malicious 205 attack, due to the other complementary attacks that are likely to be 206 launched using rogue NA and similar messages, are best considered by 207 further work and document(s). As a result, this text intends to 208 provide informational guidance for operators looking for practical 209 measures to take to avoid 'accidental' rogue RAs on their own 210 networks. 212 3. Methods to Mitigate against Rogue RAs 214 In this section we present a summary of methods suggested to date for 215 reducing or removing the possibility of rogue RAs being seen on a 216 network. 218 3.1. Manual configuration 220 The default gateway and host address can usually be manually 221 configured on a node. This of course can be a resource intensive 222 solution, and also prone to administrative mistakes in itself. 224 Manual configuration implies that RA processing is disabled. Most 225 operating systems allow RA messages to be ignored, such that if an 226 IPv6 address is manually configured on a system, an additional global 227 autoconfigured address will not be added should an unexpected RA 228 appear on the link. 230 3.2. Introduce RA snooping 232 It should be possible to implement 'RA snooping' in Layer 2 switches 233 in a similar way to DHCP snooping, such that RAs observed from 234 incorrect sources are blocked or dropped, and not propagated through 235 a subnet. One candidate solution in this space called RA-Guard 236 [I-D.ietf-v6ops-ra-guard] has been proposed. This type of solution 237 has appeal because it is a familiar model for enterprise network 238 managers, but it can also be used to complement Secure Neighbour 239 Discovery (SeND) [RFC3971], by a switch acting as a SeND proxy for 240 hosts. 242 This type of solution may not be applicable everywhere, e.g. in 243 environments where there are not centrally controlled or manageable 244 switches. 246 3.3. Use ACLs on Managed Switches 248 Certain switch platforms can already implement some level of rogue RA 249 filtering by the administrator configuring Access Control Lists 250 (ACLs) that block RA ICMP messages that might be inbound on 'user' 251 ports. Again this type of 'solution' depends on the presence of such 252 configurable switches. 254 A recent draft describes the RA message format(s) for filtering 255 [I-D.nward-ipv6-autoconfig-filtering-ethernet]. This draft also 256 notes requirements for DHCPv6 snooping, which can then be implemented 257 similar to DHCPv4 snooping. 259 3.4. Secure Neighbor Discovery (SeND) 261 The Secure Neighbor Discovery (SeND) [RFC3971] protocol provides a 262 method for hosts and routers to perform secure Neighbor Discovery. 263 Thus it can in principle protect a network against rogue RAs. 265 SeND is not yet widely used at the time of writing, in part because 266 there are very few implementations of the protocol. Some other 267 deployment issues have been raised, though these are likely to be 268 resolved in due course. For example, routers probably don't want to 269 use autogenerated addresses (which might need to be protected by 270 ACLs) so SeND needs to be shown to work with non autogenerated 271 addresses. Also, it has been argued that there are 'bootstrapping' 272 issues, in that hosts wanting to validate router credentials (e.g. to 273 a certificate server or Network Time Protocol (NTP) server) are 274 likely to need to communicate via the router for that information. 276 Further, it's not wholly clear how widely adopted SeND could or would 277 be in site networks with 'lightweight' security (e.g. many campus 278 networks), especially where hosts are managed by users and not 279 administratively. Public or conference wireless networks may face 280 similar challenges. There may also be networks, like perhaps sensor 281 networks, where use of SeND is less practical. These networks still 282 require rogue RA protection. 284 While SeND clearly can provide a good, longer term solution, 285 especially in networks where malicious activity is a significant 286 concern, there is a requirement today for practical solutions, and/or 287 solutions more readily applicable in more 'relaxed' environments. In 288 the latter case, solutions like 'RA snooping' or applied ACLs are 289 more attractive now. 291 3.5. Router Preference Option 293 [RFC4191] introduced a router preference option, such that an RA 294 could carry one of three router preference values: High, Medium 295 (default) or Low. Thus an administrator could use High settings for 296 managed RAs, and hope that 'accidental' RAs would be medium priority. 297 This of course would only work in some scenarios - if the user who 298 accidentally sends out a rogue RA on the network has configured their 299 device with High precedence for their own intended usage, the 300 priorities would clash. But for accidental rogue RAs caused by 301 software like Windows ICS and 6to4, which would use the default 302 precedence, it could be useful. Obviously this solution would also 303 rely on clients (and routers) having implementations of the Router 304 Preference Option. 306 3.6. Rely on Layer 2 admission control 308 In principle, if a technology such as IEEE 802.1x is used, devices 309 would first need to authenticate to the network before being able to 310 send or receive IPv6 traffic. Ideally authentication would be 311 mutual. Deployment of 802.1x, with mutual authentication, may 312 however be seen as somewhat 'heavyweight' akin to SeND, for some 313 deployments. 315 Improving Layer 2 security may help to mitigate against an attacker's 316 capability to join the network to send RAs, but it doesn't prevent 317 misconfiguration issues. A user can happily authenticate and still 318 launch a Windows ICS service for example. 320 3.7. Use host-based packet filters 322 In a managed environment hosts could be configured via their 323 'personal firewall' to only accept RAs from trusted sources. Hosts 324 could also potentially be configured to discard 6to4-based RAs in a 325 managed enterprise environment. 327 However, the problem is then pushed to keeping this configuration 328 maintained and correct. If a router fails and is replaced, possibly 329 with a new Layer 2 interface address, the link local source address 330 in the filter may become incorrect and thus no method would be 331 available to push the new information to the host over the network. 333 3.8. Use an 'intelligent' deprecation tool 335 It is possible to run a daemon on a link (perhaps on the router on 336 the link) to watch for incorrect RAs and to send a deprecating RA 337 with router lifetime of zero when such an RA is observed. The KAME 338 rafixd is an example of such a tool, which has been used at IETF 339 meetings with some success. A slightly enhanced tool called RAMOND 340 has since been developed from this code, and is now available as a 341 Sourceforge project. As with host based firewalling, the daemon 342 would need to somehow know what 'good' and 'bad' RAs are, from some 343 combination of known good sources and/or link prefixes. In an 344 environment with native IPv6 though, 6to4-based RAs would certainly 345 be known to be rogue. 347 Whether or not use of such a tool is the preferred method, monitoring 348 a link for observed RAs seems prudent from a network management 349 perspective. Some such tools exist already, e.g. NDPMon, which can 350 also detect other undesirable behaviour. 352 3.9. Use Layer 2 Partitioning 354 If each system or user on a network is partitioned into a different 355 Layer 2 medium, then the impact of rogue RAs can be limited. In 356 broadband networks RFC2684 bridging [RFC2684] may be available, for 357 example. The benefit may be scenario-specific, e.g. whether a given 358 user or customer has their own network prefix or whether the 359 provisioning is in a shared subnet or link. It is certainly 360 desirable that any given user or customer's system(s) are unable to 361 see RAs that may be generated by other users or customers. 363 However, such partitioning would probably increase address space 364 consumption significantly if applied in enterprise networks, and in 365 many cases hardware costs and software licensing costs to enable 366 routing to the edge can be quite significant. 368 3.10. Add Default Gateway/Prefix Options to DHCPv6 370 Adding Default Gateway and Prefix options for DHCPv6 would allow 371 network administrators to configure hosts to only use DHCPv6 for 372 default gateway and prefix configuration in managed networks, where 373 RAs would be required today. A new draft has proposed such a default 374 router option, along with prefix advertisement options for DHCPv6 375 [I-D.droms-dhc-dhcpv6-default-router]. Even with such options added 376 to DHCPv6, an RA is in principle still required to inform hosts to 377 use DHCPv6. 379 An advantage of DHCPv6 is that should an error be introduced, only 380 hosts that have refreshed their DHCP information since that time are 381 affected, while a multicast rogue RA will most likely affect all 382 hosts immediately. DHCPv6 also allows different answers to be given 383 to different hosts. 385 While making host configuration possible via DHCPv6 alone is 386 possible, making IPv6 configuration able to be done in a similar way 387 to IPv4 today, the problem has only been shifted. Rather than rogue 388 RAs being the problem, rogue DHCPv6 servers would be an equivalent 389 issue. As with IPv4, a network would then still require use of 390 Authenticated DHCP, or DHCP(v6) snooping, as suggested in 391 [I-D.nward-ipv6-autoconfig-filtering-ethernet]. 393 There is certainly some demand in the community for DHCPv6-only host 394 configuration. While this may mitigate the rogue RA issue, it simply 395 moves the trust problem elsewhere, albeit to a place administrators 396 are familiar with today. 398 4. Scenarios and mitigations 400 In this section we summarise the scenarios and practical mitigations 401 described above in a matrix format. We consider, for the case of a 402 rogue multicast RA, which of the mitigation methods helps protect 403 against administrator and user errors. For the administrator error, 404 we discount an error in configuring the countermeasure itself, rather 405 we consider an administrator error to be an error in configuration 406 elsewhere in the network. 408 +------------------------+-------------+-------------+ 409 | Scenario | Admin | User | 410 | Mitigation | Error | Error | 411 +------------------------+-------------+-------------+ 412 | Manual configuration | Y | Y | 413 +------------------------+-------------+-------------+ 414 | SeND | Y | Y | 415 +------------------------+-------------+-------------+ 416 | RA snooping | Y | Y | 417 +------------------------+-------------+-------------+ 418 | Use switch ACLs | Y | Y | 419 +------------------------+-------------+-------------+ 420 | Router preference | N | Y | 421 +------------------------+-------------+-------------+ 422 | Layer 2 admission | N | N | 423 +------------------------+-------------+-------------+ 424 | Host firewall | Y | Y | 425 +------------------------+-------------+-------------+ 426 | Deprecation daemon | Y | Y | 427 +------------------------+-------------+-------------+ 428 | Layer 2 partition | N | Y | 429 +------------------------+-------------+-------------+ 430 | DHCPv6 gateway option | Partly | If Auth | 431 +------------------------+-------------+-------------+ 433 What the above summary does not consider is the practicality of 434 deploying the measure. An easy-to-deploy method that buys improved 435 resilience to rogue RAs without significant administrative overhead 436 is attractive. On that basis the RA snooping proposal, e.g. RA 437 Guard, has merit, while approaches like manual configuration are less 438 appealing. However RA Guard is not yet fully defined or available, 439 while only certain managed switch equipment may support the required 440 ACLs. 442 5. Other related considerations 444 There are a number of related issues that have come out of 445 discussions on the rogue RA topic, which the authors believe are 446 worth capturing in this document. 448 5.1. Unicast RAs 450 The above discussion was initially held on the assumption that rogue 451 multicast RAs were the cause of problems on a shared network subnet. 452 However, the specifications for Router Advertisements allow them to 453 be sent unicast to a host, as per Section 6.2.6 of RFC4861. If a 454 host sending rogues RAs sends them unicast to the soliciting host, 455 that RA may not be seen by other hosts on the shared medium, e.g. by 456 a monitoring daemon. In most cases though, an accidental rogue RA is 457 likely to be multicast. 459 5.2. The DHCP vs RA threat model 461 Comparing the threat model for rogue RAs and rogue DHCPv6 servers is 462 an interesting exercise. In the case of Windows ICS causing rogue 463 6to4-based RAs to appear on a network, it is very likely that the 464 same host is also acting as a rogue IPv4 DHCP server. The rogue 465 DHCPv4 server can allocate a default gateway and an address to hosts, 466 just as a rogue RA can lead hosts to learning of a new (additional) 467 default gateway, prefix(es) and address. In the case of multicast 468 rogue RAs however, the impact is potentially immediate to all hosts, 469 while the rogue DHCP server's impact will depend on lease timers for 470 hosts. 472 In principle Authenticated DHCP can be used to protect against rogue 473 DHCPv4 (and DHCPv6) servers, just as SeND could be used to protect 474 against rogue IPv6 RAs. However, actual use of Authenticated DHCP in 475 typical networks is currently minimal. Were new DHCPv6 default 476 gateway and prefix options to be standardised as described above, 477 then without Authenticated DHCP the (lack of) security is just pushed 478 to another place. 480 The RA Guard approach is essentially using a similar model to DHCP 481 message snooping to protect against rogue RAs in network (switch) 482 equipment. As noted above, DHCPv6 message snooping would also be 483 very desirable in IPv6 networks. 485 5.3. IPv4-only networks 487 The rogue RA problem should also be considered by administrators and 488 operators of IPv4-only networks, where IPv6 monitoring, firewalling 489 and other related mechanisms may not be in place. 491 For example a comment has been made that in the case of 6to4 being 492 run by a host on a subnet that is not administratively configured 493 with IPv6, some OSes or applications may begin using IPv6 to the 6to4 494 host (router) rather than IPv4 to the intended default IPv4 router, 495 because they have IPv6 enabled by default and some applications 496 prefer IPv6 by default. Technically aware users may also 497 deliberately choose to use IPv6, possibly for subversive reasons. 498 Mitigating against this condition can also be seen to be important. 500 5.4. Network monitoring tools 502 It would generally be prudent for network monitoring or management 503 platforms to be able to observe and report on observed RAs, and 504 whether unintended RAs (possibly from unintended sources) are present 505 on a network. Further, it may be useful for individual hosts to be 506 able to report their address status (assuming their configuration 507 status allowed it of course), e.g. this could be useful during an 508 IPv6 renumbering phased process as described in RFC4192 [RFC4192]. 510 The above assumes, of course, that what defines a 'good' (or 'bad') 511 RA can be configured in a trustworthy manner within the network's 512 management framework. 514 5.5. Recovering from bad configuration state 516 After a host receives and processes a rogue RA, it may have multiple 517 default gateways, global addresses, and potentially clashing RA 518 options (e.g. M/O bits). The host's behaviour may then be 519 unpredictable, in terms of the default router that is used, and the 520 (source) address(es) used in communications. A host that is aware of 521 protocols such as shim6 RFC5533 [RFC5533] may believe it is genuinely 522 multihomed. 524 An important issue is how readily a host can recover from receiving 525 and processing bad configuration information, e.g. considering the '2 526 hour rule' of Section 5.5.3 of RFC4862 (though this applies to the 527 valid address lifetime not the router lifetime). We should ensure 528 that methods exist for a network administrator to correct bad 529 configuration information on a link or subnet, and that OS platforms 530 support these methods. At least if the problem can be detected, and 531 corrected promptly, the impact is minimised. 533 5.6. Isolating the offending rogue RA source 535 In addition to issuing a deprecating RA, it would be desirable to 536 isolate the offending source of the rogue RA from the network. It 537 may be possible to use Network Access Control methods to quarantine 538 the offending host, or rather the network point of attachment or port 539 that it is using. 541 6. Conclusions 543 In this text we have described scenarios via which rogue Router 544 Advertisements (RAs) may appear on a network, and some measures that 545 could be used to mitigate against these. We have also noted some 546 related issues that have arisen in the rogue RA discussions. Our 547 discussion is generally focused on the assumption that rogue RAs are 548 appearing as a result of accidental misconfiguration on the network, 549 by a user or administrator. 551 While SeND perhaps offers the most robust solution, implementations 552 and deployment guidelines are not yet widely available. SeND is very 553 likely to be a good, longer term solution, but many administrators 554 are seeking solutions today. Such administrators are also often in 555 networks with security models for which SeND is a 'heavyweight' 556 solution, e.g. campus networks, or wireless conference or public 557 networks. For such scenarios, simpler measures are desirable. 559 Adding new DHCPv6 Default Gateway and Prefix Options would allow IPv6 560 host configuration by DHCP only, and be a method that IPv4 561 administrators are comfortable with (for better or worse), but this 562 simply shifts the robustness issue elsewhere. 564 While a number of the mitigations described above have their appeal, 565 the simplest solutions probably lie in switch-based ACLs and RA-Guard 566 style approaches. Where managed switches are not available, use of 567 the Router Preference option and (more so in managed desktop 568 environments) host firewalls may be appropriate. 570 In the longer term wider experience of SeND will be beneficial, while 571 the use of RA snooping will remain useful either to complement SeND 572 (where a switch running RA Guard can potentially be a SeND proxy) or 573 to assist in scenarios for which SeND is not deployed. 575 7. Security Considerations 577 This Informational document is focused on discussing solutions to 578 operational problems caused by rogue RAs resulting from unintended 579 misconfiguration by users or administrators. Earlier versions of 580 this text included some analysis of rogue RAs introduced maliciously, 581 e.g. by including an extra column in the table in Section 4. 582 However, the consensus of the v6ops WG feedback was to instead focus 583 on the common operational problem seen today, of 'accidental' rogue 584 RAs. 586 Thus the final version of this text does not address attacks on a 587 network where rogue RAs are intentionally introduced as part of a 588 broader attack, e.g. including malicious NA messages. On the wire, 589 malicious rogue RAs will generally look the same as 'accidental' 590 ones, though they are more likely, for example, to spoof the MAC or 591 IPv6 source address of the genuine router, or to use a High router 592 preference option. It is also likely that malicious rogue RAs will 593 be accompanied by other attacks on the IPv6 infrastructure, making 594 discussion of mitigations more complex. Administrators may be able 595 to detect such activity by use of tools such as NDPMon. 597 It is worth noting that the deprecation daemon could be used as part 598 of a denial of service attack, should the tool be used to deprecate 599 the genuine RA. 601 8. IANA Considerations 603 There are no extra IANA consideration for this document. 605 9. Acknowledgments 607 Thanks are due to members of the IETF IPv6 Operations and DHCP WGs 608 for their inputs on this topic, as well as some comments from various 609 operational mailing lists, and private comments, including but not 610 limited to: Iljitsch van Beijnum, Dale Carder, Remi Denis-Courmont, 611 Tony Hain, Bob Hinden, Christian Huitema, Tatuya Jinmei, Eric Levy- 612 Abegnoli, David Malone, Thomas Narten, Chip Popoviciu, Dave Thaler, 613 Gunter Van de Velde, Goeran Weinholt and Dan White. 615 10. Informative References 617 [RFC2684] Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation 618 over ATM Adaptation Layer 5", RFC 2684, September 1999. 620 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 621 via IPv4 Clouds", RFC 3056, February 2001. 623 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 624 and M. Carney, "Dynamic Host Configuration Protocol for 625 IPv6 (DHCPv6)", RFC 3315, July 2003. 627 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 628 (DHCP) Service for IPv6", RFC 3736, April 2004. 630 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 631 Neighbor Discovery (SEND)", RFC 3971, March 2005. 633 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 634 More-Specific Routes", RFC 4191, November 2005. 636 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 637 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 638 September 2005. 640 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 641 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 642 September 2007. 644 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 645 Address Autoconfiguration", RFC 4862, September 2007. 647 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 648 Shim Protocol for IPv6", RFC 5533, June 2009. 650 [I-D.ietf-v6ops-ra-guard] 651 Levy-Abegnoli, E., Velde, G., Popoviciu, C., and J. 652 Mohacsi, "IPv6 Router Advertisement Guard", 653 draft-ietf-v6ops-ra-guard-08 (work in progress), 654 September 2010. 656 [I-D.nward-ipv6-autoconfig-filtering-ethernet] 657 Ward, N., "IPv6 Autoconfig Filtering on Ethernet 658 Switches", 659 draft-nward-ipv6-autoconfig-filtering-ethernet-00 (work in 660 progress), March 2009. 662 [I-D.droms-dhc-dhcpv6-default-router] 663 Droms, R. and T. Narten, "Default Router and Prefix 664 Advertisement Options for DHCPv6", 665 draft-droms-dhc-dhcpv6-default-router-00 (work in 666 progress), March 2009. 668 Authors' Addresses 670 Tim Chown 671 University of Southampton 672 Highfield 673 Southampton, Hampshire SO17 1BJ 674 United Kingdom 676 Email: tjc@ecs.soton.ac.uk 678 Stig Venaas 679 Cisco Systems 680 Tasman Drive 681 San Jose, CA 95134 682 USA 684 Email: stig@cisco.com