Internet Engineering Task Force (IETF) E. Levy-Abegnoli Request for Comments: 6105 G. Van de Velde Category: Informational Cisco Systems ISSN: 2070-1721 C. Popoviciu Technodyne J. Mohacsi NIIF/Hungarnet February 2011 IPv6 Router Advertisement Guard
AbstractRouted protocols are often susceptible to spoof attacks. The canonical solution for IPv6 is Secure Neighbor Discovery (SEND), a solution that is non-trivial to deploy. This document proposes a light-weight alternative and complement to SEND based on filtering in the layer-2 network fabric, using a variety of filtering criteria, including, for example, SEND status. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the 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. 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 (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 1. Introduction ....................................................3 2. Model and Applicability .........................................3 3. Stateless RA-Guard ..............................................5 4. Stateful RA-Guard ...............................................6 4.1. State Machine ..............................................6 4.2. SEND-Based RA-Guard ........................................8 5. RA-Guard Use Considerations .....................................8 6. Security Considerations .........................................9 7. Acknowledgements ................................................9 8. References ......................................................9 8.1. Normative References .......................................9 8.2. Informative References .....................................9
RFC3971], there is always the risk of facing operational problems due to rogue Router Advertisements (RAs) generated maliciously or unintentionally by unauthorized or improperly configured routers connecting to the segment. There are several examples of work done on this topic that resulted in related studies and code, including [NDPMON] [KAME] [IPv6-SAMURAIS]. This document describes a solution framework for the rogue-RA problem [RFC6104] where network segments are designed around a single L2-switching device or a set of L2-switching devices capable of identifying invalid RAs and blocking them. The solutions developed within this framework can span the spectrum from basic (where the port of the L2 device is statically instructed to forward or not to forward RAs received from the connected device) to advanced (where a criterion is used by the L2 device to dynamically validate or invalidate a received RA, this criterion can even be based on SEND mechanisms). Figure 1 illustrates a deployment scenario for RA-Guard.
Block Allow +------+ incoming +---------+ incoming +--------+ |Host | RA | L2 | RA | Router | | |----------------| device |--------------| | +------+ +----+----+ +--------+ | |Block |incoming |RA | | | +---+---+ | Host | | | +-------+ Figure 1 RA-Guard does not intend to provide a substitute for SEND-based solutions. It actually intends to provide complementary solutions in those environments where SEND might not be suitable or fully supported by all devices involved. It may take time until SEND is ubiquitous in IPv6 networks and some of its large-scale deployment aspects are sorted out, such as provisioning hosts with trust anchors. It is also reasonable to expect that some devices, such as IPv6-enabled sensors, might not consider implementing SEND at all. An RA-Guard implementation that SEND-validates RAs on behalf of hosts would potentially simplify some of these challenges. RA-Guard can be seen as a superset of SEND with regard to router authorization. Its purpose is to filter Router Advertisements based on a set of criteria, from a simplistic "RA disallowed on a given interface" to "RA allowed from pre-defined sources" and up to a full- fledged SEND "RA allowed from authorized sources only". In addition to this granularity on the criteria for filtering out Router Advertisements, RA-Guard introduces the concept of router authorization proxy. Instead of each node on the link analyzing RAs and making an individual decision, a legitimate "node-in-the-middle" 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 SEND is enabled, the RA is checked against X.509 certificates
[RFC4861]. If any other criterion is in use, such as known L3 (addresses) or L2 (link-layer address, port number) legitimate 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 is an L2 device, it will not change the content of the validated RA and will avoid any of the ND-proxy pitfalls. RA-Guard intends to provide simple solutions to the rogue-RA problem in contexts where simplicity is required while leveraging SEND in a context environment consisting of a mix of SEND-capable devices (L2 switches and routers) and devices that do not consistently use SEND. Furthermore, RA-Guard is useful to simplify SEND deployments, as only the L2 switch and the routers are required to carry certificates (their own and the trust anchor certificates).
An example of a very simple stateless RA-Guard implementation could be a small L2 switch for which there is one interface "statically configured" as the interface connecting to a router, while all other interfaces are for non-router devices. With this small static setup, the only interface forwarding RAs will be the pre-assigned router interface, while the non-router interfaces block all RAs. Section 4.2. The state machine for stateful RA-Guard can be global, per-interface, or per-peer, depending on the scheme used for authorizing RAs. When RA-Guard is SEND-based, the state machine is per-peer and defined in [RFC3971]. When RA-Guard is using a discovery method, the state machine of the RA-Guard capability consists of four different states: o State 1: OFF A device or interface in the RA-Guard "OFF" state operates as if 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 IPv6 routing devices connected to its interfaces. The learning process takes place over a pre-defined unique period of time, as set by manual configuration;
or it can be event-triggered. The information gathered is compared against pre-defined criteria (criteria similar to the stateless RA-Guard rules) to qualify the validity of the RAs. 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 "all" of the RAs until their validity is verified. When the L2 device reaches the end of the LEARNING state, it has a record of which interfaces are attached to links with valid IPv6 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 A device or interface running RA-Guard and in the BLOCKING state will block ingress RA messages. An interface can transition from the BLOCKING state into the FORWARDING state directly if explicitly instructed by the L2-device operator. 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 A device or interface running RA-Guard and in the FORWARDING state will accept valid ingress RAs and forward them to their destination. An interface can transition from the FORWARDING state into the BLOCKING state directly if explicitly instructed by the L2-device operator. 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 configuration or by meeting a pre-defined criterion.
RFC3971] and the RSA (Rivest, Shamir, and Adleman algorithm for public-key cryptography) signature, as specified in Section 5 of [RFC3971]. The RA should be dropped in case of failure of this verification. It will then apply host behavior as described in Section 6.4.6 of [RFC3971]. In particular, the L2 device will attempt to retrieve a valid certificate from its cache for the public key referred to in the RA. If such a certificate is found, the L2 device will forward the RA to its destination. If not, the L2 device will generate a Certification Path Solicitation (CPS) [RFC3971] with an unspecified source address, to query the router certificate(s). It will then capture the Certification Path Advertisement (CPA) [RFC3971] 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 its destination and store the router certificate in its cache. In order to operate in this scenario, the L2 device should be provisioned with a trust anchor certificate, as specified in Section 6 of [RFC3971]. It may also establish layer-3 connectivity with a Certificate Revocation List (CRL) Certification Path Advertisement server and/or with an NTP server. A bootstrapping issue in this case can be resolved by using the configuration method to specify a trusted port to a first router, and the SEND-based RA-Guard method on all other ports. The first router can then be used for Network Time Protocol (NTP) [RFC5905] and CRL connectivity.
RFC4861]), then there are no possible instances of accidentally filtered legitimate Router Advertisements, assuming the RA-Guard filter enforcement strictly follows the RA-Guard set criteria. In Section 4.1, a simple mechanism to dynamically learn the valid IPv6 routers connected to an L2 device is explained. It is important that this LEARNING state is only entered intentionally by manual configuration. The list of learned IPv6 routers should be verified by the network manager to make sure that it corresponds with the expected valid RA list. This procedure will make sure that either accidentally or intentionally generated rogue RAs are blocked by RA-Guard. [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010. [NDPMON] LORIA/INRIA, "NDPMon - IPv6 Neighbor Discovery Protocol Monitor", November 2007, <http://ndpmon.sourceforge.net/>. [KAME] KAME Project, "rafixd - developed at KAME - An active rogue RA nullifier", November 2007, <http://www.kame.net/>.
[IPv6-SAMURAIS] Hagino (itojun), J., "IPv6 demystified: I have a problem with rogue RAs in my IPv6 network", 2007, <http://ipv6samurais.com/>. [RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement Problem Statement", RFC 6104, February 2011.