[secdir] Review of draft-ietf-v6ops-ra-guard-06.txt

[Nicolas Williams <[e-mail]>]

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.

In my opinion this document is not quite ready for publication.

"RA-Guard" is a filtering service that is intended to run in layer-2
network fabrics to help protect routers from attackers.  However, this
is not exactly clear from the text of the abstract.  The possible types
of filters ("filter criteria") given are:

 - stateless filters based on link-layer address of sender, switch port
   on which the RA is received, sender IP address, and "prefix list"
   (what is that?);

 - stateful filters: stateless filters (see above) learned during a
   learning period;

 - stateful filters based on SEND status.

Issues:

 - The Abstract needs a lot of wordsmithing, and needs to expand
   acronyms on first use.

   Here's an attempt at a re-write:

   "
   Routing protocols are often susceptible to spoof attacks.  The
   canonical solution to this is Secure Neighbor Discovery (SEND)
   [RFC3971], a solution that is difficult to deploy.  This document
   proposes a light-weight alternative and complement to SEND based on
   filtering in the layer-2 network fabric, using a variety of filtering
   criteria, including, for example, SEND status.
   "

   (Not much more needs to be said in the abstract.)

 - The Introduction needs a lot of wordsmithing, and needs to expand
   acronyms on first use.

 - Are there particular routing protocols that this solution applies to,
   or not?

 - I don't understand why "Ethernet" is described as incompatible with
   RA-Guard.  There clearly exist switched Ethernet L2 fabrics...
   Perhaps the authors intended to be more specific?

 - The Security Considerations section is too short.  Not enough
   examples of filtering criteria are given in the body of the document,
   and none of the security considerations of using such any specific
   RA-Guard filtering criteria are discussed.  Nor are security
   considerations of use of specific filtering criteria with and without
   also using SEND are discussed.  Nor are the security considerations
   of using learning mode discussed.

 - I suppose there's no need for a standard filter interchange language,
   but perhaps this could be stated explicitly.  Even so, examples with
   a pseudo-language for writing filters may well be useful.

Nico
--