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

Nick Hilliard <nick@inex.ie> Tue, 16 October 2012 22:28 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 38BC821F854E for <v6ops@ietfa.amsl.com>; Tue, 16 Oct 2012 15:28:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.3
X-Spam-Level:
X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001]
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 3-15c-yWeVl4 for <v6ops@ietfa.amsl.com>; Tue, 16 Oct 2012 15:28:41 -0700 (PDT)
Received: from mail.acquirer.com (mail.acquirer.com [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 39E1221F853F for <v6ops@ietf.org>; Tue, 16 Oct 2012 15:28:40 -0700 (PDT)
X-Envelope-To: v6ops@ietf.org
Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100:9ca5:2d61:684e:c638]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id q9GMRo1l030835 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 16 Oct 2012 23:27:56 +0100 (IST) (envelope-from nick@inex.ie)
Message-ID: <507DDF8A.9010607@inex.ie>
Date: Tue, 16 Oct 2012 23:28:26 +0100
From: Nick Hilliard <nick@inex.ie>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>
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>
In-Reply-To: <E1829B60731D1740BB7A0626B4FAF0A65E0DEDF3CE@XCH-NW-01V.nw.nos.boeing.com>
X-Enigmail-Version: 1.4.5
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" <v6ops@ietf.org>, "draft-taylor-v6ops-fragdrop@tools.ietf.org" <draft-taylor-v6ops-fragdrop@tools.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: Tue, 16 Oct 2012 22:28:42 -0000

>>> Why not just let non-initial fragments through and then forward
>>> or don't forward the initial fragment depending on whether it
>>> contains enough information in tlv headers to permit a filtering
>>> decision?
>>
>> i spot some DoSs there.
> 
> DoS'ing whom - the end systems? End systems know when to flush
> incomplete reassemblies.

The intermediate systems.  Well, maybe the end systems too, but that's a
different issue.

The problem with the intermediate systems is how you handle the packets.
Most fast/dumb boxes are able to process fixed-shape packets in hardware
because ASICs are pretty good at that sort of thing.  If you need to
process TLVs at line rate and make forwarding decisions on that basis, then
you need much smarter hardware.  So the issue comes down to what happens
when you have a fast/dumb box forwarding ipv6 packets with interesting
headers, and the dumb box is expected to do some level of filtering.

For fragments, if your dedicated hardware doesn't handle them natively,
then you have a choice between:

- allowing them through always
- dropping them always
- dropping them after a certain rate limit
- punting them to a more intelligent part of the forwarding device

For punted packets, most vendors punt them to the management plane because
they don't have a dedicated path for handling packets which are difficult
to parse.  This creates a management plane DoS which can be mitigated by
rate limiting the punting process.  So you end up with either a management
plane DoS, or an initial fragment DoS, or both.

Now, you could argue that dumb fast boxes shouldn't attempt ipv6 acls in
the first place, but what do you do if you want to implement v6 iACLs to
protect your internal infrastructure from external attacks?  Do you allow
all fragments through and potentially compromise your network?  Or do you
drop all fragments because your routing iron only has the capability to
either accept all fragments or drop them all?

> For middleboxes that sit in front of
> "low-end" end systems, there is also still the option of
> Virtual Fragmentation Reassembly.

urgh, state.  As a general principal, the less state you have to deal with
in your intermediate systems, the better.

> Plus, if we can't rely on ICMP PTB and we can't rely on IPv6
> fragmentation/reassembly, then all we are left with is 1280
> and IPv6 is the new ATM...

We had problems with this for years in the ipv4 world.  IPv6 has made it
much worse by implementing a difficult-to-parse IP Options style header
mechanism and expecting that this is an integral part of the protocol.  We
fixed it in IPv4 by universally dropping packets with options and by
creating an expectation that this was acceptable.

IOW, there are large parts of the internet for which there is no good
solution to this problem.  I.e. any part which doesn't forward packets
using a highly intelligent packet processing core.

Nick