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

Tim Chown <tjc@ecs.soton.ac.uk> Thu, 03 June 2010 12:31 UTC

Return-Path: <tjc@ecs.soton.ac.uk>
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 2660D28C13C; Thu, 3 Jun 2010 05:31:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 0SXiqPX53sTA; Thu, 3 Jun 2010 05:31:46 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by core3.amsl.com (Postfix) with ESMTP id 423EE28C0DF; Thu, 3 Jun 2010 05:30:55 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id o53CUbWq024102; Thu, 3 Jun 2010 13:30:37 +0100
X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk o53CUbWq024102
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1275568238; bh=fV2KTTT1phNLKZJHM0G6nkdE3iQ=; h=References:In-Reply-To:Mime-Version:Cc:From:Subject:Date:To; b=J2LOuX+1YGTOsLbKMpnB0QqS452F7x18n8Du1Y2mI39QMi291bDkT/OT1G3oMymnU pj9h1liYHwncgl/9H4Omr5a0Z2j7j7BxRoxeV/i/GU7cezIoeWInK6NuKak+Mzyrmz bf/9O2CgxHWjBqYbnCw+fFjqRSWRzXK14Xnm58Io=
Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from <tjc@ecs.soton.ac.uk> with ESMTP id m52DUb0540005256aj ret-id none; Thu, 03 Jun 2010 13:30:38 +0100
Received: from cerf.ecs.soton.ac.uk (cerf.ecs.soton.ac.uk [152.78.69.39]) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id o53CUXVx008362 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 3 Jun 2010 13:30:33 +0100
References: <alpine.BSF.2.00.1006030051570.57855@fledge.watson.org> <F1C0B75B-584A-49F2-BA39-E32332E49758@ecs.soton.ac.uk>
In-Reply-To: <alpine.BSF.2.00.1006030051570.57855@fledge.watson.org>
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset=us-ascii
Message-ID: <EMEW3|54eb9730c008ee40f8ffa6e1026eae8cm52DUb03tjc|ecs.soton.ac.uk|F1C0B75B-584A-49F2-BA39-E32332E49758@ecs.soton.ac.uk>
Content-Transfer-Encoding: quoted-printable
From: Tim Chown <tjc@ecs.soton.ac.uk>
Date: Thu, 3 Jun 2010 13:30:32 +0100
To: secdir-secretary@mit.edu
X-Mailer: Apple Mail (2.1078)
X-ECS-MailScanner: Found to be clean, Found to be clean
X-smtpf-Report: sid=m52DUb054000525600; tid=m52DUb0540005256aj; client=relay,ipv6; mail=; rcpt=; nrcpt=4:0; fails=0
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner-ID: o53CUbWq024102
X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk
X-Mailman-Approved-At: Fri, 04 Jun 2010 10:48:09 -0700
Cc: draft-ietf-v6ops-rogue-ra.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] secdir review of draft-ietf-v6ops-rogue-ra
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, 03 Jun 2010 12:31:52 -0000

Hi,

The document was originally being pushed through alongside Gunter's RA guard draft, with the Rogue RA text as the problem statement and Gunter's text as a/one solution.   Both have been somewhere in the upwards pipe towards publication for a year or so now, hence the expiry.   The RA guard draft was 'tickled' to keep it rom expiring, see http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-05, so if Stig and I need to do the same for our draft, please let us know.

Regarding your comment on malicious attacks, that's a good observation, but the text was steered away from that direction in previous updates based on feedback from the WG (specifically the chart in Section 4 used to have a 'Malicious RA' column, which was later removed), so personally I'd rather not put that perspective back in the text and risk reopening the (same) WG discussion.

On your second point, yes, in theory, but you're pretty much stepping into multihomed host solutions which are rather out of scope for this draft.   For genuine multiple RAs (or RAs with multiple prefixes) there's also RFC3484 address selection.   What our draft basically says is that unintended RAs can cause 'badness', and here are some solutions to them that enterprise administrators could apply. 

On the third point, yes, your assumption is correct.  We could make that more explicit.

It would be really great to get this text published, as it's been queued for quite a while, and it gets cited quite frequently along with RA Guard in various mailing list discussions.

Tim

On 3 Jun 2010, at 06:06, Samuel Weiler wrote:

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