Rogue IPv6 Router Advertisement Problem Statement

The Neighbor Discovery protocol describes the operation of IPv6 Router Advertisements (RAs), which are used during the IPv6 autoconfiguration process, whether a node's configuration is stateful (via DHCPv6) or stateless (as per RFC4862, possibly in combination with DHCPv6 Light). In observing the operation of deployed IPv6 networks, it is apparent that there is a problem with undesired or 'bogus' IPv6 Router Advertisements (RAs) appearing on network links or subnets. By 'bogus' we mean RAs that were not the intended configured RAs, rather RAs that have appeared for some other reason. 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. 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 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.

There are three broad classes of scenario in which bogus RAs may be introduced to an IPv6 network.

Here an administrator incorrectly configures RAs on a router interface, causing incorrect RAs to appear on links and 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 multi-addressed, 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 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.

In this case a user's device 'accidentally' transmits RAs onto the local link, 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 service (ICS) which turns a host into a 6to4 gateway; this can be a useful feature, unless of course it is run when not intended. We have had reports that hosts may not see the genuine RAs on link due to host firewalls, and then turning 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 with the gateway configuration 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 an problem similar to VLAN flooding.

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.

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.

The default gateway and host address can usually be manually configured on a device. This is of course a resource intensive solution, and also prone to administrative mistakes in itself.

The SeND protocol provides a method for hosts and routers to perform secure Neighbor Discovery. At present there are very few SeND implementations available, and SeND is perceived as a complex protocol to deploy. It is also likely that not all scenarios will be able to use SeND, for various reasons. In particular SeND may be best suited for fully managed enterprise networks, rather than those where administrative control is not present.

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 has recently 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 SeND. This type of solution may not be applicable everywhere, e.g. in environments where there are not centrally controlled 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.

RFC4191 introduced router preference options, 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 - an attacker would certainly seek to use High priority anyway - and would also rely on clients having implementations of the protocol.

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. Improving Layer 2 security may help to mitigate against a malicious attacker's capability to join the network to send RAs, but it doesn't prevent misconfiguration issues.

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 no thus no method would be available to push the new information to the host over the network.

It could be 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 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 meetings with some success. A slightly enhanced ramond has since been developed from this code. 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 contrast, an attacker might use such a tool to learn about prefixes being advertised on a link and to deprecate the 'good' RA(s) in favour of their bogus RA(s). 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.

It might be possible, in networks where configurations are very static and systems generally remain up, to configure an option such that any new RAs that are seen are not acted upon for a certain period, e.g. 2 hours. This might allow time for a misconfiguration or accidental RA to be detected and stopped, before hosts use the data in the RA. Of course this would add delays where genuine new RAs are required, while new hosts appearing on a network would still be vulnerable (or be unable to configure at all).

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 RFC1483 bridging 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 certainly 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.

It may be possible to define a new Default Gateway Option for DHCPv6 that would allow network administrators to only have hosts use DHCPv6 for default gateway configuration in managed networks. While such an option could be defined, its ramifications remain unclear, and such a fundamental change to the IPv6 model of autoconfiguration would need very careful consideration. In the absence of RAs, other configuration information would also be missing, e.g. on-link prefix information. Of course, it may be that an RA is still required to inform the host to use DHCPv6, and that may introduce a Catch-22 unless hosts are configured directly to only 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.

In this section we summarise the scenarios and mitigations described above in a summary matrix. We consider, for the case of a rogue multicast RA, which of the mitigation methods protects against each cause: +------------------------+-------------+-------------+-------------+ | Scenario | Admin | User | Malicious | | Mitigation | Error | Error | Attack | +------------------------+-------------+-------------+-------------+ | Manual configuration | Y | Y | Y | +------------------------+-------------+-------------+-------------+ | SeND | Partly | Y | Y | +------------------------+-------------+-------------+-------------+ | RA snooping | Y | Y | Y | +------------------------+-------------+-------------+-------------+ | Use switch ACLs | Y | Y | Y | +------------------------+-------------+-------------+-------------+ | Router preference | N | Y | N | +------------------------+-------------+-------------+-------------+ | Layer 2 admission | N | N | Y | +------------------------+-------------+-------------+-------------+ | Host firewall | Y | Y | N | +------------------------+-------------+-------------+-------------+ | Deprecation daemon | Y | Y | Partly | +------------------------+-------------+-------------+-------------+ | New prefix delay | Partly | Partly | Partly | +------------------------+-------------+-------------+-------------+ | Layer 2 partition | N | Y | N | +------------------------+-------------+-------------+-------------+ | DHCPv6 gateway option | If Auth | If Auth | If Auth | +------------------------+-------------+-------------+-------------+ 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 and perhaps SeND may be less appealing. However RA Guard is not yet fully defined or available, while only certain managed switch equipment may support the required ACLs. Methods that involve changes to IPv6 protocols such as delays in processing RAs or a new DHCPv6 option have rather reduced appeal, regardless of their merits or complications.

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.

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 RFC4861. It is thus possible for an attacker to target one or more hosts on a shared medium without (potentially) a rogue multicast RA being observed elsewhere on the network (e.g. by a monitoring daemon).

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 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 servers, just as SeND could be used to protect against rogue IPv6 RAs. However use of Authenticated DHCP is currently minimal, while SeND is in its infancy in implementation status. Were a new DHCPv6 default gateway option to be defined as described above, then without Authenticated DHCP the (lack of) security is just pushed to another place, albeit one that site administrators are more familiar and (rightly or wrongly) comfortable with. The RA Guard approach is essentially using a similar model to DHCP message snooping to protect against rogue RAs in network (switch) equipment. It is worth noting that DHCPv6 message snooping would also be very desirable in IPv6 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.

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 RFC4192.

An important issue is how readily a host can recover from bad configuration information, e.g. considering the '2 hour rule' of Section 5.5.3 of RFC4862 (though this applies to the prefix lifetime 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.

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). 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 may believe it is genuinely multihomed.

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. While SeND perhaps offers the most robust solution, implementations are not widely available, and the solution is perceived as complex (parallels can possibly be drawn with Authenticated DHCP in terms of likely deployment). Adding a new DHCPv6 Default Gateway Option would allow configuration by DHCP, and be a method that IPv4 administrators are comfortable with (for better or worse), but such an option would have significant impacts elsewhere, and in any event one must recognise that the security risk is then simply shifted elsewhere. Further work on the solutions is certainly welcome. In the meantime, the simplest initial step would be for RA snooping to be defined and deployed for Layer 2 devices, in such a way that can address (shared) wireless as well as wired networks. One draft proposal in this space, RA-Guard, has recently been published . Alternatively, certain switch platforms allow configuration of Access Control Lists (ACLs) that can achieve a similar function. In the longer term wider experience of SeND will be beneficial, while the use of RA snooping will remain useful either to complement SeND or to assist in scenarios that do not lend themselves to SeND deployment.

There are no extra Security consideration for this document.

There are no extra IANA consideration for this document.

Thanks are due to members of the IETF IPv6 Operations and DHCP WGs for their inputs on this topic, as well as some comments from various operational mailing lists, including but not limited to: Iljitsch van Beijnum, Dale Carder, Remi Denis-Courmant, Tony Hain, Christian Huitema, Tatuya Jinmei, David Malone, Chip Popoviciu, Dave Thaler, Göran Weinholt and Dan White.