draft-ietf-v6ops-ra-guard-08.txt | rfc6105.txt | |||
---|---|---|---|---|
v6ops Working Group E. Levy-Abegnoli | Internet Engineering Task Force (IETF) E. Levy-Abegnoli | |||
Internet-Draft G. Van de Velde | Request for Comments: 6105 G. Van de Velde | |||
Intended status: Informational C. Popoviciu | Category: Informational Cisco Systems | |||
Expires: March 6, 2011 Cisco Systems | ISSN: 2070-1721 C. Popoviciu | |||
Technodyne | ||||
J. Mohacsi | J. Mohacsi | |||
NIIF/Hungarnet | NIIF/Hungarnet | |||
September 02, 2010 | February 2011 | |||
IPv6 Router Advertisement Guard | IPv6 Router Advertisement Guard | |||
<draft-ietf-v6ops-ra-guard-08.txt> | ||||
Abstract | Abstract | |||
Routed protocols are often susceptible to spoof attacks. The | Routed protocols are often susceptible to spoof attacks. The | |||
canonical solution for IPv6 is Secure Neighbor Discovery (SEND), a | canonical solution for IPv6 is Secure Neighbor Discovery (SEND), a | |||
solution that is non-trivial to deploy. This document proposes a | solution that is non-trivial to deploy. This document proposes a | |||
light-weight alternative and complement to SEND based on filtering in | light-weight alternative and complement to SEND based on filtering in | |||
the layer-2 network fabric, using a variety of filtering criteria, | the layer-2 network fabric, using a variety of filtering criteria, | |||
including, for example, SEND status. | including, for example, SEND status. | |||
Status of this Memo | 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 | This document is not an Internet Standards Track specification; it is | |||
Task Force (IETF). Note that other groups may also distribute | published for informational purposes. | |||
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 | This document is a product of the Internet Engineering Task Force | |||
and may be updated, replaced, or obsoleted by other documents at any | (IETF). It represents the consensus of the IETF community. It has | |||
time. It is inappropriate to use Internet-Drafts as reference | received public review and has been approved for publication by the | |||
material or to cite them other than as "work in progress." | Internet Engineering Steering Group (IESG). Not all documents | |||
approved by the IESG are a candidate for any level of Internet | ||||
Standard; see Section 2 of RFC 5741. | ||||
This Internet-Draft will expire on March 6, 2011. | Information about the current status of this document, any errata, | |||
and how to provide feedback on it may be obtained at | ||||
http://www.rfc-editor.org/info/rfc6105. | ||||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2010 IETF Trust and the persons identified as the | Copyright (c) 2011 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 | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
skipping to change at page 3, line 7 | skipping to change at page 2, line 34 | |||
modifications of such material outside the IETF Standards Process. | modifications of such material outside the IETF Standards Process. | |||
Without obtaining an adequate license from the person(s) controlling | Without obtaining an adequate license from the person(s) controlling | |||
the copyright in such materials, this document may not be modified | the copyright in such materials, this document may not be modified | |||
outside the IETF Standards Process, and derivative works of it may | outside the IETF Standards Process, and derivative works of it may | |||
not be created outside the IETF Standards Process, except to format | not be created outside the IETF Standards Process, except to format | |||
it for publication as an RFC or to translate it into languages other | it for publication as an RFC or to translate it into languages other | |||
than English. | than English. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1. Introduction ....................................................3 | |||
2. Model and Applicability . . . . . . . . . . . . . . . . . . . 4 | 2. Model and Applicability .........................................3 | |||
3. Stateless RA-Guard . . . . . . . . . . . . . . . . . . . . . . 6 | 3. Stateless RA-Guard ..............................................5 | |||
4. Stateful RA-Guard . . . . . . . . . . . . . . . . . . . . . . 6 | 4. Stateful RA-Guard ...............................................6 | |||
4.1. State Machine . . . . . . . . . . . . . . . . . . . . . . 7 | 4.1. State Machine ..............................................6 | |||
4.2. SEND-based RA-Guard . . . . . . . . . . . . . . . . . . . 8 | 4.2. SEND-Based RA-Guard ........................................8 | |||
5. RA-Guard Use Considerations . . . . . . . . . . . . . . . . . 9 | 5. RA-Guard Use Considerations .....................................8 | |||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 | 6. Security Considerations .........................................9 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | 7. Acknowledgements ................................................9 | |||
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 | 8. References ......................................................9 | |||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 | 8.1. Normative References .......................................9 | |||
9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 | 8.2. Informative References .....................................9 | |||
9.2. Informative References . . . . . . . . . . . . . . . . . . 10 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 | ||||
1. Introduction | 1. Introduction | |||
When operating IPv6 in a shared L2 network segment without complete | When operating IPv6 in a shared layer-2 (L2) network segment without | |||
SEND support by all devices connected or without the availability of | complete SEcure Neighbor Discovery (SEND) support by all devices | |||
the infrastructure necessary to support Secure Neighbor Discovery | connected or without the availability of the infrastructure necessary | |||
(SEND) [RFC3971], there is always the risk of facing operational | to support SEND [RFC3971], there is always the risk of facing | |||
problems due to rogue Router Advertisements generated maliciously or | operational problems due to rogue Router Advertisements (RAs) | |||
unintentionally by unauthorized or improperly configured routers | generated maliciously or unintentionally by unauthorized or | |||
connecting to the segment. | improperly configured routers connecting to the segment. | |||
There are several examples of work done on this topic which resulted | There are several examples of work done on this topic that resulted | |||
in several related studies [reference1] [reference2] | in related studies and code, including [NDPMON] [KAME] | |||
[reference3].This document describes a solution framework for the | [IPv6-SAMURAIS]. This document describes a solution framework for | |||
rogue-RA problem where network segments are designed around a single | the rogue-RA problem [RFC6104] where network segments are designed | |||
or a set of L2-switching devices capable of identifying invalid RAs | around a single L2-switching device or a set of L2-switching devices | |||
and blocking them. The solutions developed within this framework can | capable of identifying invalid RAs and blocking them. The solutions | |||
span the spectrum from basic (where the port of the L2 device is | developed within this framework can span the spectrum from basic | |||
statically instructed to forward or not to forward RAs received from | (where the port of the L2 device is statically instructed to forward | |||
the connected device) to advanced (where a criteria is used by the L2 | or not to forward RAs received from the connected device) to advanced | |||
device to dynamically validate or invalidate a received RA, this | (where a criterion is used by the L2 device to dynamically validate | |||
criteria can even be based on SEND mechanisms). | or invalidate a received RA, this criterion can even be based on SEND | |||
mechanisms). | ||||
2. Model and Applicability | 2. Model and Applicability | |||
RA-Guard applies to an environment where all messages between IPv6 | RA-Guard applies to an environment where all messages between IPv6 | |||
end-devices traverse the controlled L2 networking devices. It does | end-devices traverse the controlled L2 networking devices. It does | |||
not apply to a shared media, when devices can communicate directly | not apply to shared media, when devices can communicate directly | |||
without going through an RA-Guard capable L2 networking device. | without going through an RA-Guard-capable L2 networking device. | |||
Figure 1 illustrates a deployment scenario for RA-Guard. | Figure 1 illustrates a deployment scenario for RA-Guard. | |||
Block Allow | Block Allow | |||
+------+ incoming +---------+ incoming +--------+ | +------+ incoming +---------+ incoming +--------+ | |||
|Host | RA | L2 | RA | Router | | |Host | RA | L2 | RA | Router | | |||
| |----------------| device |--------------| | | | |----------------| device |--------------| | | |||
+------+ +----+----+ +--------+ | +------+ +----+----+ +--------+ | |||
| | | | |||
|Block | |Block | |||
|incoming | |incoming | |||
|RA | |RA | |||
| | | | |||
| | | | |||
| | | | |||
+---+---+ | +---+---+ | |||
| Host | | | Host | | |||
| | | | | | |||
+-------+ | +-------+ | |||
Figure 1 | Figure 1 | |||
RA-Guard does not intend to provide a substitute for SEND based | 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 until 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 | |||
It is also reasonable to expect that some devices might not consider | anchors. It is also reasonable to expect that some devices, such as | |||
implementing SEND at all such as IPv6 enabled sensors. An RA-Guard | IPv6-enabled sensors, might not consider implementing SEND at all. | |||
implementation which SEND-validates RAs on behalf of hosts would | An RA-Guard implementation that SEND-validates RAs on behalf of hosts | |||
potentially simplify some of these challenges. | would 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 Advertisements based | authorization. Its purpose is to filter Router Advertisements based | |||
on a set of criteria, from a simplistic "RA disallowed on a given | on a set of criteria, 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 a full- | |||
fledge SEND "RA allowed from authorized sources only". | fledged 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 Advertisements, 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 analyzing 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 | SEND is enabled, the RA is checked against X.509 certificates | |||
[RFC4861]. If any other criteria is in use, such as known L3 | ||||
[RFC4861]. If any other criterion is in use, such as known L3 | ||||
(addresses) or L2 (link-layer address, port number) legitimate | (addresses) or L2 (link-layer address, port number) legitimate | |||
sources of RAs, the node-in-the middle can use this criteria and | sources of RAs, the node-in-the middle can use this criterion and | |||
filter out any RA that does not comply. If this node-in-the-middle | filter out any RA that does not comply. If this node-in-the-middle | |||
is a L2 device, it will not change the content of the validated RA, | is an L2 device, it will not change the content of the validated RA | |||
and avoid any of the ND-proxy pitfalls. | and will avoid any of the ND-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 an | in contexts where simplicity is required while leveraging SEND in a | |||
context environment consisting of with a mix of SEND capable devices | context environment consisting of a mix of SEND-capable devices (L2 | |||
(L2 switches and routers) and devices that do not consistently use | switches and routers) and devices that do not consistently use SEND. | |||
SEND. Furthermore, RA-Guard is useful to simplify SEND deployments, | Furthermore, RA-Guard is useful to simplify SEND deployments, as only | |||
as only the L2 switch and the routers are required to carry | the L2 switch and the routers are required to carry certificates | |||
certificates (their own and the trust anchor certificates). | (their own and the trust anchor certificates). | |||
3. Stateless RA-Guard | 3. Stateless RA-Guard | |||
Stateless RA-Guard examines incoming RAs and decide whether to | Stateless RA-Guard examines incoming RAs and decides whether to | |||
forward or block them based solely on information found in the | forward or block them based solely on information found in the | |||
message or in the L2-device configuration. Typical information | message or in the L2-device configuration. Typical information | |||
available in the frames received, useful for RA validation is: | available in the frames received, useful for RA validation, is as | |||
follows: | ||||
o Link-layer address of the sender | o Link-layer address of the sender | |||
o Port on which the frame was received | o Port on which the frame was received | |||
o IP source address | o IP source address | |||
o Prefix list | o Prefix list | |||
The following configuration information created on the L2-device can | The following configuration information created on the L2 device can | |||
be made available to RA-Guard, to validate against the information | be made available to RA-Guard, to validate against the information | |||
found in the received RA frame: | found in the received RA frame: | |||
o Allowed/Disallowed link-layer address of RA-sender | o Allowed/Disallowed link-layer address of the RA sender | |||
o Allowed/Disallowed ports for receiving RAs | o Allowed/Disallowed ports for receiving RAs | |||
o Allowed/Disallowed IP source addresses of RA-sender | ||||
o Allowed/Disallowed IP source addresses of the RA sender | ||||
o Allowed Prefix list and Prefix ranges | o Allowed Prefix list and Prefix ranges | |||
o Router Priority | o Router Priority | |||
Once the L2 device has validated the content of the RA frame against | Once the L2 device has validated the content of the RA frame against | |||
the configuration, it forwards the RA to destination, whether unicast | the configuration, it forwards the RA to its destination, whether | |||
or multicast. Otherwise, the RA is dropped. | unicast or multicast. Otherwise, the RA is dropped. | |||
An example of a very simple stateless RA-Guard implementation could | An example of a very simple stateless RA-Guard implementation could | |||
be a small L2-switch for which there is one interface "statically- | be a small L2 switch for which there is one interface "statically | |||
configured" as the interface connecting to a router, while all other | configured" as the interface connecting to a router, while all other | |||
interfaces are for non-router devices. With his small static setup | interfaces are for non-router devices. With this small static setup, | |||
the only interface forwarding RAs will be the pre-assigned router | the only interface forwarding RAs will be the pre-assigned router | |||
interface, while the non-router interfaces block all RAs. | interface, while the non-router interfaces block all RAs. | |||
4. Stateful RA-Guard | 4. Stateful RA-Guard | |||
4.1. State Machine | 4.1. State Machine | |||
Stateful RA-Guard learns dynamically about legitimate RA senders, and | Stateful RA-Guard learns dynamically about legitimate RA senders and | |||
store this information for allowing subsequent RAs. A simple | stores this information for allowing subsequent RAs. A simple | |||
stateful scheme would be for the L2-device to listen to RAs during a | stateful scheme would be for the L2 device to listen to RAs during a | |||
certain manual determined period of time, where the start of the | certain manually configured period of time, where the start of the | |||
listening-period and the duration of the listening-period for a | listening period and the duration of the listening period for a | |||
single instance is controled by the manual intervention. As result | single instance are controlled by the manual intervention. As a | |||
the L2-device can then allow subsequent RAs only on those ports on | result, the L2 device can then allow subsequent RAs only on those | |||
which valid RAs were received during this period. Often the LEARNING | ports on which valid RAs were received during this period. Often, | |||
state will only be activated by manual configuration when a new IPv6 | the "LEARNING" state will only be activated by manual configuration | |||
router is provisioned on the L2-network. | when a new IPv6 router is provisioned on the L2 network. | |||
A more sophisticated stateful scheme is based on SEND, and is | A more sophisticated stateful scheme is based on SEND and is | |||
described in Section 4.2. | described in Section 4.2. | |||
The state machine for stateful RA-Guard can be global, per-interface, | The state machine for stateful RA-Guard can be global, per-interface, | |||
or per-peer, depending on the scheme used for authorizing RAs. | or per-peer, depending on the scheme used for authorizing RAs. | |||
When RA-Guard is SEND-based, the state machine is per-peer and | When RA-Guard is SEND-based, the state machine is per-peer and | |||
defined in [RFC3971]. | defined in [RFC3971]. | |||
When RA-Guard is using a discovery method, the state-machine of the | When RA-Guard is using a discovery method, the state machine of the | |||
RA-Guard capability consists of four different states: | RA-Guard capability consists of four different states: | |||
o State 1: OFF | o State 1: OFF | |||
A device or interface in RA-Guard "OFF" state, operates as if | ||||
the RA-Guard capability is not available. | A device or interface in the RA-Guard "OFF" state operates as if | |||
the RA-Guard capability is not available. | ||||
o State 2: LEARNING | o State 2: LEARNING | |||
A device or interface in the RA-Guard "Learning" state is | ||||
actively acquiring information about the IPv6 routing devices | A device or interface in the RA-Guard "LEARNING" state is actively | |||
connected. The learning process takes place over a pre-defined | acquiring information about the IPv6 routing devices connected to | |||
unique period in time, set by manual configuration or it can be | its interfaces. The learning process takes place over a | |||
event triggered. The information gathered is compared against | pre-defined unique period of time, as set by manual configuration; | |||
pre-defined criteria; criteria similar as the stateless RA- | or it can be event-triggered. The information gathered is | |||
Guard rules to qualify the validity of the RAs. | compared against pre-defined criteria (criteria similar to the | |||
In this state, the RA-Guard enabled device or interface is | stateless RA-Guard rules) to qualify the validity of the RAs. | |||
either blocking "all" RAs until their validity is verified or, | ||||
alternatively it can temporarily forward "all" the RAs until | In this state, the RA-Guard-enabled device or interface is either | |||
their validity is verified. | blocking "all" RAs until their validity is verified or, | |||
Once the L2-device has identified through "Learning" the valid | alternatively, it can temporarily forward "all" of the RAs until | |||
IPv6 routers and hence also identified the valid RAs, it | their validity is verified. | |||
transtions each interface from "LEARNING" into either BLOCKING | ||||
state if there was no valid IPv6 router discovered at the | When the L2 device reaches the end of the LEARNING state, it has a | |||
interface, or transitions the interface into FORWARDING state | record of which interfaces are attached to links with valid IPv6 | |||
if there was a valid IPv6 router discovered. | routers. The L2 device transitions each interface from the | |||
LEARNING state into either the BLOCKING state if there was no | ||||
valid IPv6 router discovered at the interface, or into the | ||||
FORWARDING state if there was a valid IPv6 router discovered. | ||||
o State 3: BLOCKING | o State 3: BLOCKING | |||
A device or interface running RA-Guard and in Blocking state | ||||
will block ingress RA-messages. | A device or interface running RA-Guard and in the BLOCKING state | |||
An interface can transition from BLOCKING state into FORWARDING | will block ingress RA messages. | |||
state directly if explicitly instructed by the L2-device | ||||
operator. | An interface can transition from the BLOCKING state into the | |||
An interface can transition from BLOCKING state into LEARNING | FORWARDING state directly if explicitly instructed by the | |||
state if either explicitly told by the L2-device operator or by | L2-device operator. | |||
a triggered event. | ||||
An interface can transition from the BLOCKING state into the | ||||
LEARNING state if either explicitly instructed by the L2-device | ||||
operator or prompted by a triggered event. | ||||
o State 4: FORWARDING | o State 4: FORWARDING | |||
A device or interface running RA-Guard and in Forwarding state | ||||
will accept valid ingress RAs and forward them to their | A device or interface running RA-Guard and in the FORWARDING state | |||
destination. | will accept valid ingress RAs and forward them to their | |||
An interface can transition from FORWARDING state into BLOCKING | destination. | |||
state directly if explicitly instructed by the L2-device | ||||
operator. | An interface can transition from the FORWARDING state into the | |||
An interface can transition from FORWARDING state into LEARNING | BLOCKING state directly if explicitly instructed by the L2-device | |||
state if either explicitly told by the L2-device operator or by | operator. | |||
a triggered event. | ||||
An interface can transition from the FORWARDING state into the | ||||
LEARNING state if either explicitly instructed by the L2-device | ||||
operator or prompted by a triggered event. | ||||
The transition between these states can be triggered by manual | The transition between these states can be triggered by manual | |||
configuration or by meeting a pre-defined criteria. | configuration or by meeting a pre-defined criterion. | |||
4.2. SEND-based RA-Guard | 4.2. SEND-Based RA-Guard | |||
In this scenario, the L2 device is blocking or forwarding RAs based | In this scenario, the L2 device is blocking or forwarding RAs based | |||
on SEND considerations. Upon capturing an RA on the interface, the | on SEND considerations. Upon capturing an RA on the interface, the | |||
L2-device will first verify the Cryptographically Generated Addresses | L2 device will first verify the Cryptographically Generated Address | |||
(CGA) [RFC3971] address and the RSA (Rivest, Shamir and Adleman | (CGA) [RFC3971] and the RSA (Rivest, Shamir, and Adleman algorithm | |||
algorithm for public-key cryptography) signature, as specified in | for public-key cryptography) signature, as specified in Section 5 of | |||
section 5 of [RFC3971]. RA should be dropped in case of failure of | [RFC3971]. The RA should be dropped in case of failure of this | |||
this verification. It will then apply host behavior as described in | verification. It will then apply host behavior as described in | |||
section 6.4.6 of [RFC3971]. In particular, the L2 device will | Section 6.4.6 of [RFC3971]. In particular, the L2 device will | |||
attempt to retrieve a valid certificate from its cache for the public | attempt to retrieve a valid certificate from its cache for the public | |||
key referred to in the RA. If such certificate is found, the L2 | key referred to in the RA. If such a certificate is found, the L2 | |||
device will forward the RA to destination. If not, the L2 device | device will forward the RA to its destination. If not, the L2 device | |||
will generate a Certification Path Solicitation (CPS) [RFC3971], | will generate a Certification Path Solicitation (CPS) [RFC3971] with | |||
sourced with UNSPECIFIED address, to query the router certificate(s). | an unspecified source address, to query the router certificate(s). | |||
It will then capture the Certification Path Advertisements (CPA) | It will then capture the Certification Path Advertisement (CPA) | |||
[RFC3971], and attempt to validate the certificate chain. Failure to | [RFC3971] and attempt to validate the certificate chain. Failure to | |||
validate the chain will result in dropping the RA. Upon validation | validate the chain will result in dropping the RA. Upon validation | |||
success, the L2 device will forward the RA to destination and and | success, the L2 device will forward the RA to its destination and | |||
store the router certificate in its cache. | store the router certificate in its cache. | |||
In order to operate in this scenario, the L2-device should be | In order to operate in this scenario, the L2 device should be | |||
provisioned with a trust anchor certificate, as specified in section | provisioned with a trust anchor certificate, as specified in | |||
6 of [RFC3971]. It may also establish a layer-3 connectivity with a | Section 6 of [RFC3971]. It may also establish layer-3 connectivity | |||
Certificate Revocation List (CRL) Certification Path Advertisement | with a Certificate Revocation List (CRL) Certification Path | |||
server and/or with and NTP server. Bootstrapping issue in this case | Advertisement server and/or with an NTP server. A bootstrapping | |||
can be resolved by using the configuration method to specify a | issue in this case can be resolved by using the configuration method | |||
trusted port to a first router, and SEND-based RA-Guard method on all | to specify a trusted port to a first router, and the SEND-based | |||
other ports. The first router can then be used for Network Time | RA-Guard method on all other ports. The first router can then be | |||
Protocol (NTP) [RFC5905] and CRL connectivity. | used for Network Time Protocol (NTP) [RFC5905] and CRL connectivity. | |||
5. RA-Guard Use Considerations | 5. RA-Guard Use Considerations | |||
The RA-Guard mechanism is effective only when all messages between | The RA-Guard mechanism is effective only when all messages between | |||
IPv6 devices in the target environment traverse controlled L2 | IPv6 devices in the target environment traverse controlled L2 | |||
networking devices. In the case of environments such as Ethernet | networking devices. In the case of environments such as Ethernet | |||
hubs, devices can communicate directly without going through an RA- | hubs, devices can communicate directly without going through an | |||
Guard capable L2 networking device, the RA-Guard feature cannot | RA-Guard-capable L2 networking device, and the RA-Guard feature | |||
protect against rogue-RAs. | cannot protect against rogue RAs. | |||
RA-Guard mechanisms do not offer protection in environments where | RA-Guard mechanisms do not offer protection in environments where | |||
IPv6 traffic is tunneled. | IPv6 traffic is tunneled. | |||
6. IANA Considerations | 6. Security Considerations | |||
There are no extra IANA consideration for this document. | ||||
7. Security Considerations | ||||
Once RA-Guard has setup the proper criteria, for example, it | Once RA-Guard has set up the proper criteria (for example, it | |||
identified that a port is allowed to receive RAs, or it identified | specified that a port is allowed to receive RAs, or it identified | |||
legitimate sources of RA, or certificate base [RFC4861], then there | legitimate sources of RAs or certificate bases [RFC4861]), then there | |||
is no possible instances of accidently filtered legitimate Router | are no possible instances of accidentally filtered legitimate Router | |||
advertisements assuming the RA-Guard filter enforcement follows | Advertisements, assuming the RA-Guard filter enforcement strictly | |||
strictly the RA-Guard set criteria. | follows the RA-Guard set criteria. | |||
in Section 4.1 a simple mechanism to learn dynamical the valid IPv6 | In Section 4.1, a simple mechanism to dynamically learn the valid | |||
routers connected to a L2-device is explained. It is important that | IPv6 routers connected to an L2 device is explained. It is important | |||
this LEARN state is only entered intentionally by manual | that this LEARNING state is only entered intentionally by manual | |||
configuration. The list of learned IPv6 routers should be verified | configuration. The list of learned IPv6 routers should be verified | |||
by the network manager to make sure that it corresponds with the | by the network manager to make sure that it corresponds with the | |||
expected valid RA list. This procedure will make sure that either | expected valid RA list. This procedure will make sure that either | |||
accidently or intentionally rogue RAs are blocked by RA-guard. | accidentally or intentionally generated rogue RAs are blocked by | |||
RA-Guard. | ||||
8. Acknowledgements | 7. Acknowledgements | |||
The authors dedicate this document to the memory of Jun-ichiro Hagino | The authors dedicate this document to the memory of Jun-ichiro Hagino | |||
(itojun) for his contributions to the development and deployment of | (itojun) for his contributions to the development and deployment of | |||
IPv6. | IPv6. | |||
9. References | 8. References | |||
9.1. Normative References | ||||
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure | 8.1. Normative References | |||
Neighbor Discovery (SEND)", RFC 3971, March 2005. | ||||
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, | [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, | |||
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, | "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. | |||
September 2007. | ||||
[RFC4158] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R. | [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, | |||
Nicholas, "Internet X.509 Public Key Infrastructure: | "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, | |||
Certification Path Building", RFC 4158, September 2005. | September 2007. | |||
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network | [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, | |||
Time Protocol Version 4: Protocol and Algorithms | "Network Time Protocol Version 4: Protocol and Algorithms | |||
Specification", RFC 5905, June 2010. | Specification", RFC 5905, June 2010. | |||
9.2. Informative References | 8.2. Informative References | |||
[reference1] | [NDPMON] LORIA/INRIA, "NDPMon - IPv6 Neighbor Discovery Protocol | |||
LORIA/INRIA, "NDPMon - IPv6 Neighbor Discovery Protocol | Monitor", November 2007, | |||
Monitor (http://ndpmon.sourceforge.net/)", November 2007. | <http://ndpmon.sourceforge.net/>. | |||
[reference2] | [KAME] KAME Project, "rafixd - developed at KAME - An active | |||
KAME Project, "rafixd - developed at KAME - An active | rogue RA nullifier", November 2007, | |||
rogue RA nullifier (http://www.kame.net/dev/cvsweb2.cgi/ | <http://www.kame.net/>. | |||
kame/kame/kame/rafixd/)", November 2007. | ||||
[reference3] | [IPv6-SAMURAIS] | |||
Hagino (itojun), Jun-ichiro., "Discussion of the various | Hagino (itojun), J., "IPv6 demystified: I have a problem | |||
solutions (http://ipv6samurais.com/ipv6samurais/ | with rogue RAs in my IPv6 network", 2007, | |||
demystified/rogue-RA.html)", 2007. | <http://ipv6samurais.com/>. | |||
[reference4] | [RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement | |||
Chown, Tim. and Stig. Venaas, "Rogue IPv6 Router | Problem Statement", RFC 6104, February 2011. | |||
Advertisement Problem (draft-ietf-v6ops-rogue-ra-00.txt)", | ||||
May 2009. | ||||
Authors' Addresses | Authors' Addresses | |||
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 | Gunter Van de Velde | |||
Cisco Systems | Cisco Systems | |||
De Kleetlaan 6a | De Kleetlaan 6a | |||
Diegem 1831 | Diegem 1831 | |||
Belgium | Belgium | |||
Phone: +32 2704 5473 | Phone: +32 2704 5473 | |||
Email: gunter@cisco.com | EMail: gunter@cisco.com | |||
Ciprian Popoviciu | Ciprian Popoviciu | |||
Cisco Systems | Technodyne | |||
7025-6 Kit Creek Road | 111 Wood Ave. S. | |||
Research Triangle Park, North Carolina NC 27709-4987 | Iselin, NJ 08830 | |||
USA | USA | |||
Phone: +1 919 392-3723 | Phone: +1 1 919 599-5666 | |||
Email: cpopovic@cisco.com | EMail: chip@technodyne.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 | EMail: mohacsi@niif.hu | |||
Email: mohacsi@niif.hu | ||||
End of changes. 70 change blocks. | ||||
229 lines changed or deleted | 239 lines changed or added | |||
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |