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

Ronald Bonica <rbonica@juniper.net> Wed, 30 May 2012 19:33 UTC

Return-Path: <rbonica@juniper.net>
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 9C55D11E8115 for <v6ops@ietfa.amsl.com>; Wed, 30 May 2012 12:33:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.135
X-Spam-Level:
X-Spam-Status: No, score=-106.135 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, 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 pIIuVsRVbhJz for <v6ops@ietfa.amsl.com>; Wed, 30 May 2012 12:33:44 -0700 (PDT)
Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id 0447511E8095 for <v6ops@ietf.org>; Wed, 30 May 2012 12:33:39 -0700 (PDT)
Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKT8Z2E1wfLI96mUt2Y3lS8XCg8SnrUywU@postini.com; Wed, 30 May 2012 12:33:43 PDT
Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 30 May 2012 12:32:53 -0700
Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Wed, 30 May 2012 15:32:52 -0400
From: Ronald Bonica <rbonica@juniper.net>
To: "Joel M. Halpern" <jmh@joelhalpern.com>, 'Fernando Gont' <fernando@gont.com.ar>
Date: Wed, 30 May 2012 15:32:51 -0400
Thread-Topic: [v6ops] Last Call: <draft-ietf-v6ops-ra-guard-implementation-04.txt> (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice
Thread-Index: Ac0+gwoMVEm2LQA3Q1qLNs2r2W5m+AAFnHNQ
Message-ID: <13205C286662DE4387D9AF3AC30EF456D76C387C2C@EMBX01-WF.jnpr.net>
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> <4FC64D8A.2020302@joelhalpern.com>
In-Reply-To: <4FC64D8A.2020302@joelhalpern.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 19:33:44 -0000

Joel,

On the one hand, I don't think that v6ops is overstepping its charter. It isn't modifying IPv6. It is merely identifying a combination of IPv6 features that might spell trouble used in the same datagram. 

On the other hand, I would be thrilled if the 6man WG would update RFC 4443 to say something like "ICMPv6 packets MUST NOT be fragmented unless the ICMPv6 Type, Code and Checksum all fit in the first fragment".

                                                      Ron
                                                    <Speaking as individual contributor>


> -----Original Message-----
> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
> Of Joel M. Halpern
> Sent: Wednesday, May 30, 2012 12:41 PM
> To: 'Fernando Gont'
> Cc: 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
> 
> 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
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

v2.23.0 | Report a Bug | By Email