IPv6 Router Advertisement Guard
RFC 6105
Yes
No Objection
Note: This ballot was opened for revision 08 and is now closed.
Lars Eggert No Objection
(Ron Bonica; former steering group member) Yes
(Adrian Farrel; former steering group member) (was Discuss) No Objection
The RFC Editor will make you remove the citations from the Abstract.
(Alexey Melnikov; former steering group member) No Objection
(Dan Romascanu; former steering group member) (was Discuss) No Objection
(David Harrington; former steering group member) No Objection
(Gonzalo Camarillo; former steering group member) No Objection
(Jari Arkko; former steering group member) (was Discuss) No Objection
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.
(Peter Saint-Andre; former steering group member) No Objection
(Ralph Droms; former steering group member) (was Discuss) No Objection
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.
(Robert Sparks; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
Please consider the editorial comments in the Gen-ART Review by Miguel Garcia on 2010-07-12.
(Sean Turner; former steering group member) No Objection
I support Tim's DISCUSS position.
(Stewart Bryant; former steering group member) No Objection
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 =======
(Tim Polk; former steering group member) (was Discuss) No Objection