Rogue IPv6 Router Advertisement Problem Statement
draft-ietf-v6ops-rogue-ra-02

IPv6 Operations                                                 T. Chown
Internet-Draft                                 University of Southampton
Intended status: Informational                                 S. Venaas
Expires: April 28, 2011                                    Cisco Systems
                                                        October 25, 2010

           Rogue IPv6 Router Advertisement Problem Statement
                      draft-ietf-v6ops-rogue-ra-02

Abstract

   When deploying IPv6, whether IPv6-only or dual-stack, routers are
   configured to send IPv6 Router Advertisements 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 Router Advertisement (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 draft 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 Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 28, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Chown & Venaas           Expires April 28, 2011                 [Page 1]
Internet-Draft      Rogue IPv6 Router Advertisements        October 2010

   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           Expires April 28, 2011                 [Page 2]
Internet-Draft      Rogue IPv6 Router Advertisements        October 2010

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.  Introduce RA snooping  . . . . . . . . . . . . . . . . . .  6
     3.3.  Use ACLs on Managed Switches . . . . . . . . . . . . . . .  7
     3.4.  Secure Neighbor Discovery (SeND) . . . . . . . . . . . . .  7
     3.5.  Router Preference Option . . . . . . . . . . . . . . . . .  8
     3.6.  Rely on Layer 2 admission control  . . . . . . . . . . . .  8
     3.7.  Use host-based packet filters  . . . . . . . . . . . . . .  8
     3.8.  Use an 'intelligent' deprecation tool  . . . . . . . . . .  8
     3.9.  Use Layer 2 Partitioning . . . . . . . . . . . . . . . . .  9
     3.10. Add 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 vs 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.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 14
   10. Informative References . . . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16

Chown & Venaas           Expires April 28, 2011                 [Page 3]
Internet-Draft      Rogue IPv6 Router Advertisements        October 2010

1.  Introduction

   The Neighbor Discovery protocol [RFC4861] describes the operation of
   IPv6 Router Advertisements (RAs) which are used to determine node
   configuration information during the IPv6 autoconfiguration process,
   whether that node's configuration is stateful via 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 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.  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 Neighbour Advertisement (NA) and
   related messages also.

2.  Bogus RA Scenarios

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

Chown & Venaas           Expires April 28, 2011                 [Page 4]
Internet-Draft      Rogue IPv6 Router Advertisements        October 2010

2.1.  Administrator misconfiguration

   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 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 service (ICS) which turns 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 too, 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           Expires April 28, 2011                 [Page 5]
Internet-Draft      Rogue IPv6 Router Advertisements        October 2010

   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 WG, 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.  Introduce 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
   [I-D.ietf-v6ops-ra-guard] 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 Neighbour
   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           Expires April 28, 2011                 [Page 6]
Internet-Draft      Rogue IPv6 Router Advertisements        October 2010

3.3.  Use 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 draft describes the RA message format(s) for filtering
   [I-D.nward-ipv6-autoconfig-filtering-ethernet].  This draft also
   notes requirements for DHCPv6 snooping, which can then be implemented
   similar 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           Expires April 28, 2011                 [Page 7]
Internet-Draft      Rogue IPv6 Router Advertisements        October 2010

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.  Rely 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.  Use 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.  Use 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 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           Expires April 28, 2011                 [Page 8]
Internet-Draft      Rogue IPv6 Router Advertisements        October 2010

   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.  Use 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 RFC2684 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.  Add 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 draft has proposed such a default
   router option, along with prefix advertisement options for DHCPv6
   [I-D.droms-dhc-dhcpv6-default-router].  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
   possible, making IPv6 configuration able to be done in a similar way

Chown & Venaas           Expires April 28, 2011                 [Page 9]
Internet-Draft      Rogue IPv6 Router Advertisements        October 2010

   to IPv4 today, the problem has only been shifted.  Rather than 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
   [I-D.nward-ipv6-autoconfig-filtering-ethernet].

   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 scenarios and practical mitigations
   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  |   Admin     |   User      |
        | Mitigation             |   Error     |   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           Expires April 28, 2011                [Page 10]
Internet-Draft      Rogue IPv6 Router Advertisements        October 2010

   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 RFC4861.  If a
   host sending rogues 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 vs 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           Expires April 28, 2011                [Page 11]
Internet-Draft      Rogue IPv6 Router Advertisements        October 2010

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

   An important issue is how readily a host can recover from receiving
   and processing bad configuration information, e.g. considering the '2
   hour rule' of Section 5.5.3 of RFC4862 (though this applies to the
   valid address lifetime not the router lifetime).  We should ensure

Chown & Venaas           Expires April 28, 2011                [Page 12]
Internet-Draft      Rogue IPv6 Router Advertisements        October 2010

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

   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.

Chown & Venaas           Expires April 28, 2011                [Page 13]
Internet-Draft      Rogue IPv6 Router Advertisements        October 2010

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. by including an extra column in the table in Section 4.
   However, the consensus of the v6ops WG feedback was to instead focus
   on the common operational problem seen today, of 'accidental' rogue
   RAs.

   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 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 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.  IANA Considerations

   There are no extra IANA consideration for this document.

9.  Acknowledgments

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

10.  Informative References

   [RFC2684]  Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation
              over ATM Adaptation Layer 5", RFC 2684, September 1999.

Chown & Venaas           Expires April 28, 2011                [Page 14]
Internet-Draft      Rogue IPv6 Router Advertisements        October 2010

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

   [I-D.ietf-v6ops-ra-guard]
              Levy-Abegnoli, E., Velde, G., Popoviciu, C., and J.
              Mohacsi, "IPv6 Router Advertisement Guard",
              draft-ietf-v6ops-ra-guard-08 (work in progress),
              September 2010.

   [I-D.nward-ipv6-autoconfig-filtering-ethernet]
              Ward, N., "IPv6 Autoconfig Filtering on Ethernet
              Switches",
              draft-nward-ipv6-autoconfig-filtering-ethernet-00 (work in
              progress), March 2009.

   [I-D.droms-dhc-dhcpv6-default-router]
              Droms, R. and T. Narten, "Default Router and Prefix
              Advertisement Options for DHCPv6",
              draft-droms-dhc-dhcpv6-default-router-00 (work in
              progress), March 2009.

Chown & Venaas           Expires April 28, 2011                [Page 15]
Internet-Draft      Rogue IPv6 Router Advertisements        October 2010

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           Expires April 28, 2011                [Page 16]