diff options
Diffstat (limited to 'doc/rfc/rfc6104.txt')
| -rw-r--r-- | doc/rfc/rfc6104.txt | 899 |
1 files changed, 899 insertions, 0 deletions
diff --git a/doc/rfc/rfc6104.txt b/doc/rfc/rfc6104.txt new file mode 100644 index 0000000..55d2e60 --- /dev/null +++ b/doc/rfc/rfc6104.txt @@ -0,0 +1,899 @@ + + + + + + +Internet Engineering Task Force (IETF) T. Chown +Request for Comments: 6104 University of Southampton +Category: Informational S. Venaas +ISSN: 2070-1721 Cisco Systems + February 2011 + + + Rogue IPv6 Router Advertisement Problem Statement + +Abstract + + When deploying IPv6, whether IPv6-only or dual-stack, routers are + configured to send IPv6 Router Advertisements (RAs) to convey + information to nodes that enable them to autoconfigure on the + network. This information includes the implied default router + address taken from the observed source address of the RA message, as + well as on-link prefix information. However, unintended + misconfigurations by users or administrators, or possibly malicious + attacks on the network, may lead to bogus RAs being present, which in + turn can cause operational problems for hosts on the network. In + this document, we summarise the scenarios in which rogue RAs may be + observed and present a list of possible solutions to the problem. We + focus on the unintended causes of rogue RAs in the text. The goal of + this text is to be Informational, and as such to present a framework + around which solutions can be proposed and discussed. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6104. + + + + + + + + + + +Chown & Venaas Informational [Page 1] + +RFC 6104 Rogue IPv6 Router Advertisements February 2011 + + +Copyright Notice + + Copyright (c) 2011 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + + + + + + + + + + + + + + + + + + + + + + + + + +Chown & Venaas Informational [Page 2] + +RFC 6104 Rogue IPv6 Router Advertisements February 2011 + + +Table of Contents + + 1. Introduction ....................................................4 + 2. Bogus RA Scenarios ..............................................4 + 2.1. Administrator Misconfiguration .............................5 + 2.2. User Misconfiguration ......................................5 + 2.3. Malicious Misconfiguration .................................5 + 3. Methods to Mitigate against Rogue RAs ...........................6 + 3.1. Manual Configuration .......................................6 + 3.2. Introducing RA Snooping ....................................6 + 3.3. Using ACLs on Managed Switches .............................7 + 3.4. SEcure Neighbor Discovery (SEND) ...........................7 + 3.5. Router Preference Option ...................................8 + 3.6. Relying on Layer 2 Admission Control .......................8 + 3.7. Using Host-Based Packet Filters ............................8 + 3.8. Using an "Intelligent" Deprecation Tool ....................8 + 3.9. Using Layer 2 Partitioning .................................9 + 3.10. Adding Default Gateway/Prefix Options to DHCPv6 ...........9 + 4. Scenarios and Mitigations ......................................10 + 5. Other Related Considerations ...................................11 + 5.1. Unicast RAs ...............................................11 + 5.2. The DHCP versus RA Threat Model ...........................11 + 5.3. IPv4-Only Networks ........................................12 + 5.4. Network Monitoring Tools ..................................12 + 5.5. Recovering from Bad Configuration State ...................12 + 5.6. Isolating the Offending Rogue RA Source ...................13 + 6. Conclusions ....................................................13 + 7. Security Considerations ........................................14 + 8. Acknowledgments ................................................14 + 9. Informative References .........................................15 + + + + + + + + + + + + + + + + + + + + + +Chown & Venaas Informational [Page 3] + +RFC 6104 Rogue IPv6 Router Advertisements February 2011 + + +1. Introduction + + The Neighbor Discovery protocol [RFC4861] describes the operation of + IPv6 Router Advertisements (RAs) that are used to determine node + configuration information during the IPv6 autoconfiguration process, + whether that node's configuration is stateful, via the Dynamic Host + Configuration Protocol for IPv6 (DHCPv6) [RFC3315] or stateless, as + per [RFC4862], possibly in combination with DHCPv6 Light [RFC3736]. + + In observing the operation of deployed IPv6 networks, it is apparent + that there is a problem with undesired or "bogus" IPv6 RAs appearing + on network links or subnets. By "bogus" we mean RAs that were not + the intended configured RAs, but rather RAs that have appeared for + some other reason. While the problem appears more common in shared + wireless environments, it is also seen on wired enterprise networks. + + The problem with rogue RAs is that they can cause partial or complete + failure of operation of hosts on an IPv6 link. For example, the + default router address is drawn directly from the source address of + the RA message. In addition, rogue RAs can cause hosts to assume + wrong prefixes to be used for stateless address autoconfiguration. + In a case where there may be mixing of "good" and "bad" RAs, a host + might keep on using the "good" default gateway, but pick a wrong + source address, leading to egress filtering problems. As such, rogue + RAs are an operational issue for which solution(s) are required, and + for which best practice needs to be conveyed. This not only includes + preventing or detecting rogue RAs, but also where necessary ensuring + the network (and hosts on the network) have the ability to quickly + recover from a state where host configuration is incorrect as a + result of processing such an RA. + + In the next section, we discuss the scenarios that may give rise to + rogue RAs being present. In the following section, we present some + candidate solutions for the problem, some of which may be more + practical to deploy than others. This document focuses on + "accidental" rogue RAs; while malicious RAs are of course also + possible, the common problem today lies with unintended RAs. In + addition, a network experiencing malicious attack of this kind is + likely to also experience malicious Neighbor Advertisement (NA) and + related messages. + +2. Bogus RA Scenarios + + There are three broad classes of scenario in which bogus RAs may be + introduced to an IPv6 network. + + + + + + +Chown & Venaas Informational [Page 4] + +RFC 6104 Rogue IPv6 Router Advertisements February 2011 + + +2.1. Administrator Misconfiguration + + Here an administrator incorrectly configures RAs on a router + interface, causing incorrect RAs to appear on links and causing hosts + to generate incorrect or unintended IPv6 address, gateway, or other + information. In such a case, the default gateway may be correct, but + a host might for example become multiaddressed, possibly with a + correct and incorrect address based on a correct and incorrect + prefix. There is also the possibility of other configuration + information being misconfigured, such as the lifetime option. + + In the case of a Layer 2 IEEE 802.1Q Virtual LAN (VLAN) + misconfiguration, RAs may "flood" to unintended links, causing hosts + or more than one link to potentially become incorrectly + multiaddressed, with possibly two different default routers + available. + +2.2. User Misconfiguration + + In this case, a user's device "accidentally" transmits RAs onto the + local link, potentially adding an additional default gateway and + associated prefix information. + + This seems to typically be seen on wireless (though sometimes wired) + networks where a laptop has enabled the Windows Internet Connection + Sharing (ICS) service, which can turn a host into a 6to4 [RFC3056] + gateway; this can be a useful feature, unless of course it is run + when not intended. This service can also cause IPv4 problems, as it + will typically start a "rogue" DHCPv4 server on the host. + + We have also had reports that hosts may not see genuine IPv6 RAs on a + link due to host firewalls, causing them to turn on a connection- + sharing service and 6to4 as a result. In some cases, more technical + users may also use a laptop as a home gateway (e.g., again a 6to4 + gateway) and then connect to another network, forgetting their + previous gateway configuration is still active. + + There are also reported incidents in enterprise networks of users + physically plugging Ethernet cables into the wrong sockets and + bridging two subnets together, causing a problem similar to VLAN + flooding. + +2.3. Malicious Misconfiguration + + Here an attacker is deliberately generating RAs on the local network + in an attempt to perform some form of denial-of-service or man-in- + the-middle attack. + + + + +Chown & Venaas Informational [Page 5] + +RFC 6104 Rogue IPv6 Router Advertisements February 2011 + + + As stated above, while this is a genuine concern for network + administrators, there have been few if any reports of such activity, + while in contrast reports of accidental rogue RAs are very + commonplace. In writing this text, and with the feedback of the + v6ops working group, we came to the conclusion that the issue of + malicious attack, due to the other complementary attacks that are + likely to be launched using rogue NA and similar messages, are best + considered by further work and document(s). As a result, this text + intends to provide informational guidance for operators looking for + practical measures to take to avoid "accidental" rogue RAs on their + own networks. + +3. Methods to Mitigate against Rogue RAs + + In this section, we present a summary of methods suggested to date + for reducing or removing the possibility of rogue RAs being seen on a + network. + +3.1. Manual Configuration + + The default gateway and host address can usually be manually + configured on a node. This of course can be a resource intensive + solution, and also prone to administrative mistakes in itself. + + Manual configuration implies that RA processing is disabled. Most + operating systems allow RA messages to be ignored, such that if an + IPv6 address is manually configured on a system, an additional global + autoconfigured address will not be added should an unexpected RA + appear on the link. + +3.2. Introducing RA Snooping + + It should be possible to implement "RA snooping" in Layer 2 switches + in a similar way to DHCP snooping, such that RAs observed from + incorrect sources are blocked or dropped, and not propagated through + a subnet. One candidate solution in this space, called "RA-Guard" + [RFC6105], has been proposed. This type of solution has appeal + because it is a familiar model for enterprise network managers, but + it can also be used to complement SEcure Neighbor Discovery (SEND) + [RFC3971], by a switch acting as a SEND proxy for hosts. + + This type of solution may not be applicable everywhere, e.g., in + environments where there are not centrally controlled or manageable + switches. + + + + + + + +Chown & Venaas Informational [Page 6] + +RFC 6104 Rogue IPv6 Router Advertisements February 2011 + + +3.3. Using ACLs on Managed Switches + + Certain switch platforms can already implement some level of rogue RA + filtering by the administrator configuring Access Control Lists + (ACLs) that block RA ICMP messages that might be inbound on "user" + ports. Again this type of "solution" depends on the presence of such + configurable switches. + + A recent document describes the RA message format(s) for filtering + [IPv6-AUTOCFG-FILTER]. The document also notes requirements for + DHCPv6 snooping, which can then be implemented similarly to DHCPv4 + snooping. + +3.4. SEcure Neighbor Discovery (SEND) + + The SEcure Neighbor Discovery (SEND) [RFC3971] protocol provides a + method for hosts and routers to perform secure Neighbor Discovery. + Thus, it can in principle protect a network against rogue RAs. + + SEND is not yet widely used at the time of writing, in part because + there are very few implementations of the protocol. Some other + deployment issues have been raised, though these are likely to be + resolved in due course. For example, routers probably don't want to + use autogenerated addresses (which might need to be protected by + ACLs), so SEND needs to be shown to work with non-autogenerated + addresses. Also, it has been argued that there are "bootstrapping" + issues, in that hosts wanting to validate router credentials (e.g., + to a certificate server or Network Time Protocol (NTP) server) are + likely to need to communicate via the router for that information. + + Further, it's not wholly clear how widely adopted SEND could or would + be in site networks with "lightweight" security (e.g., many campus + networks), especially where hosts are managed by users and not + administratively. Public or conference wireless networks may face + similar challenges. There may also be networks, like perhaps sensor + networks, where use of SEND is less practical. These networks still + require rogue RA protection. + + While SEND clearly can provide a good, longer-term solution, + especially in networks where malicious activity is a significant + concern, there is a requirement today for practical solutions, and/or + solutions more readily applicable in more "relaxed" environments. In + the latter case, solutions like "RA snooping" or applied ACLs are + more attractive now. + + + + + + + +Chown & Venaas Informational [Page 7] + +RFC 6104 Rogue IPv6 Router Advertisements February 2011 + + +3.5. Router Preference Option + + [RFC4191] introduced a Router Preference option, such that an RA + could carry one of three Router Preference values: High, Medium + (default), or Low. Thus, an administrator could use "High" settings + for managed RAs, and hope that "accidental" RAs would be medium + priority. This of course would only work in some scenarios -- if the + user who accidentally sends out a rogue RA on the network has + configured their device with "High" precedence for their own intended + usage, the priorities would clash. But for accidental rogue RAs + caused by software like Windows ICS and 6to4, which would use the + default precedence, it could be useful. Obviously this solution + would also rely on clients (and routers) having implementations of + the Router Preference option. + +3.6. Relying on Layer 2 Admission Control + + In principle, if a technology such as IEEE 802.1x is used, devices + would first need to authenticate to the network before being able to + send or receive IPv6 traffic. Ideally, authentication would be + mutual. Deployment of 802.1x, with mutual authentication, may + however be seen as somewhat "heavyweight", akin to SEND, for some + deployments. + + Improving Layer 2 security may help to mitigate against an attacker's + capability to join the network to send RAs, but it doesn't prevent + misconfiguration issues. A user can happily authenticate and still + launch a Windows ICS service, for example. + +3.7. Using Host-Based Packet Filters + + In a managed environment, hosts could be configured via their + "personal firewall" to only accept RAs from trusted sources. Hosts + could also potentially be configured to discard 6to4-based RAs in a + managed enterprise environment. + + However, the problem is then pushed to keeping this configuration + maintained and correct. If a router fails and is replaced, possibly + with a new Layer 2 interface address, the link local source address + in the filter may become incorrect, and thus no method would be + available to push the new information to the host over the network. + +3.8. Using an "Intelligent" Deprecation Tool + + It is possible to run a daemon on a link (perhaps on the router on + the link) to watch for incorrect RAs and to send a deprecating RA + with a router lifetime of zero when such an RA is observed. The KAME + rafixd is an example of such a tool, which has been used at IETF + + + +Chown & Venaas Informational [Page 8] + +RFC 6104 Rogue IPv6 Router Advertisements February 2011 + + + meetings with some success. A slightly enhanced tool called RAMOND + has since been developed from this code, and is now available as a + Sourceforge project. As with host-based firewalling, the daemon + would need to somehow know what "good" and "bad" RAs are, from some + combination of known good sources and/or link prefixes. In an + environment with native IPv6, though, 6to4-based RAs would certainly + be known to be rogue. + + Whether or not use of such a tool is the preferred method, monitoring + a link for observed RAs seems prudent from a network management + perspective. Some such tools exist already, e.g., NDPMon, which can + also detect other undesirable behaviour. + +3.9. Using Layer 2 Partitioning + + If each system or user on a network is partitioned into a different + Layer 2 medium, then the impact of rogue RAs can be limited. In + broadband networks, bridging [RFC2684] may be available, for example. + The benefit may be scenario-specific, e.g., whether a given user or + customer has their own network prefix or whether the provisioning is + in a shared subnet or link. It is certainly desirable that any given + user or customer's system(s) are unable to see RAs that may be + generated by other users or customers. + + However, such partitioning would probably increase address space + consumption significantly if applied in enterprise networks, and in + many cases, hardware costs and software licensing costs to enable + routing to the edge can be quite significant. + +3.10. Adding Default Gateway/Prefix Options to DHCPv6 + + Adding Default Gateway and Prefix options for DHCPv6 would allow + network administrators to configure hosts to only use DHCPv6 for + default gateway and prefix configuration in managed networks, where + RAs would be required today. A new document has proposed such a + default router option, along with prefix advertisement options for + DHCPv6 [DHCPv6-DEFAULT-RTR]. Even with such options added to DHCPv6, + an RA is in principle still required to inform hosts to use DHCPv6. + + An advantage of DHCPv6 is that should an error be introduced, only + hosts that have refreshed their DHCP information since that time are + affected, while a multicast rogue RA will most likely affect all + hosts immediately. DHCPv6 also allows different answers to be given + to different hosts. + + While making host configuration possible via DHCPv6 alone is a viable + option that would allow IPv6 configuration to be done in a way + similar to IPv4 today, the problem has only been shifted: rather than + + + +Chown & Venaas Informational [Page 9] + +RFC 6104 Rogue IPv6 Router Advertisements February 2011 + + + rogue RAs being the problem, rogue DHCPv6 servers would be an + equivalent issue. As with IPv4, a network would then still require + use of Authenticated DHCP, or DHCP(v6) snooping, as suggested in + [IPv6-AUTOCFG-FILTER]. + + There is certainly some demand in the community for DHCPv6-only host + configuration. While this may mitigate the rogue RA issue, it simply + moves the trust problem elsewhere, albeit to a place administrators + are familiar with today. + +4. Scenarios and Mitigations + + In this section, we summarise the error/misconfiguration scenarios + and practical mitigation methods described above in a matrix format. + We consider, for the case of a rogue multicast RA, which of the + mitigation methods helps protect against administrator and user + errors. For the administrator error, we discount an error in + configuring the countermeasure itself; rather, we consider an + administrator error to be an error in configuration elsewhere in the + network. + + +------------------------+---------------------------+ + | | Scenario | + | Mitigation |---------------------------| + | Method | Admin Error | User Error | + +------------------------+-------------+-------------+ + | Manual configuration | Y | Y | + +------------------------+-------------+-------------+ + | SEND | Y | Y | + +------------------------+-------------+-------------+ + | RA snooping | Y | Y | + +------------------------+-------------+-------------+ + | Use switch ACLs | Y | Y | + +------------------------+-------------+-------------+ + | Router preference | N | Y | + +------------------------+-------------+-------------+ + | Layer 2 admission | N | N | + +------------------------+-------------+-------------+ + | Host firewall | Y | Y | + +------------------------+-------------+-------------+ + | Deprecation daemon | Y | Y | + +------------------------+-------------+-------------+ + | Layer 2 partition | N | Y | + +------------------------+-------------+-------------+ + | DHCPv6 gateway option | Partly | If Auth | + +------------------------+-------------+-------------+ + + + + + +Chown & Venaas Informational [Page 10] + +RFC 6104 Rogue IPv6 Router Advertisements February 2011 + + + What the above summary does not consider is the practicality of + deploying the measure. An easy-to-deploy method that buys improved + resilience to rogue RAs without significant administrative overhead + is attractive. On that basis, the RA snooping proposal, e.g., + RA-Guard, has merit, while approaches like manual configuration are + less appealing. However, RA-Guard is not yet fully defined or + available, while only certain managed switch equipment may support + the required ACLs. + +5. Other Related Considerations + + There are a number of related issues that have come out of + discussions on the rogue RA topic, which the authors believe are + worth capturing in this document. + +5.1. Unicast RAs + + The above discussion was initially held on the assumption that rogue + multicast RAs were the cause of problems on a shared network subnet. + However, the specifications for Router Advertisements allow them to + be sent unicast to a host, as per Section 6.2.6 of RFC 4861. If a + host sending rogue RAs sends them unicast to the soliciting host, + that RA may not be seen by other hosts on the shared medium, e.g., by + a monitoring daemon. In most cases, though, an accidental rogue RA + is likely to be multicast. + +5.2. The DHCP versus RA Threat Model + + Comparing the threat model for rogue RAs and rogue DHCPv6 servers is + an interesting exercise. In the case of Windows ICS causing rogue + 6to4-based RAs to appear on a network, it is very likely that the + same host is also acting as a rogue IPv4 DHCP server. The rogue + DHCPv4 server can allocate a default gateway and an address to hosts, + just as a rogue RA can lead hosts to learning of a new (additional) + default gateway, prefix(es), and address. In the case of multicast + rogue RAs, however, the impact is potentially immediate to all hosts, + while the rogue DHCP server's impact will depend on lease timers for + hosts. + + In principle, Authenticated DHCP can be used to protect against rogue + DHCPv4 (and DHCPv6) servers, just as SEND could be used to protect + against rogue IPv6 RAs. However, actual use of Authenticated DHCP in + typical networks is currently minimal. Were new DHCPv6 default + gateway and prefix options to be standardised as described above, + then without Authenticated DHCP the (lack of) security is just pushed + to another place. + + + + + +Chown & Venaas Informational [Page 11] + +RFC 6104 Rogue IPv6 Router Advertisements February 2011 + + + The RA-Guard approach is essentially using a similar model to DHCP + message snooping to protect against rogue RAs in network (switch) + equipment. As noted above, DHCPv6 message snooping would also be + very desirable in IPv6 networks. + +5.3. IPv4-Only Networks + + The rogue RA problem should also be considered by administrators and + operators of IPv4-only networks, where IPv6 monitoring, firewalling, + and other related mechanisms may not be in place. + + For example, a comment has been made that in the case of 6to4 being + run by a host on a subnet that is not administratively configured + with IPv6, some OSes or applications may begin using IPv6 to the 6to4 + host (router) rather than IPv4 to the intended default IPv4 router, + because they have IPv6 enabled by default and some applications + prefer IPv6 by default. Technically aware users may also + deliberately choose to use IPv6, possibly for subversive reasons. + Mitigating against this condition can also be seen to be important. + +5.4. Network Monitoring Tools + + It would generally be prudent for network monitoring or management + platforms to be able to observe and report on observed RAs, and + whether unintended RAs (possibly from unintended sources) are present + on a network. Further, it may be useful for individual hosts to be + able to report their address status (assuming their configuration + status allowed it, of course), e.g., this could be useful during an + IPv6 renumbering phased process as described in RFC 4192 [RFC4192]. + + The above assumes, of course, that what defines a "good" (or "bad") + RA can be configured in a trustworthy manner within the network's + management framework. + +5.5. Recovering from Bad Configuration State + + After a host receives and processes a rogue RA, it may have multiple + default gateways, global addresses, and potentially clashing RA + options (e.g., M/O bits [RFC4861]). The host's behaviour may then be + unpredictable, in terms of the default router that is used, and the + (source) address(es) used in communications. A host that is aware of + protocols such as Shim6 [RFC5533] may believe it is genuinely + multihomed. + + + + + + + + +Chown & Venaas Informational [Page 12] + +RFC 6104 Rogue IPv6 Router Advertisements February 2011 + + + An important issue is how readily a host can recover from receiving + and processing bad configuration information, e.g., considering the + "2 hour rule" mentioned in Section 5.5.3 of RFC 4862 (though this + applies to the valid address lifetime and not the router lifetime). + We should ensure that methods exist for a network administrator to + correct bad configuration information on a link or subnet, and that + OS platforms support these methods. At least if the problem can be + detected, and corrected promptly, the impact is minimised. + +5.6. Isolating the Offending Rogue RA Source + + In addition to issuing a deprecating RA, it would be desirable to + isolate the offending source of the rogue RA from the network. It + may be possible to use Network Access Control methods to quarantine + the offending host, or rather the network point of attachment or port + that it is using. + +6. Conclusions + + In this text we have described scenarios via which rogue Router + Advertisements (RAs) may appear on a network, and some measures that + could be used to mitigate against these. We have also noted some + related issues that have arisen in the rogue RA discussions. Our + discussion is generally focused on the assumption that rogue RAs are + appearing as a result of accidental misconfiguration on the network, + by a user or administrator. + + While SEND perhaps offers the most robust solution, implementations + and deployment guidelines are not yet widely available. SEND is very + likely to be a good, longer-term solution, but many administrators + are seeking solutions today. Such administrators are also often in + networks with security models for which SEND is a "heavyweight" + solution, e.g., campus networks, or wireless conference or public + networks. For such scenarios, simpler measures are desirable. + + Adding new DHCPv6 Default Gateway and Prefix options would allow IPv6 + host configuration by DHCP only and would be a method that IPv4 + administrators are comfortable with (for better or worse), but this + simply shifts the robustness issue elsewhere. + + While a number of the mitigations described above have their appeal, + the simplest solutions probably lie in switch-based ACLs and + RA-Guard-style approaches. Where managed switches are not available, + use of the Router Preference option and (more so in managed desktop + environments) host firewalls may be appropriate. + + + + + + +Chown & Venaas Informational [Page 13] + +RFC 6104 Rogue IPv6 Router Advertisements February 2011 + + + In the longer term, wider experience of SEND will be beneficial, + while the use of RA snooping will remain useful either to complement + SEND (where a switch running RA-Guard can potentially be a SEND + proxy) or to assist in scenarios for which SEND is not deployed. + +7. Security Considerations + + This Informational document is focused on discussing solutions to + operational problems caused by rogue RAs resulting from unintended + misconfiguration by users or administrators. Earlier versions of + this text included some analysis of rogue RAs introduced maliciously; + e.g., the text included an extra column in the matrix in Section 4. + However, the consensus of the v6ops working group feedback was to + instead focus on the common operational problem of "accidental" rogue + RAs seen today. + + Thus, the final version of this text does not address attacks on a + network where rogue RAs are intentionally introduced as part of a + broader attack, e.g., including malicious NA messages. On the wire, + malicious rogue RAs will generally look the same as "accidental" + ones, though they are more likely, for example, to spoof the Media + Access Control (MAC) or IPv6 source address of the genuine router, or + to use a "High" Router Preference option. It is also likely that + malicious rogue RAs will be accompanied by other attacks on the IPv6 + infrastructure, making discussion of mitigations more complex. + Administrators may be able to detect such activity by the use of + tools such as NDPMon. + + It is worth noting that the deprecation daemon could be used as part + of a denial-of-service attack, should the tool be used to deprecate + the genuine RA. + +8. Acknowledgments + + Thanks are due to members of the IETF IPv6 Operations and DHCP + working groups for their inputs on this topic, as well as some + comments from various operational mailing lists, and private + comments, including but not limited to: Iljitsch van Beijnum, Dale + Carder, Remi Denis-Courmont, Tony Hain, Bob Hinden, Christian + Huitema, Tatuya Jinmei, Eric Levy-Abegnoli, David Malone, Thomas + Narten, Chip Popoviciu, Dave Thaler, Gunter Van de Velde, Goeran + Weinholt, and Dan White. + + + + + + + + + +Chown & Venaas Informational [Page 14] + +RFC 6104 Rogue IPv6 Router Advertisements February 2011 + + +9. Informative References + + [RFC2684] Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation + over ATM Adaptation Layer 5", RFC 2684, September 1999. + + [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains + via IPv4 Clouds", RFC 3056, February 2001. + + [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., + and M. Carney, "Dynamic Host Configuration Protocol for + IPv6 (DHCPv6)", RFC 3315, July 2003. + + [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol + (DHCP) Service for IPv6", RFC 3736, April 2004. + + [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure + Neighbor Discovery (SEND)", RFC 3971, March 2005. + + [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and + More-Specific Routes", RFC 4191, November 2005. + + [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for + Renumbering an IPv6 Network without a Flag Day", RFC 4192, + September 2005. + + [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, + "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, + September 2007. + + [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless + Address Autoconfiguration", RFC 4862, September 2007. + + [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming + Shim Protocol for IPv6", RFC 5533, June 2009. + + [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. + Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, + February 2011. + + [IPv6-AUTOCFG-FILTER] + Ward, N., "IPv6 Autoconfig Filtering on Ethernet + Switches", Work in Progress, March 2009. + + [DHCPv6-DEFAULT-RTR] + Droms, R. and T. Narten, "Default Router and Prefix + Advertisement Options for DHCPv6", Work in Progress, + March 2009. + + + + +Chown & Venaas Informational [Page 15] + +RFC 6104 Rogue IPv6 Router Advertisements February 2011 + + +Authors' Addresses + + Tim Chown + University of Southampton + Highfield + Southampton, Hampshire SO17 1BJ + United Kingdom + + EMail: tjc@ecs.soton.ac.uk + + + Stig Venaas + Cisco Systems + Tasman Drive + San Jose, CA 95134 + USA + + EMail: stig@cisco.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Chown & Venaas Informational [Page 16] + |