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

Nicolas Williams <Nicolas.Williams@oracle.com> Wed, 16 June 2010 00:24 UTC

Return-Path: <Nicolas.Williams@oracle.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id A64C53A6A7D; Tue, 15 Jun 2010 17:24:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.825
X-Spam-Status: No, score=-4.825 tagged_above=-999 required=5 tests=[AWL=-0.827, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id W3K0tTnKfc5q; Tue, 15 Jun 2010 17:24:28 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com []) by core3.amsl.com (Postfix) with ESMTP id CD4893A6A89; Tue, 15 Jun 2010 17:24:28 -0700 (PDT)
Received: from rcsinet15.oracle.com (rcsinet15.oracle.com []) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5G0OTRl012268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 Jun 2010 00:24:31 GMT
Received: from acsmt353.oracle.com (acsmt353.oracle.com []) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5FKvjpH016828; Wed, 16 Jun 2010 00:24:29 GMT
Received: from abhmt021.oracle.com by acsmt355.oracle.com with ESMTP id 328600621276647839; Tue, 15 Jun 2010 17:23:59 -0700
Received: from oracle.com (/ by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 15 Jun 2010 17:23:59 -0700
Date: Tue, 15 Jun 2010 19:23:54 -0500
From: Nicolas Williams <Nicolas.Williams@oracle.com>
To: IESG <iesg@ietf.org>, secdir@ietf.org
Message-ID: <20100616002354.GS24077@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.5.20 (2010-03-02)
X-Auth-Type: Internal IP
X-Source-IP: rcsinet15.oracle.com []
X-CT-RefId: str=0001.0A090205.4C1819C0.001A:SCFMA4539811,ss=1,fgs=0
Cc: draft-ietf-v6ops-ra-guard.all@tools.ietf.org
Subject: [secdir] Review of draft-ietf-v6ops-ra-guard-06.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Jun 2010 00:24:29 -0000

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.


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