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

"George, Wes" <wesley.george@twcable.com> Wed, 30 May 2012 16:29 UTC

Return-Path: <wesley.george@twcable.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 115C821F85CC for <v6ops@ietfa.amsl.com>; Wed, 30 May 2012 09:29:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.213
X-Spam-Level:
X-Spam-Status: No, score=-1.213 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1]
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 GDyNQc33aTbD for <v6ops@ietfa.amsl.com>; Wed, 30 May 2012 09:29:35 -0700 (PDT)
Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 74BAB21F85C7 for <v6ops@ietf.org>; Wed, 30 May 2012 09:29:35 -0700 (PDT)
X-SENDER-IP: 10.136.163.11
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="4.75,685,1330923600"; d="scan'208";a="387932599"
Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 30 May 2012 12:28:58 -0400
Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Wed, 30 May 2012 12:29:34 -0400
From: "George, Wes" <wesley.george@twcable.com>
To: Marc Lampo <marc.lampo@eurid.eu>, 'RJ Atkinson' <rja.lists@gmail.com>, 'Fernando Gont' <fernando@gont.com.ar>
Date: Wed, 30 May 2012 12:29:33 -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: Ac09/+YZ5pymZ19jSr2iiaO2JIzI1wANaQMwABI2LVA=
Message-ID: <DCC302FAA9FE5F4BBA4DCAD4656937791742B3394D@PRVPEXVS03.corp.twcable.com>
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>
In-Reply-To: <003f01cd3e36$a3a09a60$eae1cf20$@lampo@eurid.eu>
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 16:29:36 -0000

> -----Original Message-----
> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
> Of Marc Lampo
> Sent: Wednesday, May 30, 2012 3:34 AM
>
>
> Compare it to IPv4 "options" : I always configured my routers to drop
> IPv4 packets that had any options.  Not needed for any "production traffic".
> (unfortunately, such a simple solution does not exist, for IPv6 ...)

[WEG] I think there's a point of clarification here that makes this an invalid comparison. There's a very big difference between telling your router to *ignore* any IP Options it sees in packets going through the box (e.g. process/forward the packet as normal, but without taking any actions manipulated by the options) and in telling it to actually drop the packets altogether, either in general for all traffic through the box, or more specifically on "for us" packets destined for the router's control plane.
"ip options ignore" in Cisco parlance does the former, not the latter, mainly to prevent packets from being sent to the punt path and creating a DoS attack vector.  Indiscriminately Blocking/dropping packets with options configured is not a good idea unless you are operating a device whose position in the network means that you will definitely know whether or not there are any legitimate uses of options on the traffic traversing the device. Unless you have a very tight control on all of the uses of the network such that you know exactly what the traffic does and does not look like, making assumptions like that tend to get us into situations like we find ourselves in with legitimate ICMPv4 traffic being blocked by overzealous security admins. A recommendation in a BCP can't assume that much about the network, and therefore must be very careful in covering this in its recommendations.

Thanks
Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.