Re: [76attendees] Rogue IPv6 RA

Erik Kline <ek@google.com> Tue, 10 November 2009 02:26 UTC

Return-Path: <ek@google.com>
X-Original-To: ipv6@core3.amsl.com
Delivered-To: ipv6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E55B3A6807 for <ipv6@core3.amsl.com>; Mon, 9 Nov 2009 18:26:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.977
X-Spam-Level:
X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, 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 r+mfb1qs9Utb for <ipv6@core3.amsl.com>; Mon, 9 Nov 2009 18:26:50 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id 5DA193A685B for <ipv6@ietf.org>; Mon, 9 Nov 2009 18:26:49 -0800 (PST)
Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id nAA2RFCY022808 for <ipv6@ietf.org>; Mon, 9 Nov 2009 18:27:15 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1257820035; bh=nfX76JUs222Y1v0kb8SoiDtM3w4=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=EKei0+muVQb5dS2e/hA6CnXEVB6oi8gvYfBT1UaSE8dm9f6eSD9wFMiuE7xwbina+ 2+4dyn+9MhkQ60giJk33w==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=oEVaE3dQSA20vxR0aHDo6VK5N1KlClJkX/Qr8OTPj4q9b8EPMZy7yem0gVfY/Hz26 fFFKjdXxyWpGLEsUOahbw==
Received: from iwn13 (iwn13.prod.google.com [10.241.68.77]) by wpaz13.hot.corp.google.com with ESMTP id nAA2RCiF011448 for <ipv6@ietf.org>; Mon, 9 Nov 2009 18:27:12 -0800
Received: by iwn13 with SMTP id 13so2832024iwn.8 for <ipv6@ietf.org>; Mon, 09 Nov 2009 18:27:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.231.125.19 with SMTP id w19mr2760263ibr.8.1257820032265; Mon, 09 Nov 2009 18:27:12 -0800 (PST)
In-Reply-To: <8447CD11-7EAB-44A6-BF0B-EC9A92ADD24D@nttv6.net>
References: <m24op4b94l.wl%sekiya@wide.ad.jp> <66346671-3773-4A08-94CB-7A777C105631@nttv6.net> <m2my2w9dda.wl%sekiya@wide.ad.jp> <9EC1CCE4-CB5C-4491-8339-A1497475A1D7@nttv6.net> <2e8c64260911091743u2f33241h5988f3a97f80814a@mail.gmail.com> <8447CD11-7EAB-44A6-BF0B-EC9A92ADD24D@nttv6.net>
Date: Tue, 10 Nov 2009 02:27:12 +0000
Message-ID: <2e8c64260911091827q411ded51n111c8a27c3532b9b@mail.gmail.com>
Subject: Re: [76attendees] Rogue IPv6 RA
From: Erik Kline <ek@google.com>
To: Arifumi Matsumoto <arifumi@nttv6.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
Cc: Yuji Sekiya <sekiya@wide.ad.jp>, ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Nov 2009 02:26:51 -0000

2009/11/9 Arifumi Matsumoto <arifumi@nttv6.net>:
> Erik,
>
> On 2009/11/10, at 10:43, Erik Kline wrote:
>
>>> If the latter paragraph only should be executed, the address given
>>> by rogue RA remains, right ?
>>
>> My reading would be that on receipt of a 0-lifetime RA that only the
>> second paragraph would be executed (lifetime timeout).
>
> Second to that.
>
>>  However, all
>> hosts receiving the 0-lifetime RA would then have to recompute the
>> next-hop, which in /some/ cases may require sending a RS (which the
>> rogue RA node would presumably hear and re-answer).  (Of course I
>> haven't verified this against any implementation :)
>
> I fail to get your point.
> Requiring sending a RS leads to ... ?
>
> Even if that RS fails, it does not have any effect on the given
> addressby rogue RA, right ?
>
>

I was contemplating the case where you might want to run a
rogue-ra-killer on a node that listens for RAs, knows which one are
valid, and sends 0-lifetimes for all the rogues.  My point was that if
a node decides it needs to re-RS then the rogue RA node probably
continues to reply (as does the rogue-ra-killer).  Maybe this doesn't
actually happen though because most/all nodes would have also received
the valid RA and would just update next-hop information using that
data.

Just me speculating idly on a weird situation...
-Erik