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
                <draft-vandevelde-v6ops-ra-guard-00.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 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]