Hi,
Some typos and comments/questions inline below.
Internet-Drafts@ietf.org 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+
Attachment:
pgpkw85QJ2qqC.pgp
Description: PGP signature