draft-ietf-v6ops-rogue-ra-00.txt   draft-ietf-v6ops-rogue-ra-01.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: November 28, 2009 UNINETT Expires: December 9, 2010 UNINETT
May 27, 2009 June 7, 2010
Rogue IPv6 Router Advertisement Problem Statement Rogue IPv6 Router Advertisement Problem Statement
draft-ietf-v6ops-rogue-ra-00 draft-ietf-v6ops-rogue-ra-01
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 Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79.
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.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on December 9, 2010.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 28, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract 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.
When deploying IPv6, whether IPv6-only or dual-stack, routers are This document may contain material from IETF Documents or IETF
configured to send IPv6 Router Advertisements to convey information Contributions published or made publicly available before November
to nodes that enable them to autoconfigure on the network. This 10, 2008. The person(s) controlling the copyright in some of this
information includes the implied default router address taken from material may not have granted the IETF Trust the right to allow
the observed source address of the Router Advertisement (RA) message, modifications of such material outside the IETF Standards Process.
as well as on-link prefix information. However, unintended Without obtaining an adequate license from the person(s) controlling
misconfigurations by users or administrators, or possibly malicious the copyright in such materials, this document may not be modified
attacks on the network, may lead to bogus RAs being present, which in outside the IETF Standards Process, and derivative works of it may
turn can cause operational problems for hosts on the network. In not be created outside the IETF Standards Process, except to format
this draft we summarise the scenarios in which rogue RAs may be it for publication as an RFC or to translate it into languages other
observed and present a list of possible solutions to the problem. We than English.
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.
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
skipping to change at page 9, line 23 skipping to change at page 9, line 23
or accidental RA to be detected and stopped, before hosts use the 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 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 RAs are required, while new hosts appearing on a network would still
be vulnerable (or be unable to configure at all). In general, this be vulnerable (or be unable to configure at all). In general, this
does not seem to be an attractive solution. does not seem to be an attractive solution.
3.10. Use Layer 2 Partitioning 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 RFC1483 bridging [RFC1483] 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.
skipping to change at page 10, line 21 skipping to change at page 10, line 21
[I-D.nward-ipv6-autoconfig-filtering-ethernet]. [I-D.nward-ipv6-autoconfig-filtering-ethernet].
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 summary matrix. 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 protects against rogue multicast RA, which of the mitigation methods helps protect
each cause. For the administrator error, we discount an error in against each cause. For the administrator error, we discount an
configuring the countermeasure itself, rather we consider an error in configuring the countermeasure itself, rather we consider an
administrator error to be an error in configuration elsewhere in the administrator error to be an error in configuration elsewhere in the
network. 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 |
skipping to change at page 15, line 8 skipping to change at page 15, line 8
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
limited to: Iljitsch van Beijnum, Dale Carder, Remi Denis-Courmont, limited to: Iljitsch van Beijnum, Dale Carder, Remi Denis-Courmont,
Tony Hain, Bob Hinden, Christian Huitema, Tatuya Jinmei, Eric Levy- Tony Hain, Bob Hinden, Christian Huitema, Tatuya Jinmei, Eric Levy-
Abegnoli, David Malone, Thomas Narten, Chip Popoviciu, Dave Thaler, Abegnoli, David Malone, Thomas Narten, Chip Popoviciu, Dave Thaler,
Gunter Van de Velde, Goeran Weinholt and Dan White. Gunter Van de Velde, Goeran Weinholt and Dan White.
10. Informative References 10. Informative References
[RFC1483] Heinanen, J., "Multiprotocol Encapsulation over ATM [RFC2684] Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation
Adaptation Layer 5", RFC 1483, July 1993. over ATM Adaptation Layer 5", RFC 2684, September 1999.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001. via IPv4 Clouds", RFC 3056, February 2001.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004. (DHCP) Service for IPv6", RFC 3736, April 2004.
skipping to change at page 15, line 40 skipping to change at page 15, line 40
[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.
[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-02 Mohacsi, "IPv6 RA-Guard", draft-ietf-v6ops-ra-guard-05
(work in progress), March 2009. (work in progress), May 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",
 End of changes. 12 change blocks. 
55 lines changed or deleted 55 lines changed or added

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