Early Review of draft-ietf-v6ops-ra-guard-
review-ietf-v6ops-ra-guard-secdir-early-williams-2010-06-21-00
| Request | Review of | draft-ietf-v6ops-ra-guard |
|---|---|---|
| Requested revision | No specific revision (document currently at 08) | |
| Type | Early Review | |
| Team | Security Area Directorate (secdir) | |
| Deadline | 2010-07-13 | |
| Requested | 2008-08-06 | |
| Authors | Gunter Van de Velde , János Mohácsi , Eric Levy-Abegnoli , Chip Popoviciu | |
| Draft last updated | 2010-06-21 | |
| Completed reviews |
Secdir Early review of -??
by
Nicolás Williams
|
|
| Assignment | Reviewer | Nicolás Williams |
| State | Completed | |
| Review |
review-ietf-v6ops-ra-guard-secdir-early-williams-2010-06-21
|
|
| Completed | 2010-06-21 |
review-ietf-v6ops-ra-guard-secdir-early-williams-2010-06-21-00
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
--