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 --