Re: RFC 5006 and draft-ietf-v6ops-rogue-ra-01

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

Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E657D3A6836 for <ietfarch-v6ops-archive@core3.amsl.com>; Thu, 10 Jun 2010 05:39:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.011
X-Spam-Level:
X-Spam-Status: No, score=-102.011 tagged_above=-999 required=5 tests=[AWL=0.588, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 WzjZqE-ENdJE for <ietfarch-v6ops-archive@core3.amsl.com>; Thu, 10 Jun 2010 05:39:11 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5BFE03A68EB for <v6ops-archive@lists.ietf.org>; Thu, 10 Jun 2010 05:39:11 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from <owner-v6ops@ops.ietf.org>) id 1OMgxN-00061h-H8 for v6ops-data0@psg.com; Thu, 10 Jun 2010 12:34:01 +0000
Received: from [2001:630:d0:f102::25e] (helo=falcon.ecs.soton.ac.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from <tjc@ecs.soton.ac.uk>) id 1OMgxK-000617-Ef for v6ops@ops.ietf.org; Thu, 10 Jun 2010 12:33:58 +0000
Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id o5ACXr8m003083 for <v6ops@ops.ietf.org>; Thu, 10 Jun 2010 13:33:53 +0100
X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk o5ACXr8m003083
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1276173233; bh=P7FX5G+LnYCc7K43CHF/KfpClMw=; h=References:In-Reply-To:Mime-Version:From:Subject:Date:To; b=wy6UnRFIyAb3n3Z8P/w5sLEpg++A4FlaR2bNAJL2oOnsrNJewOJFGwPHqv02RVZKa pCRGEsIHb9n55Oa05xzKPuICTiIoscBHHMm2Vgl5sKqasClGMECJwEUZ61A5cFiU3U /F2PoXZewrELeJHe5rSfMuoJ6/pBUpInbsuafPGM=
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 m59DXr0540047743aX ret-id none; Thu, 10 Jun 2010 13:33:53 +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 o5ACXrTT032008 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <v6ops@ops.ietf.org>; Thu, 10 Jun 2010 13:33:53 +0100
References: <291B137B-7316-49A9-8C19-A606DCFCD019@wisc.edu> <5A07BF4F-33AB-4DB5-847B-EA1DF944C9C3@ecs.soton.ac.uk> <EMEW3|561d2bae90c9ddf8f65add274697b1eem58ESQ03tjc|ecs.soton.ac.uk|5A07BF4F-33AB-4DB5-847B-EA1DF944C9C3@ecs.soton.ac.uk> <A2C63160-0157-43E1-BCF7-2CC96B673AE7@cisco.com> <801675CF-788A-4583-9F2C-9362859DFBD6@cisco.com> <C1E1C597-CC56-48F0-AFD0-35C4496DBED5@ecs.soton.ac.uk>
In-Reply-To: <801675CF-788A-4583-9F2C-9362859DFBD6@cisco.com>
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset="us-ascii"
Message-ID: <EMEW3|dd6df153f280868f3fff0a6658747efcm59DXr03tjc|ecs.soton.ac.uk|C1E1C597-CC56-48F0-AFD0-35C4496DBED5@ecs.soton.ac.uk>
Content-Transfer-Encoding: quoted-printable
From: Tim Chown <tjc@ecs.soton.ac.uk>
Subject: Re: RFC 5006 and draft-ietf-v6ops-rogue-ra-01
Date: Thu, 10 Jun 2010 13:33:52 +0100
To: v6ops@ops.ietf.org
X-Mailer: Apple Mail (2.1078)
X-ECS-MailScanner: Found to be clean, Found to be clean
X-smtpf-Report: sid=m59DXr054004774300; tid=m59DXr0540047743aX; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner-ID: o5ACXr8m003083
X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Hi Roque,

The draft is focused on rogue RAs as that has been an operational issue for us in our dual-stack enterprise for quite some time.   The potential for additional forms of 'badness' to come from RA-based DNS configuration are worth noting, but the mitigations in general are the same.     There may be some additional mitigation methods specific to the DNS option/configuration.

While we do run tools to detect various forms of NDP 'abuse' on our network, e.g. use of the THC toolkit, we don't (yet) see evidence of that.    The rogue RA problem is far more heavily observed and cited and thus having a consolidated informational problem statement that also describes some potential mitigations focused on that problem is, we believe, useful.   Malicious rogue RAs are quite rare - ones caused by Windows ICS, accidental misconfiguration or devices being moved where their role changes (e.g. 6to4 router at home, client at work) are far more common.   But then we're in a CS dept, so our users tend to be more 'creative'.

We released ramond (http://ramond.sourceforge.net/) as an enhancement to rafixd as one tool for people to use.   RA Guard also has good potential.

Tim

On 10 Jun 2010, at 10:26, Roque Gagliano wrote:

> Sorry,
> 
> I should have said NDP options and not ICMPv6 options.
> 
> Roque.
> 
> On Jun 10, 2010, at 11:15 AM, Roque Gagliano wrote:
> 
>> Hi Tim,
>> 
>>> We could add text about this.   That would involve some mention of the problem in Section 1 (introduction), perhaps a brief discussion as an extra point in Section 5, and adding the mitigation mentioned in draft-ietf-6man-dns-options-bis-02 of disabling the host from processing DNS options in the RA (assuming the host implementation supports that of course, which isn't a MUST in the draft as far as I can see).   Other than that, I think the text in the draft about rogue RA 'badness' is generic enough to cover bad DNS information.   I'm happy to work with Stig on such text if it's deemed useful, and won't hold up publication too much more.
>>> 
>>> I note that draft-ietf-6man-dns-options-bis-02, which passed 6man WG last call, makes no reference to the rogue RA draft in its own security discussion, and also no mention of RA Guard.
>>> 
>> 
>> Why would the dns-option be different from any other ICMPv6 option in this draft context? I would keep the text generic on reference to ICMP options.
>> 
>> Roque
>> 
>>> Tim
>> 
>