v6ops Working Group E. Levy-Abegnoli Internet-Draft G. Van de Velde
Internet-Draft E. Levy-AbegnoliExpires: January 2,March 14, 2009 C. Popoviciu Cisco Systems J. Mohacsi NIIF/Hungarnet July 1,September 10, 2008 IPv6 RA-Guard <draft-ietf-v6ops-ra-guard-00.txt><draft-ietf-v6ops-ra-guard-01.txt> Status of this Memo By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at 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 January 2,March 14, 2009. Abstract It is particularly easy to experience "rogue" routers on an unsecured link. Devices acting as a rougue router may send illegitimate RAs. Section 6 of SeND [RFC3971] provides a full solution to this problem, by enabling routers certification. This solution does, however, require all nodes on an L2 network segment to support SeND, as well as it carries some deployment challenges. End-nodes must be provisioned with certificate anchors. The solution works better when 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. When using IPv6 within a single L2 network segment it is neccesary to ensure that all routers advertising their services within it are valid. In cases where it is not convinient orpossible and sometimes desirable to use SeND [RFC3971] a rogue Router Advertisement (RA) [RFC4861] could be sent by accident dueenable layer 2 devices to misconfiguraton or ill intended. Simple solutions for protecting againstdrop rogue RAs are beneficial in complementing SeND in securingbefore they reach end-nodes. In order to distinguish valid from rogue RAs, the L2 domain for ceratin types ofdevices can use a spectrum of criterias, from a static scheme that blocks RAs received on un-trusted ports, or in certain transitional situations.from un-trusted sources, to a more dynamic scheme that uses SeND to challenge RA sources. This document proposes a solutionreviews various techniques applicable on the L2 devices to reduce the threat of rogue RAs by enabling layer 2 devices to forward only RAs received over designated ports.RAs. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. RA-guard as a deployment complement to SENDModel and Applicability . . . . . . . . . . 3 3. RA-Guard state-machine. . . . . . . . . 3 3. Stateless RA-Guard . . . . . . . . . . . 4 3.1. RA-Guard state: OFF. . . . . . . . . . . 5 4. Stateful RA-Guard . . . . . . . . . 4 3.2. RA-Guard state: LEARNING. . . . . . . . . . . . . 5 4.1. State Machine . . . . 4 3.3. RA-Guard state: ACTIVE. . . . . . . . . . . . . . . . . . 5 4.4.2. SeND-based RA-Guard interface states . . . . . .. . . . . . . . . . . . . 5 4.1. RA-Blocking interface . . . . . . .. . . . . . 6 5. RA-Guard Use Considerations . . . . . . 5 4.2. RA-Forwarding interface. . . . . . . . . . . 7 6. IANA Considerations . . . . . . . 5 4.3. RA-Learning interface. . . . . . . . . . . . . . 7 7. Security Considerations . . . . . 5 4.4. RA-Guard interface state transition. . . . . . . . . . . . 5 5. RA-Guard Use Considerations. . 7 8. Acknowledgements . . . . . . . . . . . . . . . . 6 6. IANA Considerations. . . . . . . 7 9. Normative References . . . . . . . . . . . . . . . 6 7. Security Considerations. . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . 6 8. Acknowledgements. . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . . . . 6 9. Normative References . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . . . 910 1. Introduction When operating IPv6 in a shared L2 network segment without complete SeND support by all devices connected or without the availability of the infrastructure neccesarynecessary to support SeND, there is always the risk of facing operational problems due to rogue Router Advertisements generated malliciouslymaliciously or unintentionalyunintentionally by unauthorized or improperly configured routers connecting to the segment. There are several examples of work done on this topic which resulted in several related studies [reference1] [reference2] [reference3].This document describes a solution framework tofor the rogue-RA problem where network segments are designed around a single 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 criteria is used by the L2 device to dynamically validate or invalidate a received RA, this criteria can even be based on SeND mechanisms). 2. RA-guardModel and Applicability 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 complement to SEND RA-guardscenario 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 those environments where SeND might not be suitable or fully supported by all devices involved. It may take time untilluntil 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 might not consider implementing SeND at all such as IPv6 enabled sensors. The RA-guard "SeND-validating" RAAn RA-Guard implementation which SeND-validates RAs on behalf of hosts would potentially simplify some of these challenges. RA-guardRA-Guard can be seen as a superset of SEND with regard to router authorization. Its purpose is to filter Router AdvertizementsAdvertisements based on a set of criterias, from a simplistic "RA dis-alloweddisallowed on a given interface" to "RA allowed from pre-defined sources" and up to full SEND fledgefladge SeND "RA allowed from authorized sources only". In addition to this granularity on the criteria for filtering out Router Advertizements, RA-guardAdvertisements, RA-Guard introduces the concept of router authorization proxy. Instead of each node on the link analysinganalyzing 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. If any other criteria 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 criteria and 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, and avoid any of the nd- proxy pitfalls. RA-guardRA-Guard intends to provide simple solutions to the rogue-RA problem in contexts where simplicity is required while leveraging SeND in an context environment consisting of with a mix of SeND capable devices (L2 switches and routers) and devices that do not consistently use SeND. Futhermore, RA-guardFurthermore, RA-Guard is useful to simplify SeND deployments, as only the L2 switch and the routers are required to carry certificates -their(their own and the trust anchor certificates-.certificates). 3. Stateless RA-Guard state-machineStateless RA-Guard runs on devices that provide connectivity between hostsexamines incoming RAs and other hostsdecide whether to forward or networking devices. An exampleblock 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: o Link-layer address of such RA-Guard capable device would be an OSI Layer-2 switch.the sender o Port on which the frame was received o IP source address o Prefix list The capabilityfollowing configuration information created on the L2-device can be enabled globally at device level or at interface level. When RA-Guard is SEND-based, the timing ofmade available to RA-Guard, to validate against the learning phase, as well asinformation found in the overall behaviorreceived RA frame: o Allowed/Disallowed link-layer address of RA-sender o Allowed/Disallowed ports for receiving RAs o Allowed/Disallowed IP source addresses of RA-sender o Allowed Prefix list and Prefix ranges o Router Priority Once the L2 device doing RA-guard is as- defined in [RFC3971]. When RA-guard is using more static criterias,has validated the state-machinecontent of the RA-Guard capability consists of three different states: State 1: OFF State 2: LEARNINGRA frame against the configuration, it forwards the RA to destination, whether unicast or multicast. Otherwise, the RA is dropped. 4. Stateful RA-Guard 4.1. State 3: ACTIVEMachine Stateful RA-Guard learns dynamically about legitimate RA senders, and store this information for allowing subsequent RAs. A simple 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. The transition between these statesstate machine for stateful RA-Guard can be triggered by manual configurationglobal, per-interface, or by meetingper-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 pre-defined criteria. 3.1.discovery method, the state-machine of the RA-Guard state:capability consists of four different states: o State 1: OFF A device or interface in RA-Guard "OFF" state, operates as if the RA- GuardRA-Guard capability is not available. 3.2. RA-Guard state: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-definedpre- defined period of time by capturing router advertismentsadvertisements 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 blocking all RAs until their validity is verified or, alternatively it can temporarily forward the RAs until the decision is being made. 3.3. RA-Guard state: ACTIVEo State 3: BLOCKING A device or interface running RA-Guard and in ActiveBlocking state will block ingress RA-messages deemed invalid and will forward those deemed valid based on a pre-defined criteria defined. 4. RA-Guard interface states The interfaces of devices with the RA-guard capability enabled can be in three possible states related to RA handling: Learning, Blocking and Forwarding. 4.1. RA-Blocking interface AnRA-messages. o State 4: FORWARDING A device or interface in the RA Blocking state blocks all ingress RA messages whenrunning RA-Guard capability is activated on a device. 4.2. RA-Forwarding interface An interfaceand in the RAForwarding state forwards allwill accept ingress RA messages deemed valid when RA-Guard capability is activated on a device. 4.3. RA-Learning interface An interface in a RA Learning state snoops all receivedRAs and comparesforward them against the criteria identifying valid RAs. While in this state, the RAsto their destination/ The transition between these states can be blockedtriggered by manual configuration or forwarded untilby meeting a decission is taken regarding their validity. 4.4.pre-defined criteria. 4.2. SeND-based RA-Guard interface state transitionIn this scenario, the simplest cases, an RA-Guard enabled interface can be manually set in an RA-BlockingL2 device is blocking or RA-Forwarding state. By default,forwarding RAs based on SeND considerations. Upon capturing an RA on the interfacesinterface, the L2-device will first verify the CGA address and the RSA signature, as specified in section 5 of a legitimate node-in-the-middle could[RFC3971]. RA should be setdropped in RA- Blocking mode and enabledcase 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 forwarding bythe network administrator. Inpublic key referred to in the more general case,RA. If such certificate is found, the L2 device will forward the interface acquiresRA information duringto destination. If not, the 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 Learning stateto destination and by using a pre-defined validity criteria (see section 2) decides whetherand store the analyzed RAsrouter certificate in its cache. In order to operate in this scenario, the L2-device should be forwarded or blocked. Based onprovisioned 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 decission, the interface transitions into the RA Blocking orcase can be resolved by using the RA Forwarding state. Upon detecting new RAs,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 transition back into an RA-Guard Learning state.then be used for NTP and CRL connectivity. 5. RA-Guard Use Considerations The RA-Guard mechanism is effective only when all mesagesmessages between IPv6 devices in the target environment traverse thecontrolled L2 networking devices. When on a shared mediaIn the case of environments such as anEthernet hub,hubs, devices can communicate directly without going through an RA-GuardRA- Guard capable L2 networking device. In this scenario,device, the RA- GuardRA-Guard feature cannot protect against rogue-RAs. RA-Guard mecahnism doesmechanisms do not protect against tunneledoffer protection in environments where IPv6 traffic.traffic is tunneled. 6. IANA Considerations There are no extra IANA consideration for this document. 7. Security Considerations There are no extra Security consideration for this document. 8. Acknowledgements The authors dedicate this document to the memory of Jun-ichiro Hagino (itojun) for his contributions to the development and deployment of IPv6. 9. Normative References [RFC3971] Arkko, J., 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. [reference1] LORIA/INRIA, "NDPMon - IPv6 Neighbor Discovery Protocol Monitor (http://ndpmon.sourceforge.net/)", November 2007. [reference2] KAME Project, "rafixd - developed at KAME - An active rogue RA nullifier (http://www.kame.net/dev/cvsweb2.cgi/ kame/kame/kame/rafixd/)", November 2007. [reference3] Hagino (itojun), Jun-ichiro., "Discussion of the various solutions (http://ipv6samurais.com/ipv6samurais/ demystified/rogue-RA.html)", 2007. Authors' Addresses Gunter Van de Velde Cisco Systems De Kleetlaan 6a Diegem 1831 Belgium Phone: +32 2704 5473 Email: firstname.lastname@example.orgEric Levy Abegnoli Cisco Systems Village d'Entreprises Green Side - 400, Avenue Roumanille Biot - Sophia Antipolis, PROVENCE-ALPES-COTE D'AZUR 06410 France Phone: +33 49 723 2620 Email: email@example.com Gunter Van de Velde Cisco Systems De Kleetlaan 6a Diegem 1831 Belgium Phone: +32 2704 5473 Email: firstname.lastname@example.org Ciprian Popoviciu Cisco Systems 7025-6 Kit Creek Road Research Triangle Park, North Carolina NC 27709-4987 USA Phone: +1 919 392-3723 Email: email@example.com Janos Mohacsi NIIF/Hungarnet 18-22 Victor Hugo Budapest H-1132 Hungary Phone: tbc Email: firstname.lastname@example.org Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at email@example.com.