IETF Logo Mail Archive

Re: [v6ops] Last Call: <draft-ietf-v6ops-ra-guard-implementation-04.txt> (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice

"Joel M. Halpern" <jmh@joelhalpern.com> Wed, 30 May 2012 16:41 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3678C11E8086 for <v6ops@ietfa.amsl.com>; Wed, 30 May 2012 09:41:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.043
X-Spam-Level:
X-Spam-Status: No, score=-102.043 tagged_above=-999 required=5 tests=[AWL=-0.378, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jBP8QhNmIPgg for <v6ops@ietfa.amsl.com>; Wed, 30 May 2012 09:41:03 -0700 (PDT)
Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id D602821F8438 for <v6ops@ietf.org>; Wed, 30 May 2012 09:41:03 -0700 (PDT)
Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id C9424557FB8 for <v6ops@ietf.org>; Wed, 30 May 2012 09:41:03 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 7CDF71BC98E0; Wed, 30 May 2012 09:41:03 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net
Received: from [10.10.10.110] (pool-71-161-51-212.clppva.btas.verizon.net [71.161.51.212]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id CE5DD1BCDDB0; Wed, 30 May 2012 09:41:02 -0700 (PDT)
Message-ID: <4FC64D8A.2020302@joelhalpern.com>
Date: Wed, 30 May 2012 12:40:42 -0400
From: "Joel M. Halpern" <jmh@joelhalpern.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: 'Fernando Gont' <fernando@gont.com.ar>
References: <20120529143900.25613.76678.idtracker@ietfa.amsl.com> <3B0A71DA-8846-4FFF-9AD8-9B106EF8799B@gmail.com> <4FC52FD3.9060206@gont.com.ar> <AB2444D4-E85B-4E61-9944-47FB1E369203@gmail.com> <003f01cd3e36$a3a09a60$eae1cf20$@lampo@eurid.eu> <DCC302FAA9FE5F4BBA4DCAD4656937791742B3394D@PRVPEXVS03.corp.twcable.com>
In-Reply-To: <DCC302FAA9FE5F4BBA4DCAD4656937791742B3394D@PRVPEXVS03.corp.twcable.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] Last Call: <draft-ietf-v6ops-ra-guard-implementation-04.txt> (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 May 2012 16:41:04 -0000

I do see the importance of being apply to apply RAGuard in a device 
which does not accumulate fragment state.  (I don't want to try to 
analyze the potential DoS attack of having such state.)

However, the proposal introduces a network limtiation, essentially a 
protocol change, in the network.  I did not think v6Ops was free to 
recommend behaviors (dropping unclassifiable fragments) which basically 
violate the base IPv6 spec.

It seems that the right answer was discussed much earlier, namely 
changing the protocol behavior (a 6man activity) to tell hosts to reject 
RA and ND packets which were received in fragments.

If that is the right answer, then we have to be very careful about 
creating long-lived restrictions as a remediation until such a solution 
can be adopted.

Yours,
Joel

v2.23.0 | Report a Bug | By Email