draft-ietf-v6ops-rogue-ra-01.txt   draft-ietf-v6ops-rogue-ra-02.txt 
IPv6 Operations T. Chown IPv6 Operations T. Chown
Internet-Draft University of Southampton Internet-Draft University of Southampton
Intended status: Informational S. Venaas Intended status: Informational S. Venaas
Expires: December 9, 2010 UNINETT Expires: April 28, 2011 Cisco Systems
June 7, 2010 October 25, 2010
Rogue IPv6 Router Advertisement Problem Statement Rogue IPv6 Router Advertisement Problem Statement
draft-ietf-v6ops-rogue-ra-01 draft-ietf-v6ops-rogue-ra-02
Abstract Abstract
When deploying IPv6, whether IPv6-only or dual-stack, routers are When deploying IPv6, whether IPv6-only or dual-stack, routers are
configured to send IPv6 Router Advertisements to convey information configured to send IPv6 Router Advertisements to convey information
to nodes that enable them to autoconfigure on the network. This to nodes that enable them to autoconfigure on the network. This
information includes the implied default router address taken from information includes the implied default router address taken from
the observed source address of the Router Advertisement (RA) message, the observed source address of the Router Advertisement (RA) message,
as well as on-link prefix information. However, unintended as well as on-link prefix information. However, unintended
misconfigurations by users or administrators, or possibly malicious misconfigurations by users or administrators, or possibly malicious
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 9, 2010. This Internet-Draft will expire on April 28, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 15 skipping to change at page 3, line 15
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Bogus RA Scenarios . . . . . . . . . . . . . . . . . . . . . . 4 2. Bogus RA Scenarios . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Administrator misconfiguration . . . . . . . . . . . . . . 5 2.1. Administrator misconfiguration . . . . . . . . . . . . . . 5
2.2. User misconfiguration . . . . . . . . . . . . . . . . . . 5 2.2. User misconfiguration . . . . . . . . . . . . . . . . . . 5
2.3. Malicious misconfiguration . . . . . . . . . . . . . . . . 5 2.3. Malicious misconfiguration . . . . . . . . . . . . . . . . 5
3. Methods to Mitigate against Rogue RAs . . . . . . . . . . . . 6 3. Methods to Mitigate against Rogue RAs . . . . . . . . . . . . 6
3.1. Manual configuration . . . . . . . . . . . . . . . . . . . 6 3.1. Manual configuration . . . . . . . . . . . . . . . . . . . 6
3.2. Introduce RA snooping . . . . . . . . . . . . . . . . . . 6 3.2. Introduce RA snooping . . . . . . . . . . . . . . . . . . 6
3.3. Use ACLs on Managed Switches . . . . . . . . . . . . . . . 6 3.3. Use ACLs on Managed Switches . . . . . . . . . . . . . . . 7
3.4. Secure Neighbor Discovery (SeND) . . . . . . . . . . . . . 7 3.4. Secure Neighbor Discovery (SeND) . . . . . . . . . . . . . 7
3.5. Router Preference Option . . . . . . . . . . . . . . . . . 7 3.5. Router Preference Option . . . . . . . . . . . . . . . . . 8
3.6. Rely on Layer 2 admission control . . . . . . . . . . . . 8 3.6. Rely on Layer 2 admission control . . . . . . . . . . . . 8
3.7. Use host-based packet filters . . . . . . . . . . . . . . 8 3.7. Use host-based packet filters . . . . . . . . . . . . . . 8
3.8. Use an 'intelligent' deprecation tool . . . . . . . . . . 8 3.8. Use an 'intelligent' deprecation tool . . . . . . . . . . 8
3.9. Wait before using new advertisements . . . . . . . . . . . 9 3.9. Use Layer 2 Partitioning . . . . . . . . . . . . . . . . . 9
3.10. Use Layer 2 Partitioning . . . . . . . . . . . . . . . . . 9 3.10. Add Default Gateway/Prefix Options to DHCPv6 . . . . . . . 9
3.11. Add Default Gateway/Prefix Options to DHCPv6 . . . . . . . 9
4. Scenarios and mitigations . . . . . . . . . . . . . . . . . . 10 4. Scenarios and mitigations . . . . . . . . . . . . . . . . . . 10
5. Other related considerations . . . . . . . . . . . . . . . . . 11 5. Other related considerations . . . . . . . . . . . . . . . . . 11
5.1. Unicast RAs . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Unicast RAs . . . . . . . . . . . . . . . . . . . . . . . 11
5.2. The DHCP vs RA threat model . . . . . . . . . . . . . . . 12 5.2. The DHCP vs RA threat model . . . . . . . . . . . . . . . 11
5.3. IPv4-only networks . . . . . . . . . . . . . . . . . . . . 12 5.3. IPv4-only networks . . . . . . . . . . . . . . . . . . . . 12
5.4. Network monitoring tools . . . . . . . . . . . . . . . . . 13 5.4. Network monitoring tools . . . . . . . . . . . . . . . . . 12
5.5. Recovering from bad configuration state . . . . . . . . . 13 5.5. Recovering from bad configuration state . . . . . . . . . 12
5.6. Isolating the offending rogue RA source . . . . . . . . . 13 5.6. Isolating the offending rogue RA source . . . . . . . . . 13
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
10. Informative References . . . . . . . . . . . . . . . . . . . . 15 10. Informative References . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
The Neighbor Discovery protocol [RFC4861] describes the operation of The Neighbor Discovery protocol [RFC4861] describes the operation of
IPv6 Router Advertisements (RAs) which are used to determine node IPv6 Router Advertisements (RAs) which are used to determine node
configuration information during the IPv6 autoconfiguration process, configuration information during the IPv6 autoconfiguration process,
whether that node's configuration is stateful (via DHCPv6 [RFC3315]) whether that node's configuration is stateful via Dynamic Host
or stateless (as per [RFC4862], possibly in combination with DHCPv6 Configuration Protocol for IPv6 (DHCPv6) [RFC3315] or stateless, as
Light [RFC3736]). per [RFC4862], possibly in combination with DHCPv6 Light [RFC3736].
In observing the operation of deployed IPv6 networks, it is apparent In observing the operation of deployed IPv6 networks, it is apparent
that there is a problem with undesired or 'bogus' IPv6 Router that there is a problem with undesired or 'bogus' IPv6 Router
Advertisements (RAs) appearing on network links or subnets. By Advertisements (RAs) appearing on network links or subnets. By
'bogus' we mean RAs that were not the intended configured RAs, rather 'bogus' we mean RAs that were not the intended configured RAs, rather
RAs that have appeared for some other reason. While the problem RAs that have appeared for some other reason. While the problem
appears more common in shared wireless environments, it is also seen appears more common in shared wireless environments, it is also seen
on wired enterprise networks. on wired enterprise networks.
The problem with rogue RAs is that they can cause partial or complete The problem with rogue RAs is that they can cause partial or complete
skipping to change at page 4, line 44 skipping to change at page 4, line 44
recover from a state where host configuration is incorrect as a recover from a state where host configuration is incorrect as a
result of processing such an RA. result of processing such an RA.
In the next section, we discuss the scenarios that may give rise to In the next section, we discuss the scenarios that may give rise to
rogue RAs being present. In the following section we present some rogue RAs being present. In the following section we present some
candidate solutions for the problem, some of which may be more candidate solutions for the problem, some of which may be more
practical to deploy than others. This document focuses on practical to deploy than others. This document focuses on
'accidental' rogue RAs; while malicious RAs are of course also 'accidental' rogue RAs; while malicious RAs are of course also
possible, the common problem today lies with unintended RAs. In possible, the common problem today lies with unintended RAs. In
addition a network experiencing malicious attack of this kind is addition a network experiencing malicious attack of this kind is
likely to also experience malicious NA and related messages also. likely to also experience malicious Neighbour Advertisement (NA) and
related messages also.
2. Bogus RA Scenarios 2. Bogus RA Scenarios
There are three broad classes of scenario in which bogus RAs may be There are three broad classes of scenario in which bogus RAs may be
introduced to an IPv6 network. introduced to an IPv6 network.
2.1. Administrator misconfiguration 2.1. Administrator misconfiguration
Here an administrator incorrectly configures RAs on a router Here an administrator incorrectly configures RAs on a router
interface, causing incorrect RAs to appear on links and hosts to interface, causing incorrect RAs to appear on links and hosts to
generate incorrect or unintended IPv6 address, gateway or other generate incorrect or unintended IPv6 address, gateway or other
information. In such a case the default gateway may be correct, but information. In such a case the default gateway may be correct, but
a host might for example become multi-addressed, possibly with a a host might for example become multi-addressed, possibly with a
correct and incorrect address based on a correct and incorrect correct and incorrect address based on a correct and incorrect
prefix. There is also the possibility of other configuration prefix. There is also the possibility of other configuration
information being misconfigured, such as the lifetime option. information being misconfigured, such as the lifetime option.
In the case of a Layer 2 VLAN misconfiguration, RAs may 'flood' to In the case of a Layer 2 IEEE 802.1Q Virtual LAN (VLAN)
unintended links, causing hosts or more than one link to potentially misconfiguration, RAs may 'flood' to unintended links, causing hosts
become incorrectly multiaddressed, with possibly two different or more than one link to potentially become incorrectly
default routers available. multiaddressed, with possibly two different default routers
available.
2.2. User misconfiguration 2.2. User misconfiguration
In this case a user's device 'accidentally' transmits RAs onto the In this case a user's device 'accidentally' transmits RAs onto the
local link, potentially adding an additional default gateway and local link, potentially adding an additional default gateway and
associated prefix information. associated prefix information.
This seems to typically be seen on wireless (though sometimes wired) This seems to typically be seen on wireless (though sometimes wired)
networks where a laptop has enabled the Windows Internet Connection networks where a laptop has enabled the Windows Internet Connection
Sharing service (ICS) which turns a host into a 6to4 [RFC3056] Sharing service (ICS) which turns a host into a 6to4 [RFC3056]
skipping to change at page 6, line 6 skipping to change at page 6, line 8
2.3. Malicious misconfiguration 2.3. Malicious misconfiguration
Here an attacker is deliberately generating RAs on the local network 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- in an attempt to perform some form of denial of service or man-in-
the-middle attack. the-middle attack.
As stated above, while this is a genuine concern for network As stated above, while this is a genuine concern for network
administrators, there have been few if any reports of such activity, administrators, there have been few if any reports of such activity,
while in contrast reports of accidental rogue RAs are very while in contrast reports of accidental rogue RAs are very
commonplace. In writing this text we came to the conclusion that the commonplace. In writing this text, and with the feedback of the
issue of malicious attack, due to the other complementary attacks v6ops WG, we came to the conclusion that the issue of malicious
that are likely to be launched using rogue NA and similar messages, attack, due to the other complementary attacks that are likely to be
are best considered elsewhere. As a result, this text intends to 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 provide informational guidance for operators looking for practical
measures to take to avoid unintended rogue RAs on their own networks. measures to take to avoid 'accidental' rogue RAs on their own
networks.
3. Methods to Mitigate against Rogue RAs 3. Methods to Mitigate against Rogue RAs
In this section we present a summary of methods suggested to date for 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 reducing or removing the possibility of rogue RAs being seen on a
network. network.
3.1. Manual configuration 3.1. Manual configuration
The default gateway and host address can usually be manually The default gateway and host address can usually be manually
configured on a node. This is of course can be a resource intensive configured on a node. This of course can be a resource intensive
solution, and also prone to administrative mistakes in itself. solution, and also prone to administrative mistakes in itself.
Manual configuration implies that RA processing is disabled. Most Manual configuration implies that RA processing is disabled. Most
operating systems allow RA messages to be ignored, such that if an operating systems allow RA messages to be ignored, such that if an
IPv6 address is manually configured on a system, an additional global IPv6 address is manually configured on a system, an additional global
autoconfigured address will not be added should an unexpected RA autoconfigured address will not be added should an unexpected RA
appear on the link. appear on the link.
3.2. Introduce RA snooping 3.2. Introduce RA snooping
It should be possible to implement 'RA snooping' in Layer 2 switches It should be possible to implement 'RA snooping' in Layer 2 switches
in a similar way to DHCP snooping, such that RAs observed from in a similar way to DHCP snooping, such that RAs observed from
incorrect sources are blocked or dropped, and not propagated through incorrect sources are blocked or dropped, and not propagated through
a subnet. One candidate solution in this space called RA-Guard a subnet. One candidate solution in this space called RA-Guard
[I-D.ietf-v6ops-ra-guard] has been proposed. This type of solution [I-D.ietf-v6ops-ra-guard] has been proposed. This type of solution
has appeal because it is a familiar model for enterprise network has appeal because it is a familiar model for enterprise network
managers, but it can also be used to complement SeND, by a switch managers, but it can also be used to complement Secure Neighbour
acting as a SeND proxy for hosts. 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 This type of solution may not be applicable everywhere, e.g. in
environments where there are not centrally controlled or manageable environments where there are not centrally controlled or manageable
switches. switches.
3.3. Use ACLs on Managed Switches 3.3. Use ACLs on Managed Switches
Certain switch platforms can already implement some level of rogue RA Certain switch platforms can already implement some level of rogue RA
filtering by the administrator configuring Access Control Lists filtering by the administrator configuring Access Control Lists
(ACLs) that block RA ICMP messages that might be inbound on 'user' (ACLs) that block RA ICMP messages that might be inbound on 'user'
skipping to change at page 7, line 26 skipping to change at page 7, line 32
Thus it can in principle protect a network against rogue RAs. 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 SeND is not yet widely used at the time of writing, in part because
there are very few implementations of the protocol. Some other there are very few implementations of the protocol. Some other
deployment issues have been raised, though these are likely to be deployment issues have been raised, though these are likely to be
resolved in due course. For example, routers probably don't want to resolved in due course. For example, routers probably don't want to
use autogenerated addresses (which might need to be protected by use autogenerated addresses (which might need to be protected by
ACLs) so SeND needs to be shown to work with non autogenerated ACLs) so SeND needs to be shown to work with non autogenerated
addresses. Also, it has been argued that there are 'bootstrapping' addresses. Also, it has been argued that there are 'bootstrapping'
issues, in that hosts wanting to validate router credentials (e.g. to issues, in that hosts wanting to validate router credentials (e.g. to
a certificate server or NTP server) are likely to need to communicate a certificate server or Network Time Protocol (NTP) server) are
via the router for that information. likely to need to communicate via the router for that information.
Further, it's not wholly clear how widely adopted SeND could or would Further, it's not wholly clear how widely adopted SeND could or would
be in site networks with 'lightweight' security (e.g. many campus be in site networks with 'lightweight' security (e.g. many campus
networks), especially where hosts are managed by users and not networks), especially where hosts are managed by users and not
administratively. Public or conference wireless networks may face administratively. Public or conference wireless networks may face
similar challenges. There may also be networks, like perhaps sensor similar challenges. There may also be networks, like perhaps sensor
networks, where use of SeND is less practical. These networks still networks, where use of SeND is less practical. These networks still
require rogue RA protection. require rogue RA protection.
While SeND clearly can provide a good, longer term solution, While SeND clearly can provide a good, longer term solution,
skipping to change at page 8, line 5 skipping to change at page 8, line 14
3.5. Router Preference Option 3.5. Router Preference Option
[RFC4191] introduced a router preference option, such that an RA [RFC4191] introduced a router preference option, such that an RA
could carry one of three router preference values: High, Medium could carry one of three router preference values: High, Medium
(default) or Low. Thus an administrator could use High settings for (default) or Low. Thus an administrator could use High settings for
managed RAs, and hope that 'accidental' RAs would be medium priority. managed RAs, and hope that 'accidental' RAs would be medium priority.
This of course would only work in some scenarios - if the user who 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 accidentally sends out a rogue RA on the network has configured their
device with High precedence for their own intended usage, the device with High precedence for their own intended usage, the
priorities would clash. But for accidental problems like Windows ICS priorities would clash. But for accidental rogue RAs caused by
and 6to4, it could be useful. Obviously this solution would also software like Windows ICS and 6to4, which would use the default
rely on clients (and routers) having implementations of the protocol. 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 3.6. Rely on Layer 2 admission control
In principle, if a technology such as IEEE 802.1x is used, devices 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 would first need to authenticate to the network before being able to
send or receive IPv6 traffic. Ideally authentication would be send or receive IPv6 traffic. Ideally authentication would be
mutual. Deployment of 802.1x, with mutual authentication, may mutual. Deployment of 802.1x, with mutual authentication, may
however be seen as somewhat 'heavyweight' akin to SeND, for some however be seen as somewhat 'heavyweight' akin to SeND, for some
deployments. deployments.
skipping to change at page 9, line 7 skipping to change at page 9, line 17
would need to somehow know what 'good' and 'bad' RAs are, from some would need to somehow know what 'good' and 'bad' RAs are, from some
combination of known good sources and/or link prefixes. In an combination of known good sources and/or link prefixes. In an
environment with native IPv6 though, 6to4-based RAs would certainly environment with native IPv6 though, 6to4-based RAs would certainly
be known to be rogue. be known to be rogue.
Whether or not use of such a tool is the preferred method, monitoring Whether or not use of such a tool is the preferred method, monitoring
a link for observed RAs seems prudent from a network management a link for observed RAs seems prudent from a network management
perspective. Some such tools exist already, e.g. NDPMon, which can perspective. Some such tools exist already, e.g. NDPMon, which can
also detect other undesirable behaviour. also detect other undesirable behaviour.
3.9. Wait before using new advertisements 3.9. Use Layer 2 Partitioning
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). In general, this
does not seem to be an attractive solution.
3.10. Use Layer 2 Partitioning
If each system or user on a network is partitioned into a different 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 Layer 2 medium, then the impact of rogue RAs can be limited. In
broadband networks RFC2684 bridging [RFC2684] may be available, for broadband networks RFC2684 bridging [RFC2684] may be available, for
example. The benefit may be scenario-specific, e.g. whether a given example. The benefit may be scenario-specific, e.g. whether a given
user or customer has their own network prefix or whether the user or customer has their own network prefix or whether the
provisioning is in a shared subnet or link. It is certainly provisioning is in a shared subnet or link. It is certainly
desirable that any given user or customer's system(s) are unable to desirable that any given user or customer's system(s) are unable to
see RAs that may be generated by other users or customers. see RAs that may be generated by other users or customers.
However, such partitioning would probably increase address space However, such partitioning would probably increase address space
consumption significantly if applied in enterprise networks, and in consumption significantly if applied in enterprise networks, and in
many cases hardware costs and software licensing costs to enable many cases hardware costs and software licensing costs to enable
routing to the edge can be quite significant. routing to the edge can be quite significant.
3.11. Add Default Gateway/Prefix Options to DHCPv6 3.10. Add Default Gateway/Prefix Options to DHCPv6
Adding Default Gateway and Prefix options for DHCPv6 would allow Adding Default Gateway and Prefix options for DHCPv6 would allow
network administrators to configure hosts to only use DHCPv6 for network administrators to configure hosts to only use DHCPv6 for
default gateway and prefix configuration in managed networks, where default gateway and prefix configuration in managed networks, where
RAs would be required today. A new draft has proposed such a default RAs would be required today. A new draft has proposed such a default
router option, along with prefix advertisement options for DHCPv6 router option, along with prefix advertisement options for DHCPv6
[I-D.droms-dhc-dhcpv6-default-router]. Even with such options added [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 to DHCPv6, an RA is in principle still required to inform hosts to
use DHCPv6. use DHCPv6.
skipping to change at page 10, line 23 skipping to change at page 10, line 20
There is certainly some demand in the community for DHCPv6-only host There is certainly some demand in the community for DHCPv6-only host
configuration. While this may mitigate the rogue RA issue, it simply configuration. While this may mitigate the rogue RA issue, it simply
moves the trust problem elsewhere, albeit to a place administrators moves the trust problem elsewhere, albeit to a place administrators
are familiar with today. are familiar with today.
4. Scenarios and mitigations 4. Scenarios and mitigations
In this section we summarise the scenarios and practical mitigations In this section we summarise the scenarios and practical mitigations
described above in a matrix format. We consider, for the case of a described above in a matrix format. We consider, for the case of a
rogue multicast RA, which of the mitigation methods helps protect rogue multicast RA, which of the mitigation methods helps protect
against each cause. For the administrator error, we discount an against administrator and user errors. For the administrator error,
error in configuring the countermeasure itself, rather we consider an we discount an error in configuring the countermeasure itself, rather
administrator error to be an error in configuration elsewhere in the we consider an administrator error to be an error in configuration
network. elsewhere in the network.
+------------------------+-------------+-------------+ +------------------------+-------------+-------------+
| Scenario | Admin | User | | Scenario | Admin | User |
| Mitigation | Error | Error | | Mitigation | Error | Error |
+------------------------+-------------+-------------+ +------------------------+-------------+-------------+
| Manual configuration | Y | Y | | Manual configuration | Y | Y |
+------------------------+-------------+-------------+ +------------------------+-------------+-------------+
| SeND | Y | Y | | SeND | Y | Y |
+------------------------+-------------+-------------+ +------------------------+-------------+-------------+
| RA snooping | Y | Y | | RA snooping | Y | Y |
skipping to change at page 11, line 25 skipping to change at page 10, line 45
| Use switch ACLs | Y | Y | | Use switch ACLs | Y | Y |
+------------------------+-------------+-------------+ +------------------------+-------------+-------------+
| Router preference | N | Y | | Router preference | N | Y |
+------------------------+-------------+-------------+ +------------------------+-------------+-------------+
| Layer 2 admission | N | N | | Layer 2 admission | N | N |
+------------------------+-------------+-------------+ +------------------------+-------------+-------------+
| Host firewall | Y | Y | | Host firewall | Y | Y |
+------------------------+-------------+-------------+ +------------------------+-------------+-------------+
| Deprecation daemon | Y | Y | | Deprecation daemon | Y | Y |
+------------------------+-------------+-------------+ +------------------------+-------------+-------------+
| New prefix delay | Partly | Partly |
+------------------------+-------------+-------------+
| Layer 2 partition | N | Y | | Layer 2 partition | N | Y |
+------------------------+-------------+-------------+ +------------------------+-------------+-------------+
| DHCPv6 gateway option | Partly | If Auth | | DHCPv6 gateway option | Partly | If Auth |
+------------------------+-------------+-------------+ +------------------------+-------------+-------------+
What the above summary does not consider is the practicality of What the above summary does not consider is the practicality of
deploying the measure. An easy-to-deploy method that buys improved deploying the measure. An easy-to-deploy method that buys improved
resilience to rogue RAs without significant administrative overhead resilience to rogue RAs without significant administrative overhead
is attractive. On that basis the RA snooping proposal, e.g. RA is attractive. On that basis the RA snooping proposal, e.g. RA
Guard, has merit, while approaches like manual configuration are less Guard, has merit, while approaches like manual configuration are less
skipping to change at page 13, line 26 skipping to change at page 12, line 46
RA can be configured in a trustworthy manner within the network's RA can be configured in a trustworthy manner within the network's
management framework. management framework.
5.5. Recovering from bad configuration state 5.5. Recovering from bad configuration state
After a host receives and processes a rogue RA, it may have multiple After a host receives and processes a rogue RA, it may have multiple
default gateways, global addresses, and potentially clashing RA default gateways, global addresses, and potentially clashing RA
options (e.g. M/O bits). The host's behaviour may then be 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 unpredictable, in terms of the default router that is used, and the
(source) address(es) used in communications. A host that is aware of (source) address(es) used in communications. A host that is aware of
protocols such as shim6 may believe it is genuinely multihomed. protocols such as shim6 RFC5533 [RFC5533] may believe it is genuinely
multihomed.
An important issue is how readily a host can recover from receiving An important issue is how readily a host can recover from receiving
and processing bad configuration information, e.g. considering the '2 and processing bad configuration information, e.g. considering the '2
hour rule' of Section 5.5.3 of RFC4862 (though this applies to the hour rule' of Section 5.5.3 of RFC4862 (though this applies to the
valid address lifetime not the router lifetime). We should ensure valid address lifetime not the router lifetime). We should ensure
that methods exist for a network administrator to correct bad that methods exist for a network administrator to correct bad
configuration information on a link or subnet, and that OS platforms configuration information on a link or subnet, and that OS platforms
support these methods. At least if the problem can be detected, and support these methods. At least if the problem can be detected, and
corrected promptly, the impact is minimised. corrected promptly, the impact is minimised.
skipping to change at page 14, line 22 skipping to change at page 13, line 42
solution, e.g. campus networks, or wireless conference or public solution, e.g. campus networks, or wireless conference or public
networks. For such scenarios, simpler measures are desirable. networks. For such scenarios, simpler measures are desirable.
Adding new DHCPv6 Default Gateway and Prefix Options would allow IPv6 Adding new DHCPv6 Default Gateway and Prefix Options would allow IPv6
host configuration by DHCP only, and be a method that IPv4 host configuration by DHCP only, and be a method that IPv4
administrators are comfortable with (for better or worse), but this administrators are comfortable with (for better or worse), but this
simply shifts the robustness issue elsewhere. simply shifts the robustness issue elsewhere.
While a number of the mitigations described above have their appeal, While a number of the mitigations described above have their appeal,
the simplest solutions probably lie in switch-based ACLs and RA-Guard the simplest solutions probably lie in switch-based ACLs and RA-Guard
style approaches. Where managed switches are no available, use of style approaches. Where managed switches are not available, use of
the Router Preference option and (moreso in managed desktop the Router Preference option and (more so in managed desktop
environments) host firewalls may be appropriate. environments) host firewalls may be appropriate.
In the longer term wider experience of SeND will be beneficial, while In the longer term wider experience of SeND will be beneficial, while
the use of RA snooping will remain useful either to complement SeND 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 (where a switch running RA Guard can potentially be a SeND proxy) or
to assist in scenarios for which SeND is not deployed. to assist in scenarios for which SeND is not deployed.
7. Security Considerations 7. Security Considerations
This document is Informational. It does not describe solutions for This Informational document is focused on discussing solutions to
malicious attacks on a network for which malicious RAs may be part of operational problems caused by rogue RAs resulting from unintended
a broader attack, e.g. including malicious NA messages. 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 8. IANA Considerations
There are no extra IANA consideration for this document. There are no extra IANA consideration for this document.
9. Acknowledgments 9. Acknowledgments
Thanks are due to members of the IETF IPv6 Operations and DHCP WGs 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 for their inputs on this topic, as well as some comments from various
operational mailing lists, and private comments, including but not operational mailing lists, and private comments, including but not
skipping to change at page 15, line 38 skipping to change at page 15, line 32
Renumbering an IPv6 Network without a Flag Day", RFC 4192, Renumbering an IPv6 Network without a Flag Day", RFC 4192,
September 2005. September 2005.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007. 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] [I-D.ietf-v6ops-ra-guard]
Levy-Abegnoli, E., Velde, G., Popoviciu, C., and J. Levy-Abegnoli, E., Velde, G., Popoviciu, C., and J.
Mohacsi, "IPv6 RA-Guard", draft-ietf-v6ops-ra-guard-05 Mohacsi, "IPv6 Router Advertisement Guard",
(work in progress), May 2010. draft-ietf-v6ops-ra-guard-08 (work in progress),
September 2010.
[I-D.nward-ipv6-autoconfig-filtering-ethernet] [I-D.nward-ipv6-autoconfig-filtering-ethernet]
Ward, N., "IPv6 Autoconfig Filtering on Ethernet Ward, N., "IPv6 Autoconfig Filtering on Ethernet
Switches", Switches",
draft-nward-ipv6-autoconfig-filtering-ethernet-00 (work in draft-nward-ipv6-autoconfig-filtering-ethernet-00 (work in
progress), March 2009. progress), March 2009.
[I-D.droms-dhc-dhcpv6-default-router] [I-D.droms-dhc-dhcpv6-default-router]
Droms, R. and T. Narten, "Default Router and Prefix Droms, R. and T. Narten, "Default Router and Prefix
Advertisement Options for DHCPv6", Advertisement Options for DHCPv6",
skipping to change at page 16, line 19 skipping to change at page 16, line 16
Tim Chown Tim Chown
University of Southampton University of Southampton
Highfield Highfield
Southampton, Hampshire SO17 1BJ Southampton, Hampshire SO17 1BJ
United Kingdom United Kingdom
Email: tjc@ecs.soton.ac.uk Email: tjc@ecs.soton.ac.uk
Stig Venaas Stig Venaas
UNINETT Cisco Systems
Trondheim NO 7465 Tasman Drive
Norway San Jose, CA 95134
USA
Email: venaas@uninett.no Email: stig@cisco.com
 End of changes. 29 change blocks. 
65 lines changed or deleted 83 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/