v6ops Working Group G. Van de Velde Internet-Draft E. Levy-Abegnoli Expires: May 15, 2008 C. Popoviciu Cisco Systems J. Mohacsi NIIF/Hungarnet November 12, 2007 IPv6 RA-Guard 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 May 15, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract When using IPv6 within a single L2 network segment it is assumed that for good network behavior, the available routers attached to the segment are valid routers. A rogue Router Advertisement (RA) [1] however could be sent by accident by a misconfigured network device, or on purpose by malicious devices. This document proposes a Van de Velde, et al. Expires May 15, 2008 [Page 1] Internet-Draft IPv6 RA-Guard November 2007 solution to reduce the threat of rogue RAs by enabling layer 2 devices to provide forward RAs received over designated ports. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. RA-Guard state-machine . . . . . . . . . . . . . . . . . . . . 3 2.1. RA-Guard state: OFF . . . . . . . . . . . . . . . . . . . . 3 2.2. RA-Guard state: LEARNING . . . . . . . . . . . . . . . . . 3 2.3. RA-Guard state: ACTIVE . . . . . . . . . . . . . . . . . . 4 3. RA-Guard interface states . . . . . . . . . . . . . . . . . . . 4 3.1. RA-Blocking interface . . . . . . . . . . . . . . . . . . . 4 3.2. RA-Forwarding interface . . . . . . . . . . . . . . . . . . 4 3.3. RA-Learning interface . . . . . . . . . . . . . . . . . . . 4 3.4. RA-Guard interface state transition . . . . . . . . . . . . 4 4. Pittfals of RA-Guard . . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 8.2. Informative References . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Intellectual Property and Copyright Statements . . . . . . . . . . 7 Van de Velde, et al. Expires May 15, 2008 [Page 2] Internet-Draft IPv6 RA-Guard November 2007 1. Introduction When operating IPv6 in a shared L2 network segment there is always the risk of facing operational problems due to rogue Router Advertisements generated malliciously or unintentionaly by unauthorized or improperly configured routers connecting to the segment. If a network segment is designed around a single or a set of L2-switching devices capable of identifying invalid RAs and blocking them, then the impact of rogue RA's can be minimized. The identification of valid RA's can be done based on various criteria defined by the network administrator. Previous art to minimalize the impact of rogue RA's has been investigated by various people and entities. Some examples of these studies are [2] [3] [4]. 2. 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. Depending on the mode of operation, 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. 2.1. RA-Guard state: OFF A device or interface in RA-Guard "OFF" state, operates as if the RA- Guard capability is not available. 2.2. RA-Guard state: 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 advertisments. 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 Van de Velde, et al. Expires May 15, 2008 [Page 3] Internet-Draft IPv6 RA-Guard November 2007 blocking all RAs until their validity is verified or, alternatively it can temporarily forward the RAs until the decision is being made. 2.3. RA-Guard state: ACTIVE A device or interface running RA-Guard and in Active state will block ingress RA-messages deemed invalid and will forward those deemed valid based on a pre-defined criteria defined. 3. 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. 3.1. RA-Blocking interface An interface in the RA Blocking state blocks all ingress RA messages when RA-Guard capability is activated on a device. 3.2. RA-Forwarding interface An interface in the RA Forwarding state forwards all ingress RA messages deemed valid when RA-Guard capability is activated on a device. 3.3. RA-Learning interface An interface in a RA Learning state all ingress RAs are snooped and compared against the criteria identifying valid RAs. While in this state, the RAs can be blocked or forwarded until a decission is taken regarding their validity. 3.4. RA-Guard interface state transition In the simplest cases, an RA-Guard enabled interface can be manually set in an RA-Blocking or RA-Forwarding state. In the more general case, the interface acquires RA information during the RA Learning state and by using a pre-defined validity criteria decides whether the analyzed RAs should be forwarded or blocked. Based on this decission, the interface transitions into the RA Blocking or the RA Forwarding state. Upon detecting new RAs, a port can transition back into an RA-Guard Learning state. Van de Velde, et al. Expires May 15, 2008 [Page 4] Internet-Draft IPv6 RA-Guard November 2007 4. Pittfals of RA-Guard The RA-Guard mechanism relies on the assumption that all mesages between IPv6 devices in the target environment traverse the controlled L2 networking devices. When on a shared media such as an Ethernet hub, devices can communicate directly without going through an RA-Guard capable L2 networking device. In this scenario, the RA- Guard feature has no additional value. RA-Guard mecahnism does not protect against tunneled IPv6 traffic. RA-Guard does not provide any protection against the content or IPv6 addresses used with RA-messages. 5. IANA Considerations There are no extra IANA consideration for this document. 6. Security Considerations There are no extra Security consideration for this document. 7. Acknowledgements The authors dedicate this document to the memory of Jun-ichiro Hagino (itojun) for his contributions to the development and deployment of IPv6. 8. References 8.1. Normative References 8.2. Informative References [1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [2] LORIA/INRIA, "NDPMon - IPv6 Neighbor Discovery Protocol Monitor (http://ndpmon.sourceforge.net/)", November 2007. [3] KAME Project, "rafixd - developed at KAME - An active rogue RA nullifier (http://www.kame.net/dev/cvsweb2.cgi/kame/kame/kame/rafixd/)", November 2007. Van de Velde, et al. Expires May 15, 2008 [Page 5] Internet-Draft IPv6 RA-Guard November 2007 [4] 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: gunter@cisco.com Eric 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: elevyabe@cisco.com Ciprian Popoviciu Cisco Systems 7025-6 Kit Creek Road Research Triangle Park, North Carolina NC 27709-4987 USA Phone: +1 919 392-3723 Email: cpopovic@cisco.com Janos Mohacsi NIIF/Hungarnet 18-22 Victor Hugo Budapest H-1132 Hungary Phone: tbc Email: mohacsi@niif.hu Van de Velde, et al. Expires May 15, 2008 [Page 6] Internet-Draft IPv6 RA-Guard November 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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 ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Van de Velde, et al. Expires May 15, 2008 [Page 7]