IPv6 Router Advertisement Guard
draft-ietf-v6ops-ra-guard-08

The RFC Editor will make you remove the citations from the Abstract.

Review by Ari Keränen:

The "RA" abbreviation in the title should be expanded.

According to ID checklist, there should not be citations in the abstract:
http://www.ietf.org/id-info/checklist.html#anchor6

Overall, I find the abstract somewhat long and hard to read. Having less details and making editorial fixes would be a good idea (e.g., the phrase "End-nodes must be provisioned with certificate anchors." in the middle sounds strange, and probably is not even that relevant). Perhaps the whole first paragraph of the abstract could be removed.


2. Model and Applicability

Figure 1 does not have a caption. Also, the meaning of the diagonal lines and the horizontal line connecting the two diagonal lines was not clear.

SEND is not spelled consistently (sometimes it's "SeND").

   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.

Capitalize "nd" in the "nd-proxy".


4.1. State Machine

It's hard to see when and why would one move to the BLOCKING state in the state machine. Overall, it would be helpful to have some explanation on the transitions instead of just saying that they are "triggered by manual configuration or by meeting a pre-defined criteria".


4.2. SeND-based RA-Guard

Expand abbreviations and add references where needed (e.g., CGA, RSA, CPS, CRL, NTP).

   Bootstrapping issue in this
   case can be resolved by using the configuration method to specify a
   trusted port to a first router, and send-based-ra-guard method on all
   other ports.

"send-based-ra-guard" should be spelled as in the title?


7. Security Considerations

   Once RA-Guard has setup the proper criteria, for example, it
   identified that a port is allowed to receive RAs, or it identified
   legitimate sources of RA, or certificate base, then there is no
   possible instances of accidentlly filtered legitimate RA's assuming
   the RA-Guard filter enforcement follows strictly the RA-Guard
   criteria's.

Typos: accidentlly, RA's, criteria's

Why isn't spoofing of source address and port discussed? After all, in sections 2 and 3 it is mentioned that L2 and L3 addresses can be used for filtering.

Also, it seems that it would be fairly easy to attack against the stateful RA-Guard described in the Section 4.1 by sending valid RAs during the learning period and then switch to rogue RAs.

I've cleared my DISCUSS based on the changes to section 4.1. I
think a couple of sentences in the definition of the LEARNING state
might benefit from clarification:

         A device or interface in the RA-Guard "Learning" state is
         actively acquiring information about the IPv6 routing devices
         connected.

Append "to its interfaces"?

         The learning process takes place over a pre-defined
         unique period in time, set by manual configuration or it can be
         event triggered.

It's not clear to me whether the event triggering causes the device
to enter or leave the LEARNING state.  That is, does the device
always stay in LEARNING state for a fixed period of time, or can
it stay in LEARNING state either for a fixed period of time or until
some event takes place?

         Once the L2-device has identified through "Learning" the valid
         IPv6 routers and hence also identified the valid RAs, [...]

Would this paragraph be clearer as:

	 When the L2-device reaches the end of the LEARNING state, it
         has a record of which interfaces are attached to links with
         valid IPv6 routers.  The L2-device transtions each interface
         from "LEARNING" into either BLOCKING state if there was no
         valid IPv6 router discovered at the interface, or transitions
         the interface into FORWARDING state if there was a valid IPv6
         router discovered.

Finally, although the state machine is described earlier in section
4.1 as "global, per-interface, or per-peer", this paragraph implies
that the BLOCKING/FORWARDING state is per-interface.

  Please consider the editorial comments in the Gen-ART Review by
  Miguel Garcia on 2010-07-12.

I support Tim's DISCUSS position.

Just some minor issues with definition of abbreviations:

"When operating IPv6 in a shared L2 network segment without complete
SeND support by all devices"

Need a REF to SeND - it is in the Abstract but not in the main body of the doc.

=======

"RA-Guard can be seen as a superset of SEND"
s/SEND/SeND/   ?

=======

In section 4.2

CGA, CPS, CPANTP and CRL all used without expansion or definition

=======