idnits 2.17.1 draft-chown-v6ops-rogue-ra-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, 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 (March 9, 2009) is 5498 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 1483 (Obsoleted by RFC 2684) -- 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-02 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 5 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: September 10, 2009 UNINETT 6 March 9, 2009 8 Rogue IPv6 Router Advertisement Problem Statement 9 draft-chown-v6ops-rogue-ra-03 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. This document may contain material 15 from IETF Documents or IETF Contributions published or made publicly 16 available before November 10, 2008. The person(s) controlling the 17 copyright in some of this material may not have granted the IETF 18 Trust the right to allow modifications of such material outside the 19 IETF Standards Process. Without obtaining an adequate license from 20 the person(s) controlling the copyright in such materials, this 21 document may not be modified outside the IETF Standards Process, and 22 derivative works of it may not be created outside the IETF Standards 23 Process, except to format it for publication as an RFC or to 24 translate it into languages other than English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on September 10, 2009. 44 Copyright Notice 46 Copyright (c) 2009 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents in effect on the date of 51 publication of this document (http://trustee.ietf.org/license-info). 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. 55 Abstract 57 When deploying IPv6, whether IPv6-only or dual-stack, routers are 58 configured to send IPv6 Router Advertisements to convey information 59 to nodes that enable them to autoconfigure on the network. This 60 information includes the implied default router address taken from 61 the observed source address of the Router Advertisement (RA) message, 62 as well as on-link prefix information. However, unintended 63 misconfigurations by users or administrators, or possibly malicious 64 attacks on the network, may lead to bogus RAs being present, which in 65 turn can cause operational problems for hosts on the network. In 66 this draft we summarise the scenarios in which rogue RAs may be 67 observed and present a list of possible solutions to the problem. We 68 focus on the unintended causes of rogue RAs in the text. The goal of 69 this text is to be Informational, and as such to present a framework 70 around which solutions can be proposed and discussed. 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 also. 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 for their SLAAC addresses. In a case where there may 128 be mixing of 'good' and 'bad' RAs, a host might keep on using the 129 'good' default gateway, but pick a wrong source address, leading to 130 egress filtering problems. As such, rogue RAs are an operational 131 issue for which solution(s) are required, and for which best practice 132 needs to be conveyed. This not only includes preventing or detecting 133 rogue RAs, but also where necessary ensuring the network (and hosts 134 on the network) have the ability to quickly recover from a state 135 where host configuration is incorrect as a result of processing such 136 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 an 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 send 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 no 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 In contrast though, an attacker might use such a tool to learn about 342 prefixes being advertised on a link and to deprecate the 'good' RA(s) 343 in favour of their bogus RA(s). 345 Whether or not use of such a tool is the preferred method, monitoring 346 a link for observed RAs seems prudent from a network management 347 perspective. Some such tools exist already, e.g. NDPMon, which can 348 also detect other undesirable behaviour. 350 3.9. Wait before using new advertisements 352 It might be possible, in networks where configurations are very 353 static and systems generally remain up, to configure an option such 354 that any new RAs that are seen are not acted upon for a certain 355 period, e.g. 2 hours. This might allow time for a misconfiguration 356 or accidental RA to be detected and stopped, before hosts use the 357 data in the RA. Of course this would add delays where genuine new 358 RAs are required, while new hosts appearing on a network would still 359 be vulnerable (or be unable to configure at all). In general, this 360 does not seem to be an attractive solution. 362 3.10. Use Layer 2 Partitioning 364 If each system or user on a network is partitioned into a different 365 Layer 2 medium, then the impact of rogue RAs can be limited. In 366 broadband networks RFC1483 bridging [RFC1483] may be available, for 367 example. The benefit may be scenario-specific, e.g. whether a given 368 user or customer has their own network prefix or whether the 369 provisioning is in a shared subnet or link. It is certainly 370 desirable that any given user or customer's system(s) are unable to 371 see RAs that may be generated by other users or customers. 373 However, such partitioning would probably increase address space 374 consumption significantly if applied in enterprise networks, and in 375 many cases hardware costs and software licensing costs to enable 376 routing to the edge can be quite significant. 378 3.11. Add Default Gateway/Prefix Options to DHCPv6 380 Adding Default Gateway and Prefix options for DHCPv6 would allow 381 network administrators to configure hosts to only use DHCPv6 for 382 default gateway and prefix configuration in managed networks, where 383 RAs would be required today. A new draft has proposed such a default 384 router option, along with prefix advertisement options for DHCPv6 385 [I-D.droms-dhc-dhcpv6-default-router]. Even with such options added 386 to DHCPv6, an RA is in principle still required to inform hosts to 387 use DHCPv6. 389 An advantage of DHCPv6 is that should an error be introduced, only 390 hosts that have refreshed their DHCP information since that time are 391 affected, while a multicast rogue RA will most likely affect all 392 hosts immediately. DHCPv6 also allows different answers to be given 393 to different hosts. 395 While making host configuration possible via DHCPv6 alone is 396 possible, making IPv6 configuration able to be done in a similar way 397 to IPv4 today, the problem has only been shifted. Rather than rogue 398 RAs being the problem, rogue DHCPv6 servers would be an equivalent 399 issue. As with IPv4, a network would then still require use of 400 Authenticated DHCP, or DHCP(v6) snooping, as suggested in 401 [I-D.nward-ipv6-autoconfig-filtering-ethernet]. 403 There is certainly some demand in the community for DHCPv6-only host 404 configuration. While this may mitigate the rogue RA issue, it simply 405 moves the trust problem elsewhere, albeit to a place administrators 406 are familiar with today. 408 4. Scenarios and mitigations 410 In this section we summarise the scenarios and practical mitigations 411 described above in a summary matrix. We consider, for the case of a 412 rogue multicast RA, which of the mitigation methods protects against 413 each cause. For the administrator error, we discount an error in 414 configuring the countermeasure itself, rather we consider an 415 administrator error to be an error in configuration elsewhere in the 416 network. 418 +------------------------+-------------+-------------+ 419 | Scenario | Admin | User | 420 | Mitigation | Error | Error | 421 +------------------------+-------------+-------------+ 422 | Manual configuration | Y | Y | 423 +------------------------+-------------+-------------+ 424 | SeND | Y | Y | 425 +------------------------+-------------+-------------+ 426 | RA snooping | Y | Y | 427 +------------------------+-------------+-------------+ 428 | Use switch ACLs | Y | Y | 429 +------------------------+-------------+-------------+ 430 | Router preference | N | Y | 431 +------------------------+-------------+-------------+ 432 | Layer 2 admission | N | N | 433 +------------------------+-------------+-------------+ 434 | Host firewall | Y | Y | 435 +------------------------+-------------+-------------+ 436 | Deprecation daemon | Y | Y | 437 +------------------------+-------------+-------------+ 438 | New prefix delay | Partly | Partly | 439 +------------------------+-------------+-------------+ 440 | Layer 2 partition | N | Y | 441 +------------------------+-------------+-------------+ 442 | DHCPv6 gateway option | Partly | If Auth | 443 +------------------------+-------------+-------------+ 445 What the above summary does not consider is the practicality of 446 deploying the measure. An easy-to-deploy method that buys improved 447 resilience to rogue RAs without significant administrative overhead 448 is attractive. On that basis the RA snooping proposal, e.g. RA 449 Guard, has merit, while approaches like manual configuration However 450 RA Guard is not yet fully defined or available, while only certain 451 managed switch equipment may support the required ACLs. 453 5. Other related considerations 455 There are a number of related issues that have come out of 456 discussions on the rogue RA topic, which the authors believe are 457 worth capturing in this document. 459 5.1. Unicast RAs 461 The above discussion was initially held on the assumption that rogue 462 multicast RAs were the cause of problems on a shared network subnet. 463 However, the specifications for Router Advertisements allow them to 464 be sent unicast to a host, as per Section 6.2.6 of RFC4861. It is 465 thus possible for an attacker to target one or more hosts on a shared 466 medium without (potentially) a rogue multicast RA being observed 467 elsewhere on the network (e.g. by a monitoring daemon). However, an 468 accidental rogue RA is likely to be multicast. 470 5.2. The DHCP vs RA threat model 472 Comparing the threat model for rogue RAs and rogue DHCPv6 servers is 473 an interesting exercise. In the case of Windows ICS causing rogue 474 6to4-based RAs to appear on a network, it is very likely that the 475 same host is also acting as a rogue IPv4 DHCP server. The rogue 476 DHCPv4 server can allocate a default gateway and an address to hosts, 477 just as a rogue RA can lead hosts to learning of a new (additional) 478 default gateway, prefix(es) and address. In the case of multicast 479 rogue RAs however, the impact is potentially immediate to all hosts, 480 while the rogue DHCP server's impact will depend on lease timers for 481 hosts. 483 In principle Authenticated DHCP can be used to protect against rogue 484 DHCPv4 (and DHCPv6) servers, just as SeND could be used to protect 485 against rogue IPv6 RAs. However, actual use of Authenticated DHCP in 486 typical networks is currently minimal. Were new DHCPv6 default 487 gateway and prefix options to be standardised as described above, 488 then without Authenticated DHCP the (lack of) security is just pushed 489 to another place. 491 The RA Guard approach is essentially using a similar model to DHCP 492 message snooping to protect against rogue RAs in network (switch) 493 equipment. As noted above, DHCPv6 message snooping would also be 494 very desirable in IPv6 networks. 496 5.3. IPv4-only networks 498 The rogue RA problem should also be considered by administrators and 499 operators of IPv4-only networks, where IPv6 monitoring, firewalling 500 and other related mechanisms may not be in place. 502 For example a comment has been made that in the case of 6to4 being 503 run by a host on a subnet that is not administratively configured 504 with IPv6, some OSes or applications may begin using IPv6 to the 6to4 505 host (router) rather than IPv4 to the intended default IPv4 router, 506 because they have IPv6 enabled by default and some applications 507 prefer IPv6 by default. Technically aware users may also 508 deliberately choose to use IPv6, possibly for subversive reasons. 509 Mitigating against this condition can also be seen to be important. 511 5.4. Network monitoring tools 513 It would generally be prudent for network monitoring or management 514 platforms to be able to observe and report on observed RAs, and 515 whether unintended RAs (possibly from unintended sources) are present 516 on a network. Further, it may be useful for individual hosts to be 517 able to report their address status (assuming their configuration 518 status allowed it of course), e.g. this could be useful during an 519 IPv6 renumbering phased process as described in RFC4192 [RFC4192]. 521 The above assumes, of course, that what defines a 'good' (or 'bad') 522 RA can be configured in a trustworthy manner within the network's 523 management framework. 525 5.5. Recovering from bad configuration state 527 After a host receives and processes a rogue RA, it may have multiple 528 default gateways, global addresses, and potentially clashing RA 529 options (e.g. M/O bits). The host's behaviour may then be 530 unpredictable, in terms of the default router that is used, and the 531 (source) address(es) used in communications. A host that is aware of 532 protocols such as shim6 may believe it is genuinely multihomed. 534 An important issue is how readily a host can recover from receiving 535 and processing bad configuration information, e.g. considering the '2 536 hour rule' of Section 5.5.3 of RFC4862 (though this applies to the 537 valid lifetime not the router lifetime). We should ensure that 538 methods exist for a network administrator to correct bad 539 configuration information on a link or subnet, and that OS platforms 540 support these methods. At least if the problem can be detected, and 541 corrected promptly, the impact is minimised. 543 5.6. Isolating the offending rogue RA source 545 In addition to issuing a deprecating RA, it would be desirable to 546 isolate the offending source of the rogue RA from the network. It 547 may be possible to use Network Access Control methods to quarantine 548 the offending host, or rather the network point of attachment or port 549 that it is using. 551 6. Conclusions 553 In this text we have described scenarios via which rogue Router 554 Advertisements (RAs) may appear on a network, and some measures that 555 could be used to mitigate against these. We have also noted some 556 related issues that have arisen in the rogue RA discussions. Our 557 discussion is generally focused on the assumption that rogue RAs are 558 appearing as a result of accidental misconfiguration on the network, 559 by a user or administrator. 561 While SeND perhaps offers the most robust solution, implementations 562 and deployment guidelines are not yet widely available. SeND is very 563 likely to be a good, longer term solution, but many administrators 564 are seeking solutions today. Such administrators are also often in 565 networks with security models for which SeND is a 'heavyweight' 566 solution, e.g. campus networks, or wireless conference or public 567 networks. For such scenarios, simpler measures are desirable. 569 Adding new DHCPv6 Default Gateway and Prefix Options would allow IPv6 570 host configuration by DHCP only, and be a method that IPv4 571 administrators are comfortable with (for better or worse), but this 572 simply shifts the security risk elsewhere. 574 While a number of the mitigations described above have their appeal, 575 the simplest solutions probably lie in switch-based ACLs and RA-Guard 576 style approaches. Where managed switches are no available, use of 577 the Router Preference option and (moreso in managed desktop 578 environments) host firewalls may be appropriate. 580 In the longer term wider experience of SeND will be beneficial, while 581 the use of RA snooping will remain useful either to complement SeND 582 (where a switch running RA Guard can potentially be a SeND proxy) or 583 to assist in scenarios for which SeND is not deployed. 585 7. Security Considerations 587 This document is Informational. It does not describe solutions for 588 malicious attacks on a network for which malicious RAs may be part of 589 a broader attack, e.g. including malicious NA messages. 591 8. IANA Considerations 593 There are no extra IANA consideration for this document. 595 9. Acknowledgments 597 Thanks are due to members of the IETF IPv6 Operations and DHCP WGs 598 for their inputs on this topic, as well as some comments from various 599 operational mailing lists, and private comments, including but not 600 limited to: Iljitsch van Beijnum, Dale Carder, Remi Denis-Courmont, 601 Tony Hain, Bob Hinden, Christian Huitema, Tatuya Jinmei, Eric Levy- 602 Abegnoli, David Malone, Thomas Narten, Chip Popoviciu, Dave Thaler, 603 Gunter Van de Velde, Goeran Weinholt and Dan White. 605 10. Informative References 607 [RFC1483] Heinanen, J., "Multiprotocol Encapsulation over ATM 608 Adaptation Layer 5", RFC 1483, July 1993. 610 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 611 via IPv4 Clouds", RFC 3056, February 2001. 613 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 614 and M. Carney, "Dynamic Host Configuration Protocol for 615 IPv6 (DHCPv6)", RFC 3315, July 2003. 617 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 618 (DHCP) Service for IPv6", RFC 3736, April 2004. 620 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 621 Neighbor Discovery (SEND)", RFC 3971, March 2005. 623 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 624 More-Specific Routes", RFC 4191, November 2005. 626 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 627 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 628 September 2005. 630 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 631 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 632 September 2007. 634 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 635 Address Autoconfiguration", RFC 4862, September 2007. 637 [I-D.ietf-v6ops-ra-guard] 638 Levy-Abegnoli, E., Velde, G., Popoviciu, C., and J. 639 Mohacsi, "IPv6 RA-Guard", draft-ietf-v6ops-ra-guard-02 640 (work in progress), March 2009. 642 [I-D.nward-ipv6-autoconfig-filtering-ethernet] 643 Ward, N., "IPv6 Autoconfig Filtering on Ethernet 644 Switches", 645 draft-nward-ipv6-autoconfig-filtering-ethernet-00 (work in 646 progress), March 2009. 648 [I-D.droms-dhc-dhcpv6-default-router] 649 Droms, R. and T. Narten, "Default Router and Prefix 650 Advertisement Options for DHCPv6", 651 draft-droms-dhc-dhcpv6-default-router-00 (work in 652 progress), March 2009. 654 Authors' Addresses 656 Tim Chown 657 University of Southampton 658 Highfield 659 Southampton, Hampshire SO17 1BJ 660 United Kingdom 662 Email: tjc@ecs.soton.ac.uk 664 Stig Venaas 665 UNINETT 666 Trondheim NO 7465 667 Norway 669 Email: venaas@uninett.no