draft-ietf-v6ops-ra-guard-00.txt   draft-ietf-v6ops-ra-guard-01.txt 
v6ops Working Group G. Van de Velde v6ops Working Group E. Levy-Abegnoli
Internet-Draft E. Levy-Abegnoli Internet-Draft G. Van de Velde
Expires: January 2, 2009 C. Popoviciu Expires: March 14, 2009 C. Popoviciu
Cisco Systems Cisco Systems
J. Mohacsi J. Mohacsi
NIIF/Hungarnet NIIF/Hungarnet
July 1, 2008 September 10, 2008
IPv6 RA-Guard IPv6 RA-Guard
<draft-ietf-v6ops-ra-guard-00.txt> <draft-ietf-v6ops-ra-guard-01.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 2, 2009. This Internet-Draft will expire on March 14, 2009.
Abstract Abstract
When using IPv6 within a single L2 network segment it is neccesary to It is particularly easy to experience "rogue" routers on an unsecured
ensure that all routers advertising their services within it are link. Devices acting as a rougue router may send illegitimate RAs.
valid. In cases where it is not convinient or possible to use SeND Section 6 of SeND [RFC3971] provides a full solution to this problem,
[RFC3971] a rogue Router Advertisement (RA) [RFC4861] could be sent by enabling routers certification. This solution does, however,
by accident due to misconfiguraton or ill intended. Simple solutions require all nodes on an L2 network segment to support SeND, as well
for protecting against rogue RAs are beneficial in complementing SeND as it carries some deployment challenges. End-nodes must be
in securing the L2 domain for ceratin types of devices or in certain provisioned with certificate anchors. The solution works better when
transitional situations. end-nodes have access to a Certificate Revocation List server, and to
a Network Time Protocol server, both typically off-link, which brings
some bootstrap issues.
This document proposes a solution to reduce the threat of rogue RAs When using IPv6 within a single L2 network segment it is possible and
by enabling layer 2 devices to forward only RAs received over sometimes desirable to enable layer 2 devices to drop rogue RAs
designated ports. before they reach end-nodes. In order to distinguish valid from
rogue RAs, the L2 devices can use a spectrum of criterias, from a
static scheme that blocks RAs received on un-trusted ports, or from
un-trusted sources, to a more dynamic scheme that uses SeND to
challenge RA sources.
This document reviews various techniques applicable on the L2 devices
to reduce the threat of rogue RAs.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. RA-guard as a deployment complement to SEND . . . . . . . . . . 3 2. Model and Applicability . . . . . . . . . . . . . . . . . . . 3
3. RA-Guard state-machine . . . . . . . . . . . . . . . . . . . . 4 3. Stateless RA-Guard . . . . . . . . . . . . . . . . . . . . . . 5
3.1. RA-Guard state: OFF . . . . . . . . . . . . . . . . . . . . 4 4. Stateful RA-Guard . . . . . . . . . . . . . . . . . . . . . . 5
3.2. RA-Guard state: LEARNING . . . . . . . . . . . . . . . . . 4 4.1. State Machine . . . . . . . . . . . . . . . . . . . . . . 5
3.3. RA-Guard state: ACTIVE . . . . . . . . . . . . . . . . . . 5 4.2. SeND-based RA-Guard . . . . . . . . . . . . . . . . . . . 6
4. RA-Guard interface states . . . . . . . . . . . . . . . . . . . 5 5. RA-Guard Use Considerations . . . . . . . . . . . . . . . . . 7
4.1. RA-Blocking interface . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
4.2. RA-Forwarding interface . . . . . . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
4.3. RA-Learning interface . . . . . . . . . . . . . . . . . . . 5 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
4.4. RA-Guard interface state transition . . . . . . . . . . . . 5 9. Normative References . . . . . . . . . . . . . . . . . . . . . 7
5. RA-Guard Use Considerations . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 Intellectual Property and Copyright Statements . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
9. Normative References . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . . . 9
1. Introduction 1. Introduction
When operating IPv6 in a shared L2 network segment without complete When operating IPv6 in a shared L2 network segment without complete
SeND support by all devices connected or without the availability of SeND support by all devices connected or without the availability of
the infrastructure neccesary to support SeND, there is always the the infrastructure necessary to support SeND, there is always the
risk of facing operational problems due to rogue Router risk of facing operational problems due to rogue Router
Advertisements generated malliciously or unintentionaly by Advertisements generated maliciously or unintentionally by
unauthorized or improperly configured routers connecting to the unauthorized or improperly configured routers connecting to the
segment. segment.
There are several examples of work done on this topic which resulted There are several examples of work done on this topic which resulted
in several related studies [reference1] [reference2] in several related studies [reference1] [reference2]
[reference3].This document describes a solution framework to the [reference3].This document describes a solution framework for the
rogue-RA problem where network segments are designed around a single rogue-RA problem where network segments are designed around a single
or a set of L2-switching devices capable of identifying invalid RAs or a set of L2-switching devices capable of identifying invalid RAs
and blocking them. The solutions developed within this framework can and blocking them. The solutions developed within this framework can
span the spectrum from basic (where the port of the L2 device is span the spectrum from basic (where the port of the L2 device is
statically instructed to forward or not to forward RAs received from statically instructed to forward or not to forward RAs received from
the connected device) to advanced (where a criteria is used by the L2 the connected device) to advanced (where a criteria is used by the L2
device to dynamically validate or invalidate a received RA, this device to dynamically validate or invalidate a received RA, this
criteria can even be based on SeND mechanisms). criteria can even be based on SeND mechanisms).
2. RA-guard as a deployment complement to SEND 2. Model and Applicability
RA-guard does not intend to provide a substitute for SeND based RA-Guard applies to an environment where all messages between IPv6
end-devices traverse the controlled L2 networking devices. It does
not apply to a shared media such as an Ethernet hub, when devices can
communicate directly without going through an RA-Guard capable L2
networking device.
Figure 1 illustrates a deployment scenario for RA-Guard.
Block Allow
+------+ incoming +---------+ incoming +--------+
|Host | RA | L2 | RA | Router |
| |--------\--------| device |--------/------| |
+------+ \ +----+----+ / +--------+
\ | /
\ |Block /
\ |incoming /
\ |RA /
\_______|_______/
|
|
+---+---+
| Host |
| |
+-------+
RA-Guard does not intend to provide a substitute for SeND based
solutions. It actually intends to provide complementary solutions in solutions. It actually intends to provide complementary solutions in
those environments where SeND might not be suitable or fully those environments where SeND might not be suitable or fully
supported by all devices involved. It may take time untill SeND is supported by all devices involved. It may take time until SeND is
ubiquitous in IPv6 networks and some of its large scale deployment ubiquitous in IPv6 networks and some of its large scale deployment
aspects are sorted out such as provisioning hosts with trust anchors. aspects are sorted out such as provisioning hosts with trust anchors.
It is also reasonable to expect that some devices might not consider It is also reasonable to expect that some devices might not consider
implementing SeND at all such as IPv6 enabled sensors. The RA-guard implementing SeND at all such as IPv6 enabled sensors. An RA-Guard
"SeND-validating" RA on behalf of hosts would potentially simplify implementation which SeND-validates RAs on behalf of hosts would
some of these challenges. potentially simplify some of these challenges.
RA-guard can be seen as a superset of SEND with regard to router RA-Guard can be seen as a superset of SEND with regard to router
authorization. Its purpose is to filter Router Advertizements based authorization. Its purpose is to filter Router Advertisements based
on a set of criterias, from a simplistic "RA dis-allowed on a given on a set of criterias, from a simplistic "RA disallowed on a given
interface" to "RA allowed from pre-defined sources" and up to full interface" to "RA allowed from pre-defined sources" and up to full
SEND fledge "RA allowed from authorized sources only". fladge SeND "RA allowed from authorized sources only".
In addition to this granularity on the criteria for filtering out In addition to this granularity on the criteria for filtering out
Router Advertizements, RA-guard introduces the concept of router Router Advertisements, RA-Guard introduces the concept of router
authorization proxy. Instead of each node on the link analysing RAs authorization proxy. Instead of each node on the link analyzing RAs
and making an individual decision, a legitimate node-in-the-middle and making an individual decision, a legitimate node-in-the-middle
performs the analysis on behalf of all other nodes on the link. The performs the analysis on behalf of all other nodes on the link. The
analysis itself is not different from what each node would do: if analysis itself is not different from what each node would do: if
SeND is enabled, the RA is checked against X.509 certificates. If SeND is enabled, the RA is checked against X.509 certificates. If
any other criteria is in use, such as known L3 (addresses) or L2 any other criteria is in use, such as known L3 (addresses) or L2
(link-layer address, port number) legitimate sources of RAs, the (link-layer address, port number) legitimate sources of RAs, the
node-in-the middle can use this criteria and filter out any RA that node-in-the middle can use this criteria and filter out any RA that
does not comply. If this node-in-the-middle is a L2 device, it will does not comply. If this node-in-the-middle is a L2 device, it will
not change the content of the validated RA, and avoid any of the nd- not change the content of the validated RA, and avoid any of the nd-
proxy pitfalls. proxy pitfalls.
RA-guard intends to provide simple solutions to the rogue-RA problem RA-Guard intends to provide simple solutions to the rogue-RA problem
in contexts where simplicity is required while leveraging SeND in in contexts where simplicity is required while leveraging SeND in an
context with a mix of SeND capable devices (L2 switches and routers) context environment consisting of with a mix of SeND capable devices
and devices that do not consistently use SeND. Futhermore, RA-guard (L2 switches and routers) and devices that do not consistently use
is useful to simplify SeND deployments, as only the L2 switch and the SeND. Furthermore, RA-Guard is useful to simplify SeND deployments,
routers are required to carry certificates -their own and the trust as only the L2 switch and the routers are required to carry
anchor certificates-. certificates (their own and the trust anchor certificates).
3. RA-Guard state-machine
RA-Guard runs on devices that provide connectivity between hosts and
other hosts or networking devices. An example of such RA-Guard
capable device would be an OSI Layer-2 switch. The capability can be
enabled globally at device level or at interface level.
When RA-Guard is SEND-based, the timing of the learning phase, as
well as the overall behavior of the device doing RA-guard is as-
defined in [RFC3971].
When RA-guard is using more static criterias, the state-machine of
the RA-Guard capability consists of three different states:
State 1: OFF
State 2: LEARNING
State 3: ACTIVE
The transition between these states can be triggered by manual
configuration or by meeting a pre-defined criteria.
3.1. RA-Guard state: OFF 3. Stateless RA-Guard
A device or interface in RA-Guard "OFF" state, operates as if the RA- Stateless RA-Guard examines incoming RAs and decide whether to
Guard capability is not available. forward or block them based solely on information found in the
message or in the L2-device configuration. Typical information
available in the frames received, useful for RA validation is:
3.2. RA-Guard state: LEARNING o Link-layer address of the sender
o Port on which the frame was received
o IP source address
o Prefix list
A device or interface in the RA-Guard "Learning" state is actively The following configuration information created on the L2-device can
acquiring information about the devices connected to its interfaces. be made available to RA-Guard, to validate against the information
The learning process takes place over a pre-defined period of time by found in the received RA frame:
capturing router advertisments or it can be event triggered. The
information gathered is compared against pre-defined criteria which
qualify the validity of the RAs.
In this state, the RA-Guard enabled device or interface is either o Allowed/Disallowed link-layer address of RA-sender
blocking all RAs until their validity is verified or, alternatively o Allowed/Disallowed ports for receiving RAs
it can temporarily forward the RAs until the decision is being made. o Allowed/Disallowed IP source addresses of RA-sender
o Allowed Prefix list and Prefix ranges
o Router Priority
3.3. RA-Guard state: ACTIVE Once the L2 device has validated the content of the RA frame against
the configuration, it forwards the RA to destination, whether unicast
or multicast. Otherwise, the RA is dropped.
A device or interface running RA-Guard and in Active state will block 4. Stateful RA-Guard
ingress RA-messages deemed invalid and will forward those deemed
valid based on a pre-defined criteria defined.
4. RA-Guard interface states 4.1. State Machine
The interfaces of devices with the RA-guard capability enabled can be Stateful RA-Guard learns dynamically about legitimate RA senders, and
in three possible states related to RA handling: Learning, Blocking store this information for allowing subsequent RAs. A simple
and Forwarding. stateful scheme would be for the L2-device to listen to RAs during a
certain period of time, then to allow subsequent RAs only on those
ports on which valid RAs were received during this period. A more
sophisticated stateful scheme is based on SeND, and is described in
Section 4.2.
4.1. RA-Blocking interface The state machine for stateful RA-Guard can be global, per-interface,
or per-peer, depending on the scheme used for authorizing RAs.
An interface in the RA Blocking state blocks all ingress RA messages When RA-Guard is SEND-based, the state machine is per-peer and
when RA-Guard capability is activated on a device. defined in [RFC3971].
4.2. RA-Forwarding interface When RA-Guard is using a discovery method, the state-machine of the
RA-Guard capability consists of four different states:
An interface in the RA Forwarding state forwards all ingress RA o State 1: OFF
messages deemed valid when RA-Guard capability is activated on a A device or interface in RA-Guard "OFF" state, operates as if
device. the RA-Guard capability is not available.
o State 2: LEARNING
A device or interface in the RA-Guard "Learning" state is
actively acquiring information about the devices connected to
its interfaces. The learning process takes place over a pre-
defined period of time by capturing router advertisements or it
can be event triggered. The information gathered is compared
against pre-defined criteria which qualify the validity of the
RAs.
4.3. RA-Learning interface In this state, the RA-Guard enabled device or interface is
either blocking all RAs until their validity is verified or,
alternatively it can temporarily forward the RAs until the
decision is being made.
o State 3: BLOCKING
A device or interface running RA-Guard and in Blocking state
will block ingress RA-messages.
o State 4: FORWARDING
A device or interface running RA-Guard and in Forwarding state
will accept ingress RAs and forward them to their destination/
An interface in a RA Learning state snoops all received RAs and The transition between these states can be triggered by manual
compares them against the criteria identifying valid RAs. While in configuration or by meeting a pre-defined criteria.
this state, the RAs can be blocked or forwarded until a decission is
taken regarding their validity.
4.4. RA-Guard interface state transition 4.2. SeND-based RA-Guard
In the simplest cases, an RA-Guard enabled interface can be manually In this scenario, the L2 device is blocking or forwarding RAs based
set in an RA-Blocking or RA-Forwarding state. By default, the on SeND considerations. Upon capturing an RA on the interface, the
interfaces of a legitimate node-in-the-middle could be set in RA- L2-device will first verify the CGA address and the RSA signature, as
Blocking mode and enabled for forwarding by the network specified in section 5 of [RFC3971]. RA should be dropped in case of
administrator. In the more general case, the interface acquires RA failure of this verification. It will then apply host behavior as
information during the RA Learning state and by using a pre-defined described in section 6.4.6 of [RFC3971]. In particular, the L2
validity criteria (see section 2) decides whether the analyzed RAs device will attempt to retrieve a valid certificate from its cache
should be forwarded or blocked. Based on this decission, the for the public key referred to in the RA. If such certificate is
interface transitions into the RA Blocking or the RA Forwarding found, the L2 device will forward the RA to destination. If not, the
state. L2 device will generate a CPS, sourced with UNSPECIFIED address, to
query the router certificate(s). It will then capture the CPA(s),
and attempt to validate the certificate chain. Failure to validate
the chain will result in dropping the RA. Upon validation success,
the L2 device will forward the RA to destination and and store the
router certificate in its cache.
Upon detecting new RAs, a port can transition back into an RA-Guard In order to operate in this scenario, the L2-device should be
Learning state. provisioned with a trust anchor certificate, as specified in section
6 of [RFC3971]. It may also establish a layer-3 connectivity with a
CRL server and/or with and NTP server. Bootstrapping issue in this
case can be resolved by using the configuration method to specify a
trusted port to a first router, and send-based-ra-guard method on all
other ports. The first router can then be used for NTP and CRL
connectivity.
5. RA-Guard Use Considerations 5. RA-Guard Use Considerations
The RA-Guard mechanism is effective only when all mesages between The RA-Guard mechanism is effective only when all messages between
IPv6 devices in the target environment traverse the controlled L2 IPv6 devices in the target environment traverse controlled L2
networking devices. When on a shared media such as an Ethernet hub, networking devices. In the case of environments such as Ethernet
devices can communicate directly without going through an RA-Guard hubs, devices can communicate directly without going through an RA-
capable L2 networking device. In this scenario, the RA- Guard Guard capable L2 networking device, the RA-Guard feature cannot
feature cannot protect against rogue-RAs. protect against rogue-RAs.
RA-Guard mecahnism does not protect against tunneled IPv6 traffic. RA-Guard mechanisms do not offer protection in environments where
IPv6 traffic is tunneled.
6. IANA Considerations 6. IANA Considerations
There are no extra IANA consideration for this document. There are no extra IANA consideration for this document.
7. Security Considerations 7. Security Considerations
There are no extra Security consideration for this document. There are no extra Security consideration for this document.
8. Acknowledgements 8. Acknowledgements
skipping to change at page 7, line 17 skipping to change at page 8, line 26
rogue RA nullifier (http://www.kame.net/dev/cvsweb2.cgi/ rogue RA nullifier (http://www.kame.net/dev/cvsweb2.cgi/
kame/kame/kame/rafixd/)", November 2007. kame/kame/kame/rafixd/)", November 2007.
[reference3] [reference3]
Hagino (itojun), Jun-ichiro., "Discussion of the various Hagino (itojun), Jun-ichiro., "Discussion of the various
solutions (http://ipv6samurais.com/ipv6samurais/ solutions (http://ipv6samurais.com/ipv6samurais/
demystified/rogue-RA.html)", 2007. demystified/rogue-RA.html)", 2007.
Authors' Addresses Authors' Addresses
Gunter Van de Velde
Cisco Systems
De Kleetlaan 6a
Diegem 1831
Belgium
Phone: +32 2704 5473
Email: gunter@cisco.com
Eric Levy Abegnoli Eric Levy Abegnoli
Cisco Systems Cisco Systems
Village d'Entreprises Green Side - 400, Avenue Roumanille Village d'Entreprises Green Side - 400, Avenue Roumanille
Biot - Sophia Antipolis, PROVENCE-ALPES-COTE D'AZUR 06410 Biot - Sophia Antipolis, PROVENCE-ALPES-COTE D'AZUR 06410
France France
Phone: +33 49 723 2620 Phone: +33 49 723 2620
Email: elevyabe@cisco.com Email: elevyabe@cisco.com
Gunter Van de Velde
Cisco Systems
De Kleetlaan 6a
Diegem 1831
Belgium
Phone: +32 2704 5473
Email: gunter@cisco.com
Ciprian Popoviciu Ciprian Popoviciu
Cisco Systems Cisco Systems
7025-6 Kit Creek Road 7025-6 Kit Creek Road
Research Triangle Park, North Carolina NC 27709-4987 Research Triangle Park, North Carolina NC 27709-4987
USA USA
Phone: +1 919 392-3723 Phone: +1 919 392-3723
Email: cpopovic@cisco.com Email: cpopovic@cisco.com
Janos Mohacsi Janos Mohacsi
NIIF/Hungarnet NIIF/Hungarnet
18-22 Victor Hugo 18-22 Victor Hugo
Budapest H-1132 Budapest H-1132
Hungary Hungary
Phone: tbc Phone: tbc
Email: mohacsi@niif.hu Email: mohacsi@niif.hu
Full Copyright Statement Full Copyright Statement
 End of changes. 41 change blocks. 
138 lines changed or deleted 184 lines changed or added

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