Early Review of draft-chown-v6ops-rogue-ra-
review-chown-v6ops-rogue-ra-secdir-early-weiler-2010-06-03-00

Request Review of draft-chown-v6ops-rogue-ra
Requested rev. no specific revision (document currently at 03)
Type Early Review
Team Security Area Directorate (secdir)
Deadline 2010-06-03
Requested 2008-08-06
Draft last updated 2010-06-03
Completed reviews Secdir Early review of -?? by Samuel Weiler
Assignment Reviewer Samuel Weiler
State Completed
Review review-chown-v6ops-rogue-ra-secdir-early-weiler-2010-06-03
Review completed: 2010-06-03

Review
review-chown-v6ops-rogue-ra-secdir-early-weiler-2010-06-03

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.



This expired doc has been in the secdir queue for some time.  It's not 


clear what the current state is, but I gave it a once-over now and 


will look at it again if it's ever revived.






While the security considerations sectional is minimal, that's 


generally fine for an informational doc such as this.






That said, I would like to see more thought given to malicious RAs and 


whether each of these methods could be effectively applied against 


them (e.g. how easy is each to subvert?).  And if none of the methods 


are applicable, as the current security considerations says, then also 


call that out in the abstract and intro.






Second, I'm surprised that the only end-host based solutions are 


staticly-configured packet filters (3.7) and delays (3.9).  Why not 


simply "try, try again": accept multiple RAs, see which ones work, and 


discard (or at least don't use) the rest?






Lastly, the table in section 4 is a little unclear: does "Y" mean 


"helps (somewhat)" or "is completely sufficient"?  I think it means 


the former, but clarity would be good.