Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop

Warren Kumari <warren@kumari.net> Thu, 18 October 2012 17:37 UTC

Return-Path: <warren@kumari.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 49CA421F8507 for <v6ops@ietfa.amsl.com>; Thu, 18 Oct 2012 10:37:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.82
X-Spam-Level:
X-Spam-Status: No, score=-101.82 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSqgaib7E9sH for <v6ops@ietfa.amsl.com>; Thu, 18 Oct 2012 10:37:22 -0700 (PDT)
Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC3F321F8470 for <v6ops@ietf.org>; Thu, 18 Oct 2012 10:37:22 -0700 (PDT)
Received: from [10.196.196.235] (1-193.icannmeeting.org [199.91.193.1]) by vimes.kumari.net (Postfix) with ESMTPSA id 885321B4015C; Thu, 18 Oct 2012 13:37:20 -0400 (EDT)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Warren Kumari <warren@kumari.net>
In-Reply-To: <Pine.LNX.4.64.1210171337470.7337@shell4.bayarea.net>
Date: Thu, 18 Oct 2012 13:37:19 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <AC530E99-4054-4B0A-9B5C-30F9EF4A530C@kumari.net>
References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <E1829B60731D1740BB7A0626B4FAF0A65E0DEDF3A2@XCH-NW-01V.nw.nos.boeing.com> <507DA6A3.20807@inex.ie> <E1829B60731D1740BB7A0626B4FAF0A65E0DEDF3C3@XCH-NW-01V.nw.nos.boeing.com> <507DAB13.2010704@inex.ie> <E1829B60731D1740BB7A0626B4FAF0A65E0DEDF3CE@XCH-NW-01V.nw.nos.boeing.com> <507DDF8A.9010607@inex.ie> <E1829B60731D1740BB7A0626B4FAF0A65E0DEDF5AB@XCH-NW-01V.nw.nos.boeing.com> <BB219517-B488-4777-AE9C-35C57BE91263@kumari.net> <Pine.LNX.4.64.1210171337470.7337@shell4.bayarea.net>
To: "C. M. Heard" <heard@pobox.com>
X-Mailer: Apple Mail (2.1499)
Cc: V6 Ops <v6ops@ietf.org>
Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop
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: Thu, 18 Oct 2012 17:37:23 -0000

On Oct 17, 2012, at 4:58 PM, C. M. Heard <heard@pobox.com> wrote:

> On Wed, 17 Oct 2012, Warren Kumari wrote:
>> On Oct 16, 2012, at 7:19 PM, "Templin, Fred L" <Fred.L.Templin@boeing.com> wrote:
>>> I have been informed by individuals working for major network 
>>> equipment vendors that their implementations can handle router 
>>> reassembly.
>> 
>> "can handle router reassembly" != "can handle router reassembly at 
>> line rate on multiple interfaces".
>> 
>> You really need this to be line rate on all interfaces, otherwise 
>> there is (obviously) a DoS vector here.  Reassembly at 10G (or 
>> 100G) is distinctly non-trivial and requires A: large buffers, B: 
>> short timeouts, C: gets sad if not all bits go through the same 
>> device, D: state and E: hardware designed specifically for this. 
>> This is much more than packet comes in, packet goes out...
> 
> Excuse me, maybe I'm as dumb as a post, but .... why in the world 
> are participants in this thread posing this as problem for the core?

Er, we are not necessarily talking about problems for the core -- a number of folk have 10G at the "edge" / security boundary of the network, and this is where filtering type decisions happen.

Even if you are not anywhere near approaching line-rate, you need to be sure that the device can manage to do this work *at* line rate.  If you usually only push 1Mbps through your e.g 1Gbps interface, if the device can only of reassembly with small fragments at 100Mbps, you have dropped your DoS ability to 100Mbps.


> 
> Except for packets specifically destined for core infrastructure 
> itself --- and those, surely, are not arriving at line rate 

Yes, and part of the reason that packets are not reaching the core infrastructure at line rate is because operators have the ability to examine traffic destined for the core infrastructure and filter / rate-limit it to something reasonable. I may want to allow e.g traceroute to "core" stuff and toss that in one rate-limit bucket, but never allow SSH towards my core.  If I have fragments I have no way of knowing what they are supposed to be part of, and so, er… 



> -- the 
> core has no reason to do anything other than just pass the fragments 
> on and let edge devices deal with them.

Ah, but these are edge devices….

> 
> Indeed, the draft itself states that "IPv6 datagrams with 
> fragmentation headers are a non-issue in the core of the internet, 
> where fragments are routed just like any other IPv6 datagram.  
> However, fragmentation creates operational ssues at the edge of the 
> network that may lead to administratively imposed filtering or 
> inadvertent failure to deliver the fragment to the application."

Yup.
W
> 
> //cmh
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> 

--
"Working the ICANN process is like being nibbled to death by ducks,
it takes forever, it doesn't make sense, and in the end we're still dead in the water." 
    -- Tom Galvin, VeriSign's vice president for government relations.