[secdir] secdir review of draft-ietf-v6ops-rogue-ra

Samuel Weiler <weiler@watson.org> Thu, 03 June 2010 05:07 UTC

Return-Path: <weiler@watson.org>
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 C2C353A69C5; Wed, 2 Jun 2010 22:07:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.788
X-Spam-Level:
X-Spam-Status: No, score=-0.788 tagged_above=-999 required=5 tests=[AWL=-0.789, BAYES_50=0.001]
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 sF6WU3dmrK4Z; Wed, 2 Jun 2010 22:07:06 -0700 (PDT)
Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id B1C673A693B; Wed, 2 Jun 2010 22:07:06 -0700 (PDT)
Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id o5356rXV060612; Thu, 3 Jun 2010 01:06:53 -0400 (EDT) (envelope-from weiler@watson.org)
Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id o5356qlQ060607; Thu, 3 Jun 2010 01:06:53 -0400 (EDT) (envelope-from weiler@watson.org)
X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs
Date: Thu, 03 Jun 2010 01:06:52 -0400
From: Samuel Weiler <weiler@watson.org>
To: draft-ietf-v6ops-rogue-ra.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Message-ID: <alpine.BSF.2.00.1006030051570.57855@fledge.watson.org>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format="flowed"; charset="US-ASCII"
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Thu, 03 Jun 2010 01:06:53 -0400 (EDT)
Subject: [secdir] secdir review of draft-ietf-v6ops-rogue-ra
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: secdir-secretary@mit.edu
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, 03 Jun 2010 05:07:07 -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.

This expired doc has been in the secdir queue for some time.  It's not 
clear what the current state is, but I gave it a once-over now and 
will look at it again if it's ever revived.

While the security considerations sectional is minimal, that's 
generally fine for an informational doc such as this.

That said, I would like to see more thought given to malicious RAs and 
whether each of these methods could be effectively applied against 
them (e.g. how easy is each to subvert?).  And if none of the methods 
are applicable, as the current security considerations says, then also 
call that out in the abstract and intro.

Second, I'm surprised that the only end-host based solutions are 
staticly-configured packet filters (3.7) and delays (3.9).  Why not 
simply "try, try again": accept multiple RAs, see which ones work, and 
discard (or at least don't use) the rest?

Lastly, the table in section 4 is a little unclear: does "Y" mean 
"helps (somewhat)" or "is completely sufficient"?  I think it means 
the former, but clarity would be good.