Re: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-01.txt

Nick Hilliard <nick@inex.ie> Fri, 05 July 2013 14:55 UTC

Return-Path: <nick@inex.ie>
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 A1C6C21F9E34 for <v6ops@ietfa.amsl.com>; Fri, 5 Jul 2013 07:55:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 GoUCKZLczaYn for <v6ops@ietfa.amsl.com>; Fri, 5 Jul 2013 07:54:51 -0700 (PDT)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 6240721F9C56 for <v6ops@ietf.org>; Fri, 5 Jul 2013 07:54:47 -0700 (PDT)
X-Envelope-To: v6ops@ietf.org
Received: from crumpet.dyn.netability.ie (pancake.netability.ie [87.198.142.197]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id r65EsiUn039397 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 5 Jul 2013 15:54:44 +0100 (IST) (envelope-from nick@inex.ie)
X-Authentication-Warning: cheesecake.netability.ie: Host pancake.netability.ie [87.198.142.197] claimed to be crumpet.dyn.netability.ie
Message-ID: <51D6DE34.2060800@inex.ie>
Date: Fri, 05 Jul 2013 15:54:44 +0100
From: Nick Hilliard <nick@inex.ie>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Joe Touch <touch@isi.edu>
References: <20130703235521.17726.15468.idtracker@ietfa.amsl.com> <0BDA30D8-AEDC-4E18-8ACE-64A032305F07@kumari.net> <1372897534.35448.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <CAD6AjGSGeNHPUs9+F6OOAeDOy_FZpTOGkH6viX_fENca4H8X0g@mail.gmail.com> <1372899240.80312.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51D614F6.4030000@isi.edu> <51D6A1C9.8030208@inex.ie> <51D6C2FF.4090103@isi.edu> <51D6C509.7040806@inex.ie> <51D6C66E.5060901@isi.edu> <51D6C7D2.6020504@inex.ie> <51D6CBB9.2060200@isi.edu> <51D6D2FF.40305@inex.ie> <51D6D646.7080102@isi.edu>
In-Reply-To: <51D6D646.7080102@isi.edu>
X-Enigmail-Version: 1.5.1
X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804
X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3
X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee
X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24.
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-01.txt
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: Fri, 05 Jul 2013 14:55:13 -0000

On 05/07/2013 15:20, Joe Touch wrote:
> Your explanation has nothing to do with that. 

In fact it has because it's still the same silicon which is used in both
circumstances.

Alternatively let's talk about infrastructure ACLs.  I also want to be able
to filter ipv6 packets with arbitrary ipv6 headers on my network edge so
that other people cannot reach my core network with known harmful traffic.
 Is that better?  Remember, it's the same silicon which does both.

> However, I can still shut
> down your router any number of ways, by sending lots of interesting things
> in those first 128 bytes that cause the router to overload - e.g.,
> fragments to reassemble, source routes to process, etc.

Eh, no, you generally can't.  Source routed packets have dropped for the
last 15 years.  Reassembly attacks can be protected by dropping packets
from everything except known hosts, and by using infrastructure acls to
stop spoofing.

>> ...All you need to know is the
>> ipv6 address of any interface on the box, and you can trivially trash it
>> remotely.
> 
> Whether that's true does not seem to depend on the header chain length, though.

God almighty, Joe, of course it depends on the header chain length.  It
depends on plenty of other things too, but header chain length is one of them.

This is a ridiculous argument:  you clearly have no operational experience
in this area, nor any clue of how modern routers operate and how their
operational limitations affect production networks.

Nick