idnits 2.17.1 draft-ietf-v6ops-rogue-ra-01.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 (June 7, 2010) is 5073 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) == Outdated reference: A later version (-08) exists of draft-ietf-v6ops-ra-guard-05 Summary: 0 errors (**), 0 flaws (~~), 3 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: December 9, 2010 UNINETT 6 June 7, 2010 8 Rogue IPv6 Router Advertisement Problem Statement 9 draft-ietf-v6ops-rogue-ra-01 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 December 9, 2010. 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 . . . . . . . . . . . . . . . 6 83 3.4. Secure Neighbor Discovery (SeND) . . . . . . . . . . . . . 7 84 3.5. Router Preference Option . . . . . . . . . . . . . . . . . 7 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. Wait before using new advertisements . . . . . . . . . . . 9 89 3.10. Use Layer 2 Partitioning . . . . . . . . . . . . . . . . . 9 90 3.11. Add Default Gateway/Prefix Options to DHCPv6 . . . . . . . 9 91 4. Scenarios and mitigations . . . . . . . . . . . . . . . . . . 10 92 5. Other related considerations . . . . . . . . . . . . . . . . . 11 93 5.1. Unicast RAs . . . . . . . . . . . . . . . . . . . . . . . 11 94 5.2. The DHCP vs RA threat model . . . . . . . . . . . . . . . 12 95 5.3. IPv4-only networks . . . . . . . . . . . . . . . . . . . . 12 96 5.4. Network monitoring tools . . . . . . . . . . . . . . . . . 13 97 5.5. Recovering from bad configuration state . . . . . . . . . 13 98 5.6. Isolating the offending rogue RA source . . . . . . . . . 13 99 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 13 100 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 101 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 102 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 103 10. Informative References . . . . . . . . . . . . . . . . . . . . 15 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 106 1. Introduction 108 The Neighbor Discovery protocol [RFC4861] describes the operation of 109 IPv6 Router Advertisements (RAs) which are used to determine node 110 configuration information during the IPv6 autoconfiguration process, 111 whether that node's configuration is stateful (via DHCPv6 [RFC3315]) 112 or stateless (as per [RFC4862], possibly in combination with DHCPv6 113 Light [RFC3736]). 115 In observing the operation of deployed IPv6 networks, it is apparent 116 that there is a problem with undesired or 'bogus' IPv6 Router 117 Advertisements (RAs) appearing on network links or subnets. By 118 'bogus' we mean RAs that were not the intended configured RAs, rather 119 RAs that have appeared for some other reason. While the problem 120 appears more common in shared wireless environments, it is also seen 121 on wired enterprise networks. 123 The problem with rogue RAs is that they can cause partial or complete 124 failure of operation of hosts on an IPv6 link. For example, the 125 default router address is drawn directly from the source address of 126 the RA message. In addition, rogue RAs can cause hosts to assume 127 wrong prefixes to be used for stateless address autoconfiguration. 128 In a case where there may be mixing of 'good' and 'bad' RAs, a host 129 might keep on using the 'good' default gateway, but pick a wrong 130 source address, leading to egress filtering problems. As such, rogue 131 RAs are an operational issue for which solution(s) are required, and 132 for which best practice needs to be conveyed. This not only includes 133 preventing or detecting rogue RAs, but also where necessary ensuring 134 the network (and hosts on the network) have the ability to quickly 135 recover from a state where host configuration is incorrect as a 136 result of processing such an RA. 138 In the next section, we discuss the scenarios that may give rise to 139 rogue RAs being present. In the following section we present some 140 candidate solutions for the problem, some of which may be more 141 practical to deploy than others. This document focuses on 142 'accidental' rogue RAs; while malicious RAs are of course also 143 possible, the common problem today lies with unintended RAs. In 144 addition a network experiencing malicious attack of this kind is 145 likely to also experience malicious NA and 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 VLAN misconfiguration, RAs may 'flood' to 164 unintended links, causing hosts or more than one link to potentially 165 become incorrectly multiaddressed, with possibly two different 166 default routers available. 168 2.2. User misconfiguration 170 In this case a user's device 'accidentally' transmits RAs onto the 171 local link, potentially adding an additional default gateway and 172 associated prefix information. 174 This seems to typically be seen on wireless (though sometimes wired) 175 networks where a laptop has enabled the Windows Internet Connection 176 Sharing service (ICS) which turns a host into a 6to4 [RFC3056] 177 gateway; this can be a useful feature, unless of course it is run 178 when not intended. This service can also cause IPv4 problems too, as 179 it will typically start a 'rogue' DHCPv4 server on the host. 181 We have also had reports that hosts may not see genuine IPv6 RAs on a 182 link due to host firewalls, causing them to turn on a connection 183 sharing service and 6to4 as a result. In some cases more technical 184 users may also use a laptop as a home gateway (e.g. again a 6to4 185 gateway) and then connect to another network forgetting their 186 previous gateway configuration is still active. 188 There are also reported incidents in enterprise networks of users 189 physically plugging Ethernet cables into the wrong sockets and 190 bridging two subnets together, causing a problem similar to VLAN 191 flooding. 193 2.3. Malicious misconfiguration 195 Here an attacker is deliberately generating RAs on the local network 196 in an attempt to perform some form of denial of service or man-in- 197 the-middle attack. 199 As stated above, while this is a genuine concern for network 200 administrators, there have been few if any reports of such activity, 201 while in contrast reports of accidental rogue RAs are very 202 commonplace. In writing this text we came to the conclusion that the 203 issue of malicious attack, due to the other complementary attacks 204 that are likely to be launched using rogue NA and similar messages, 205 are best considered elsewhere. As a result, this text intends to 206 provide informational guidance for operators looking for practical 207 measures to take to avoid unintended rogue RAs on their own networks. 209 3. Methods to Mitigate against Rogue RAs 211 In this section we present a summary of methods suggested to date for 212 reducing or removing the possibility of rogue RAs being seen on a 213 network. 215 3.1. Manual configuration 217 The default gateway and host address can usually be manually 218 configured on a node. This is of course can be a resource intensive 219 solution, and also prone to administrative mistakes in itself. 221 Manual configuration implies that RA processing is disabled. Most 222 operating systems allow RA messages to be ignored, such that if an 223 IPv6 address is manually configured on a system, an additional global 224 autoconfigured address will not be added should an unexpected RA 225 appear on the link. 227 3.2. Introduce RA snooping 229 It should be possible to implement 'RA snooping' in Layer 2 switches 230 in a similar way to DHCP snooping, such that RAs observed from 231 incorrect sources are blocked or dropped, and not propagated through 232 a subnet. One candidate solution in this space called RA-Guard 233 [I-D.ietf-v6ops-ra-guard] has been proposed. This type of solution 234 has appeal because it is a familiar model for enterprise network 235 managers, but it can also be used to complement SeND, by a switch 236 acting as a SeND proxy for hosts. 238 This type of solution may not be applicable everywhere, e.g. in 239 environments where there are not centrally controlled or manageable 240 switches. 242 3.3. Use ACLs on Managed Switches 244 Certain switch platforms can already implement some level of rogue RA 245 filtering by the administrator configuring Access Control Lists 246 (ACLs) that block RA ICMP messages that might be inbound on 'user' 247 ports. Again this type of 'solution' depends on the presence of such 248 configurable switches. 250 A recent draft describes the RA message format(s) for filtering 251 [I-D.nward-ipv6-autoconfig-filtering-ethernet]. This draft also 252 notes requirements for DHCPv6 snooping, which can then be implemented 253 similar to DHCPv4 snooping. 255 3.4. Secure Neighbor Discovery (SeND) 257 The Secure Neighbor Discovery (SeND) [RFC3971] protocol provides a 258 method for hosts and routers to perform secure Neighbor Discovery. 259 Thus it can in principle protect a network against rogue RAs. 261 SeND is not yet widely used at the time of writing, in part because 262 there are very few implementations of the protocol. Some other 263 deployment issues have been raised, though these are likely to be 264 resolved in due course. For example, routers probably don't want to 265 use autogenerated addresses (which might need to be protected by 266 ACLs) so SeND needs to be shown to work with non autogenerated 267 addresses. Also, it has been argued that there are 'bootstrapping' 268 issues, in that hosts wanting to validate router credentials (e.g. to 269 a certificate server or NTP server) are likely to need to communicate 270 via the router for that information. 272 Further, it's not wholly clear how widely adopted SeND could or would 273 be in site networks with 'lightweight' security (e.g. many campus 274 networks), especially where hosts are managed by users and not 275 administratively. Public or conference wireless networks may face 276 similar challenges. There may also be networks, like perhaps sensor 277 networks, where use of SeND is less practical. These networks still 278 require rogue RA protection. 280 While SeND clearly can provide a good, longer term solution, 281 especially in networks where malicious activity is a significant 282 concern, there is a requirement today for practical solutions, and/or 283 solutions more readily applicable in more 'relaxed' environments. In 284 the latter case, solutions like 'RA snooping' or applied ACLs are 285 more attractive now. 287 3.5. Router Preference Option 289 [RFC4191] introduced a router preference option, such that an RA 290 could carry one of three router preference values: High, Medium 291 (default) or Low. Thus an administrator could use High settings for 292 managed RAs, and hope that 'accidental' RAs would be medium priority. 293 This of course would only work in some scenarios - if the user who 294 accidentally sends out a rogue RA on the network has configured their 295 device with High precedence for their own intended usage, the 296 priorities would clash. But for accidental problems like Windows ICS 297 and 6to4, it could be useful. Obviously this solution would also 298 rely on clients (and routers) having implementations of the protocol. 300 3.6. Rely on Layer 2 admission control 302 In principle, if a technology such as IEEE 802.1x is used, devices 303 would first need to authenticate to the network before being able to 304 send or receive IPv6 traffic. Ideally authentication would be 305 mutual. Deployment of 802.1x, with mutual authentication, may 306 however be seen as somewhat 'heavyweight' akin to SeND, for some 307 deployments. 309 Improving Layer 2 security may help to mitigate against an attacker's 310 capability to join the network to send RAs, but it doesn't prevent 311 misconfiguration issues. A user can happily authenticate and still 312 launch a Windows ICS service for example. 314 3.7. Use host-based packet filters 316 In a managed environment hosts could be configured via their 317 'personal firewall' to only accept RAs from trusted sources. Hosts 318 could also potentially be configured to discard 6to4-based RAs in a 319 managed enterprise environment. 321 However, the problem is then pushed to keeping this configuration 322 maintained and correct. If a router fails and is replaced, possibly 323 with a new Layer 2 interface address, the link local source address 324 in the filter may become incorrect and thus no method would be 325 available to push the new information to the host over the network. 327 3.8. Use an 'intelligent' deprecation tool 329 It is possible to run a daemon on a link (perhaps on the router on 330 the link) to watch for incorrect RAs and to send a deprecating RA 331 with router lifetime of zero when such an RA is observed. The KAME 332 rafixd is an example of such a tool, which has been used at IETF 333 meetings with some success. A slightly enhanced tool called RAMOND 334 has since been developed from this code, and is now available as a 335 Sourceforge project. As with host based firewalling, the daemon 336 would need to somehow know what 'good' and 'bad' RAs are, from some 337 combination of known good sources and/or link prefixes. In an 338 environment with native IPv6 though, 6to4-based RAs would certainly 339 be known to be rogue. 341 Whether or not use of such a tool is the preferred method, monitoring 342 a link for observed RAs seems prudent from a network management 343 perspective. Some such tools exist already, e.g. NDPMon, which can 344 also detect other undesirable behaviour. 346 3.9. Wait before using new advertisements 348 It might be possible, in networks where configurations are very 349 static and systems generally remain up, to configure an option such 350 that any new RAs that are seen are not acted upon for a certain 351 period, e.g. 2 hours. This might allow time for a misconfiguration 352 or accidental RA to be detected and stopped, before hosts use the 353 data in the RA. Of course this would add delays where genuine new 354 RAs are required, while new hosts appearing on a network would still 355 be vulnerable (or be unable to configure at all). In general, this 356 does not seem to be an attractive solution. 358 3.10. Use Layer 2 Partitioning 360 If each system or user on a network is partitioned into a different 361 Layer 2 medium, then the impact of rogue RAs can be limited. In 362 broadband networks RFC2684 bridging [RFC2684] may be available, for 363 example. The benefit may be scenario-specific, e.g. whether a given 364 user or customer has their own network prefix or whether the 365 provisioning is in a shared subnet or link. It is certainly 366 desirable that any given user or customer's system(s) are unable to 367 see RAs that may be generated by other users or customers. 369 However, such partitioning would probably increase address space 370 consumption significantly if applied in enterprise networks, and in 371 many cases hardware costs and software licensing costs to enable 372 routing to the edge can be quite significant. 374 3.11. Add Default Gateway/Prefix Options to DHCPv6 376 Adding Default Gateway and Prefix options for DHCPv6 would allow 377 network administrators to configure hosts to only use DHCPv6 for 378 default gateway and prefix configuration in managed networks, where 379 RAs would be required today. A new draft has proposed such a default 380 router option, along with prefix advertisement options for DHCPv6 381 [I-D.droms-dhc-dhcpv6-default-router]. Even with such options added 382 to DHCPv6, an RA is in principle still required to inform hosts to 383 use DHCPv6. 385 An advantage of DHCPv6 is that should an error be introduced, only 386 hosts that have refreshed their DHCP information since that time are 387 affected, while a multicast rogue RA will most likely affect all 388 hosts immediately. DHCPv6 also allows different answers to be given 389 to different hosts. 391 While making host configuration possible via DHCPv6 alone is 392 possible, making IPv6 configuration able to be done in a similar way 393 to IPv4 today, the problem has only been shifted. Rather than rogue 394 RAs being the problem, rogue DHCPv6 servers would be an equivalent 395 issue. As with IPv4, a network would then still require use of 396 Authenticated DHCP, or DHCP(v6) snooping, as suggested in 397 [I-D.nward-ipv6-autoconfig-filtering-ethernet]. 399 There is certainly some demand in the community for DHCPv6-only host 400 configuration. While this may mitigate the rogue RA issue, it simply 401 moves the trust problem elsewhere, albeit to a place administrators 402 are familiar with today. 404 4. Scenarios and mitigations 406 In this section we summarise the scenarios and practical mitigations 407 described above in a matrix format. We consider, for the case of a 408 rogue multicast RA, which of the mitigation methods helps protect 409 against each cause. For the administrator error, we discount an 410 error in configuring the countermeasure itself, rather we consider an 411 administrator error to be an error in configuration elsewhere in the 412 network. 414 +------------------------+-------------+-------------+ 415 | Scenario | Admin | User | 416 | Mitigation | Error | Error | 417 +------------------------+-------------+-------------+ 418 | Manual configuration | Y | Y | 419 +------------------------+-------------+-------------+ 420 | SeND | Y | Y | 421 +------------------------+-------------+-------------+ 422 | RA snooping | Y | Y | 423 +------------------------+-------------+-------------+ 424 | Use switch ACLs | Y | Y | 425 +------------------------+-------------+-------------+ 426 | Router preference | N | Y | 427 +------------------------+-------------+-------------+ 428 | Layer 2 admission | N | N | 429 +------------------------+-------------+-------------+ 430 | Host firewall | Y | Y | 431 +------------------------+-------------+-------------+ 432 | Deprecation daemon | Y | Y | 433 +------------------------+-------------+-------------+ 434 | New prefix delay | Partly | Partly | 435 +------------------------+-------------+-------------+ 436 | Layer 2 partition | N | Y | 437 +------------------------+-------------+-------------+ 438 | DHCPv6 gateway option | Partly | If Auth | 439 +------------------------+-------------+-------------+ 441 What the above summary does not consider is the practicality of 442 deploying the measure. An easy-to-deploy method that buys improved 443 resilience to rogue RAs without significant administrative overhead 444 is attractive. On that basis the RA snooping proposal, e.g. RA 445 Guard, has merit, while approaches like manual configuration are less 446 appealing. However RA Guard is not yet fully defined or available, 447 while only certain managed switch equipment may support the required 448 ACLs. 450 5. Other related considerations 452 There are a number of related issues that have come out of 453 discussions on the rogue RA topic, which the authors believe are 454 worth capturing in this document. 456 5.1. Unicast RAs 458 The above discussion was initially held on the assumption that rogue 459 multicast RAs were the cause of problems on a shared network subnet. 460 However, the specifications for Router Advertisements allow them to 461 be sent unicast to a host, as per Section 6.2.6 of RFC4861. If a 462 host sending rogues RAs sends them unicast to the soliciting host, 463 that RA may not be seen by other hosts on the shared medium, e.g. by 464 a monitoring daemon. In most cases though, an accidental rogue RA is 465 likely to be multicast. 467 5.2. The DHCP vs RA threat model 469 Comparing the threat model for rogue RAs and rogue DHCPv6 servers is 470 an interesting exercise. In the case of Windows ICS causing rogue 471 6to4-based RAs to appear on a network, it is very likely that the 472 same host is also acting as a rogue IPv4 DHCP server. The rogue 473 DHCPv4 server can allocate a default gateway and an address to hosts, 474 just as a rogue RA can lead hosts to learning of a new (additional) 475 default gateway, prefix(es) and address. In the case of multicast 476 rogue RAs however, the impact is potentially immediate to all hosts, 477 while the rogue DHCP server's impact will depend on lease timers for 478 hosts. 480 In principle Authenticated DHCP can be used to protect against rogue 481 DHCPv4 (and DHCPv6) servers, just as SeND could be used to protect 482 against rogue IPv6 RAs. However, actual use of Authenticated DHCP in 483 typical networks is currently minimal. Were new DHCPv6 default 484 gateway and prefix options to be standardised as described above, 485 then without Authenticated DHCP the (lack of) security is just pushed 486 to another place. 488 The RA Guard approach is essentially using a similar model to DHCP 489 message snooping to protect against rogue RAs in network (switch) 490 equipment. As noted above, DHCPv6 message snooping would also be 491 very desirable in IPv6 networks. 493 5.3. IPv4-only networks 495 The rogue RA problem should also be considered by administrators and 496 operators of IPv4-only networks, where IPv6 monitoring, firewalling 497 and other related mechanisms may not be in place. 499 For example a comment has been made that in the case of 6to4 being 500 run by a host on a subnet that is not administratively configured 501 with IPv6, some OSes or applications may begin using IPv6 to the 6to4 502 host (router) rather than IPv4 to the intended default IPv4 router, 503 because they have IPv6 enabled by default and some applications 504 prefer IPv6 by default. Technically aware users may also 505 deliberately choose to use IPv6, possibly for subversive reasons. 506 Mitigating against this condition can also be seen to be important. 508 5.4. Network monitoring tools 510 It would generally be prudent for network monitoring or management 511 platforms to be able to observe and report on observed RAs, and 512 whether unintended RAs (possibly from unintended sources) are present 513 on a network. Further, it may be useful for individual hosts to be 514 able to report their address status (assuming their configuration 515 status allowed it of course), e.g. this could be useful during an 516 IPv6 renumbering phased process as described in RFC4192 [RFC4192]. 518 The above assumes, of course, that what defines a 'good' (or 'bad') 519 RA can be configured in a trustworthy manner within the network's 520 management framework. 522 5.5. Recovering from bad configuration state 524 After a host receives and processes a rogue RA, it may have multiple 525 default gateways, global addresses, and potentially clashing RA 526 options (e.g. M/O bits). The host's behaviour may then be 527 unpredictable, in terms of the default router that is used, and the 528 (source) address(es) used in communications. A host that is aware of 529 protocols such as shim6 may believe it is genuinely multihomed. 531 An important issue is how readily a host can recover from receiving 532 and processing bad configuration information, e.g. considering the '2 533 hour rule' of Section 5.5.3 of RFC4862 (though this applies to the 534 valid address lifetime not the router lifetime). We should ensure 535 that methods exist for a network administrator to correct bad 536 configuration information on a link or subnet, and that OS platforms 537 support these methods. At least if the problem can be detected, and 538 corrected promptly, the impact is minimised. 540 5.6. Isolating the offending rogue RA source 542 In addition to issuing a deprecating RA, it would be desirable to 543 isolate the offending source of the rogue RA from the network. It 544 may be possible to use Network Access Control methods to quarantine 545 the offending host, or rather the network point of attachment or port 546 that it is using. 548 6. Conclusions 550 In this text we have described scenarios via which rogue Router 551 Advertisements (RAs) may appear on a network, and some measures that 552 could be used to mitigate against these. We have also noted some 553 related issues that have arisen in the rogue RA discussions. Our 554 discussion is generally focused on the assumption that rogue RAs are 555 appearing as a result of accidental misconfiguration on the network, 556 by a user or administrator. 558 While SeND perhaps offers the most robust solution, implementations 559 and deployment guidelines are not yet widely available. SeND is very 560 likely to be a good, longer term solution, but many administrators 561 are seeking solutions today. Such administrators are also often in 562 networks with security models for which SeND is a 'heavyweight' 563 solution, e.g. campus networks, or wireless conference or public 564 networks. For such scenarios, simpler measures are desirable. 566 Adding new DHCPv6 Default Gateway and Prefix Options would allow IPv6 567 host configuration by DHCP only, and be a method that IPv4 568 administrators are comfortable with (for better or worse), but this 569 simply shifts the robustness issue elsewhere. 571 While a number of the mitigations described above have their appeal, 572 the simplest solutions probably lie in switch-based ACLs and RA-Guard 573 style approaches. Where managed switches are no available, use of 574 the Router Preference option and (moreso in managed desktop 575 environments) host firewalls may be appropriate. 577 In the longer term wider experience of SeND will be beneficial, while 578 the use of RA snooping will remain useful either to complement SeND 579 (where a switch running RA Guard can potentially be a SeND proxy) or 580 to assist in scenarios for which SeND is not deployed. 582 7. Security Considerations 584 This document is Informational. It does not describe solutions for 585 malicious attacks on a network for which malicious RAs may be part of 586 a broader attack, e.g. including malicious NA messages. 588 8. IANA Considerations 590 There are no extra IANA consideration for this document. 592 9. Acknowledgments 594 Thanks are due to members of the IETF IPv6 Operations and DHCP WGs 595 for their inputs on this topic, as well as some comments from various 596 operational mailing lists, and private comments, including but not 597 limited to: Iljitsch van Beijnum, Dale Carder, Remi Denis-Courmont, 598 Tony Hain, Bob Hinden, Christian Huitema, Tatuya Jinmei, Eric Levy- 599 Abegnoli, David Malone, Thomas Narten, Chip Popoviciu, Dave Thaler, 600 Gunter Van de Velde, Goeran Weinholt and Dan White. 602 10. Informative References 604 [RFC2684] Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation 605 over ATM Adaptation Layer 5", RFC 2684, September 1999. 607 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 608 via IPv4 Clouds", RFC 3056, February 2001. 610 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 611 and M. Carney, "Dynamic Host Configuration Protocol for 612 IPv6 (DHCPv6)", RFC 3315, July 2003. 614 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 615 (DHCP) Service for IPv6", RFC 3736, April 2004. 617 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 618 Neighbor Discovery (SEND)", RFC 3971, March 2005. 620 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 621 More-Specific Routes", RFC 4191, November 2005. 623 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 624 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 625 September 2005. 627 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 628 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 629 September 2007. 631 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 632 Address Autoconfiguration", RFC 4862, September 2007. 634 [I-D.ietf-v6ops-ra-guard] 635 Levy-Abegnoli, E., Velde, G., Popoviciu, C., and J. 636 Mohacsi, "IPv6 RA-Guard", draft-ietf-v6ops-ra-guard-05 637 (work in progress), May 2010. 639 [I-D.nward-ipv6-autoconfig-filtering-ethernet] 640 Ward, N., "IPv6 Autoconfig Filtering on Ethernet 641 Switches", 642 draft-nward-ipv6-autoconfig-filtering-ethernet-00 (work in 643 progress), March 2009. 645 [I-D.droms-dhc-dhcpv6-default-router] 646 Droms, R. and T. Narten, "Default Router and Prefix 647 Advertisement Options for DHCPv6", 648 draft-droms-dhc-dhcpv6-default-router-00 (work in 649 progress), March 2009. 651 Authors' Addresses 653 Tim Chown 654 University of Southampton 655 Highfield 656 Southampton, Hampshire SO17 1BJ 657 United Kingdom 659 Email: tjc@ecs.soton.ac.uk 661 Stig Venaas 662 UNINETT 663 Trondheim NO 7465 664 Norway 666 Email: venaas@uninett.no