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

"Gunter Van de Velde (gvandeve)" <gvandeve@cisco.com> Thu, 02 September 2010 10:41 UTC

Return-Path: <gvandeve@cisco.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BA433A6957; Thu, 2 Sep 2010 03:41:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.427
X-Spam-Level:
X-Spam-Status: No, score=-10.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zNGbFhib3ME0; Thu, 2 Sep 2010 03:41:48 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 28A8B3A6934; Thu, 2 Sep 2010 03:41:48 -0700 (PDT)
Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAFYcf0xAZnwN/2dsb2JhbACgfHGgTZwNhTkEjRc
X-IronPort-AV: E=Sophos;i="4.56,307,1280707200"; d="scan'208";a="154675974"
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 02 Sep 2010 10:42:17 +0000
Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o82AgGZb010176; Thu, 2 Sep 2010 10:42:17 GMT
Received: from xmb-ams-101.cisco.com ([144.254.74.76]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 2 Sep 2010 12:42:17 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 2 Sep 2010 12:42:16 +0200
Message-ID: <4269EA985EACD24987D82DAE2FEC62E5021A9CB3@XMB-AMS-101.cisco.com>
In-Reply-To: <20100616002354.GS24077@oracle.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [secdir] Review of draft-ietf-v6ops-ra-guard-06.txt
Thread-Index: AcsM6mpD6GfhEMqjT2S3J6AtTjUS5A9oI0vw
References: <20100616002354.GS24077@oracle.com>
From: "Gunter Van de Velde (gvandeve)" <gvandeve@cisco.com>
To: "Nicolas Williams" <Nicolas.Williams@oracle.com>, "IESG" <iesg@ietf.org>, <secdir@ietf.org>
X-OriginalArrivalTime: 02 Sep 2010 10:42:17.0476 (UTC) FILETIME=[83592C40:01CB4A8B]
X-Mailman-Approved-At: Fri, 03 Sep 2010 11:31:04 -0700
Cc: draft-ietf-v6ops-ra-guard.all@tools.ietf.org
Subject: Re: [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: Thu, 02 Sep 2010 10:41:49 -0000

Hi Nicolas,

We just submitted a new draft:
http://www.ietf.org/id/draft-ietf-v6ops-ra-guard-08.txt

Inline: GV>

-----Original Message-----
From: Nicolas Williams [mailto:Nicolas.Williams@oracle.com] 
Sent: Wednesday, June 16, 2010 2:24 AM
To: IESG; secdir@ietf.org
Cc: draft-ietf-v6ops-ra-guard.all@tools.ietf.org
Subject: [secdir] Review of draft-ietf-v6ops-ra-guard-06.txt

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.


GV> ack.. abstract in the paper now is based upon your suggestion.

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

GV> Agreed. Abstract is changed, inline with some of the discuss
comments.

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

GV> Done

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

GV> nope.. just IPv6 Router advertisement... 

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

GV> I removed the example

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

GV> its longer now inline with the discuss comments

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

GV> Not sure this is needed for this trivial kind of mechanism

Many thanks for your review and work on this paper.

Gunter Van de Velde