Subject: Comments on draft-ietf-v6ops-ra-guard-00.txt

From: [email-masked] (Arnaud Ebalard)
Date: Mon, 07 Jul 2008 11:13:31 +0200

Hi,

Some typos and comments/questions inline below.

[email-masked] writes:

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the IPv6 Operations Working Group of the IETF.
>
>
> 	Title           : IPv6 RA-Guard
> 	Author(s)       : G. Van de Velde, et al.
> 	Filename        : draft-ietf-v6ops-ra-guard-00.txt
> 	Pages           : 9
> 	Date            : 2008-06-30
>
> When using IPv6 within a single L2 network segment it is neccesary to
                                                           ^^^^^^^^^
                                                           necessary

> ensure that all routers advertising their services within it are
> valid.  In cases where it is not convinient or possible to use SeND
                                   ^^^^^^^^^^
                                   convenient

> [RFC3971] a rogue Router Advertisement (RA) [RFC4861] could be sent
> by accident due to misconfiguraton or ill intended.  Simple solutions
> for protecting against rogue RAs are beneficial in complementing SeND
> in securing the L2 domain for ceratin types of devices or in certain
                                ^^^^^^^
                                certain

> transitional situations.
> This document proposes a solution to reduce the threat of rogue RAs
> by enabling layer 2 devices to forward only RAs received over
> designated ports.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ra-guard-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
>
>
>
> v6ops Working Group                                      G. Van de Velde
> Internet-Draft                                          E. Levy-Abegnoli
> Expires: January 2, 2009                                    C. Popoviciu
>                                                            Cisco Systems
>                                                               J. Mohacsi
>                                                           NIIF/Hungarnet
>                                                             July 1, 2008
>
>
>                              IPv6 RA-Guard
>                    <draft-ietf-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 January 2, 2009.
>
> Abstract
>
>    When using IPv6 within a single L2 network segment it is neccesary
                                                              ^^^^^^^^^
                                                              necessary

>    ensure that all routers advertising their services within it are
>    valid.  In cases where it is not convinient or possible to use SeND
                                      ^^^^^^^^^^
                                      convenient

>    [RFC3971] a rogue Router Advertisement (RA) [RFC4861] could be sent
>    by accident due to misconfiguraton or ill intended.  Simple solutions
>    for protecting against rogue RAs are beneficial in complementing SeND
>    in securing the L2 domain for ceratin types of devices or in certain
>    transitional situations.

[snip]

> 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 neccesary to support SeND, there is always the
                        ^^^^^^^^^
                        necessary

>    risk of facing operational problems due to rogue Router
>    Advertisements generated malliciously or unintentionaly by
                              ^^^^^^^^^^^^    ^^^^^^^^^^^^^^
                              maliciously              nally ?

>    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 to 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-guard as a deployment complement to SEND
>
>    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 untill SeND is
                                                          ^^^^^^
                                                          until

>    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" RA 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 Advertizements based
>    on a set of criterias, from a simplistic "RA dis-allowed on a given
                                                  ^^^^^^^^^^^
                                                  disallowed

>    interface" to "RA allowed from pre-defined sources" and up to full
>    SEND fledge "RA allowed from authorized sources only".
>
>    In addition to this granularity on the criteria for filtering out
>    Router Advertizements, RA-guard introduces the concept of router
            ^^^^^^^^^^^^^^ 
            Advertisements

>    authorization proxy.  Instead of each node on the link analysing 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
>
>
>
> Van de Velde, et al.     Expires January 2, 2009                [Page 3]
> 
> Internet-Draft                IPv6 RA-Guard                    July 2008
>
>
>    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-guard intends to provide simple solutions to the rogue-RA problem
>    in contexts where simplicity is required while leveraging SeND in
>    context with a mix of SeND capable devices (L2 switches and routers)
>    and devices that do not consistently use SeND.  Futhermore, 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-.

For what purpose would the switches need their own certificate if they
should act transparently (maybe it's simply the sentence) ?

> 3.  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.
>
>    When RA-Guard is SEND-based, the timing of the learning phase, as
>    well as the overall behavior of the device doing RA-guard is as-
>    defined in [RFC3971].

     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

     What does it mean, *precisely* ?

>    When RA-guard is using more static criterias, 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.
>
> 3.1.  RA-Guard state: OFF
>
>    A device or interface in RA-Guard "OFF" state, operates as if the RA-
>    Guard capability is not available.
>
> 3.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 or it can be event triggered.  The
                      ^^^^^^^^^^^^^^
                      advertisements

>
>
>
> Van de Velde, et al.     Expires January 2, 2009                [Page 4]
> 
> Internet-Draft                IPv6 RA-Guard                    July 2008
>
>
>    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: 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.
                                           ^^^^^^^
                                           to be removed

> 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
>
>    An interface in the RA Blocking state blocks all ingress RA messages
>    when RA-Guard capability is activated on a device.
>
> 4.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.
>
> 4.3.  RA-Learning interface
>
>    An interface in a RA Learning state snoops all received RAs and
>    compares them against the criteria identifying valid RAs.  While in
>    this state, the RAs can be blocked or forwarded until a decission
                                                             ^^^^^^^^^
                                                             decision

>    is taken regarding their validity.
>
> 4.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.  By default, the
>    interfaces of a legitimate node-in-the-middle could be set in RA-
>    Blocking mode and enabled for forwarding by the network
>    administrator.  In the more general case, the interface acquires RA
>    information during the RA Learning state and by using a pre-defined
>    validity criteria (see section 2) decides whether the analyzed RAs
>    should be forwarded or blocked.  Based on this decission, the
                                                    ^^^^^^^^^
                                                    decision

>    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.
                                    ^^^
                            ambiguous, too vague

> 5.  RA-Guard Use Considerations
> 
>    The RA-Guard mechanism is effective only when all mesages between
                                                       ^^^^^^^
                                                       messages

>    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 cannot protect against rogue-RAs.
> 
>    RA-Guard mecahnism does not protect against tunneled IPv6 traffic.

[snip]

> 7.  Security Considerations
>
>    There are no extra Security consideration for this document.

     really ? ;-)

[snip]

a+