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

Tim Chown <tjc@ecs.soton.ac.uk> Thu, 10 June 2010 13:12 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 6001628C0E2; Thu, 10 Jun 2010 06:12:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[AWL=0.504, BAYES_00=-2.599]
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 cdo6jE7SFc-N; Thu, 10 Jun 2010 06:12:06 -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 7B5F728C0E8; Thu, 10 Jun 2010 06:12:05 -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 o5ADBw9k012507; Thu, 10 Jun 2010 14:11:58 +0100
X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk o5ADBw9k012507
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1276175519; bh=tp64VpENGa/zVz/UEpx6FDC96j4=; h=References:In-Reply-To:Mime-Version:Cc:From:Subject:Date:To; b=WUd1f+wTo2bjR6c3Lmu+MlM5SWWvhlzvCqIE6PU/NSpEKFWoZqiJUPfCV6BAOCCVC iuJvhSAbMs6w2guAnUFWmGauZniXb1nj7c2ytdnqg0Sv2ivcn3QtQhEXXvJoXsawcY 9690slGS5ryAXoF66O6dgSF1dHF+3OUA4ymaPm5Y=
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 m59EBw0540048079bQ ret-id none; Thu, 10 Jun 2010 14:11:59 +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 o5ADBsuS008577 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 10 Jun 2010 14:11:55 +0100
References: <alpine.BSF.2.00.1006030051570.57855@fledge.watson.org> <F1C0B75B-584A-49F2-BA39-E32332E49758@ecs.soton.ac.uk> <EMEW3|54eb9730c008ee40f8ffa6e1026eae8cm52DUb03tjc|ecs.soton.ac.uk|F1C0B75B-584A-49F2-BA39-E32332E49758@ecs.soton.ac.uk> <alpine.BSF.2.00.1006091254200.59072@fledge.watson.org> <1F7AAE6F-B3FC-4198-A9DD-C82E6B4F65C2@ecs.soton.ac.uk>
In-Reply-To: <alpine.BSF.2.00.1006091254200.59072@fledge.watson.org>
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset=us-ascii
Message-ID: <EMEW3|6011fe9a4749f944aadc97aa303fb01bm59EBw03tjc|ecs.soton.ac.uk|1F7AAE6F-B3FC-4198-A9DD-C82E6B4F65C2@ecs.soton.ac.uk>
Content-Transfer-Encoding: quoted-printable
From: Tim Chown <tjc@ecs.soton.ac.uk>
Date: Thu, 10 Jun 2010 14:11:54 +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=m59EBw054004807900; tid=m59EBw0540048079bQ; 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: o5ADBw9k012507
X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk
X-Mailman-Approved-At: Thu, 10 Jun 2010 06:49:50 -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, 10 Jun 2010 13:12:08 -0000

On 9 Jun 2010, at 18:01, Samuel Weiler wrote:

> Thanks for the explanation re: why the malicious RA text was removed.
> 
> On Thu, 3 Jun 2010, Tim Chown wrote:
> 
> [reordering text for ease of reading]
> 
>>> 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?
>> 
>> 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.
> 
> I'm not convinced that "test before use" is necessarily equivalent to multihoming.  And the doc is already covering some host-based mitigations (in 3.7 and 3.9).  Why discard this one?

Fair point Sam.   I think 3.9 (wait before use) was a suggestion from one IETF WG meeting, which really isn't that practical, so could actually be quite reasonably dropped.   The original aim of the draft was to cite practical steps an administrator could take, but 3.2 (RA snooping/RA Guard), 3.4 (use SeND) and 3.11 (add options to DHCPv6) are all methods that are also, as yet, not available.   So we could add your suggestion.

One consideration in 'test before use' though is that connectivity might work, from a user/application perspective, but it might not work as intended or with undesirable consequences/side effects, e.g. via an unintended VLAN or router.

Tim