Re: Non-Last Small IPv6 Fragments

Ole Troan <otroan@employees.org> Sat, 12 January 2019 09:49 UTC

Return-Path: <otroan@employees.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0FF128D09 for <ipv6@ietfa.amsl.com>; Sat, 12 Jan 2019 01:49:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJoHofdm_FVV for <ipv6@ietfa.amsl.com>; Sat, 12 Jan 2019 01:49:01 -0800 (PST)
Received: from bugle.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 000BA12785F for <ipv6@ietf.org>; Sat, 12 Jan 2019 01:49:00 -0800 (PST)
Received: from astfgl.hanazo.no (30.51-175-112.customer.lyse.net [51.175.112.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id 50B82FECBE51 for <ipv6@ietf.org>; Sat, 12 Jan 2019 09:49:00 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id A0365C7A634 for <ipv6@ietf.org>; Sat, 12 Jan 2019 10:48:57 +0100 (CET)
From: Ole Troan <otroan@employees.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Subject: Re: Non-Last Small IPv6 Fragments
Date: Sat, 12 Jan 2019 10:48:57 +0100
References: <CAOSSMjV0Vazum5OKztWhAhJrjLjXc5w5YGxdzHgbzi7YVSk7rg@mail.gmail.com> <BYAPR05MB4245B9305E6EC57EDD45509FAE840@BYAPR05MB4245.namprd05.prod.outlook.com> <7453645f-ff91-e866-b087-e7d4f1450ab6@gmail.com> <0e792b48-4360-6977-9ae8-9cdfdc78c7b8@gmail.com> <16A642DC-D3A4-452C-B7D1-20CA0EEEDDA2@lists.zabbadoz.net> <CAOSSMjWS9po2XuBHJ5hbN9hfNDKZ1diecH08Kt697-15jRtAvg@mail.gmail.com> <0e0c3141-889e-ff60-2787-2889b3a9af6b@si6networks.com> <748DA428-5AB2-4487-A4FB-F2DABF5BF8BE@thehobsons.co.uk> <8b43af81-1c49-5cea-6472-97703674e661@si6networks.com> <CAN-Dau1HwG5RndacpSA+si+zKuTdpSvA=QA1A11A==rMNe=4+w@mail.gmail.com> <CALx6S35KNhV2gFp9OdU+M1zy5WUuEAEvXkDXNDWWxi7uQ4e_cw@mail.gmail.com> <CAN-Dau0rTdiiF2SjByxcMG6nhPCEjUH2pYBCOeK_FSGJ_ucDQw@mail.gmail.com> <CALx6S34AyV9OpvnjQhQc56n5vfeVgU5Zd3kheP0g+XvsMbBV9g@mail.gmail.com> <1b2e318e-1a9f-bb5d-75a5-04444c42ef20@si6networks.com> <CALx6S37TJr++fC=pVoeS=mrO1fHc4gL_Wtu-XkVTswzs2XxXCA@mail.gmail.com> <9352bb4d-f4d9-ebc6-34f9-dcb2f3ec24f1@si6networks.com>
To: 6man WG <ipv6@ietf.org>
In-Reply-To: <9352bb4d-f4d9-ebc6-34f9-dcb2f3ec24f1@si6networks.com>
Message-Id: <312A771E-9E5B-4E33-926F-EDF46C4CB925@employees.org>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Lx3uL2RKVYKq9umcVpQ1alX38DU>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 12 Jan 2019 09:49:02 -0000

Fernando said:
> I agree with the above (please see the ref I posted to RFC6274, which
> basically argues about this). HOowever, it is still not clear to me
> what's the problem you are addressing by enforcing a minimum fragment
> size. If you allow MIN_MTU/2, then you require first frags to be 640
> bytes.. and teh attacker is required to send 640 as opposed to 60 bytes
> or  so. Doesn't seem to be much of a difference to me.
> And as noted by Bob, I still don't see what's the big deal with the
> small fragments.
> 
> There are some DoS attacks where you send a last frag and possibly a
> first frag, and the implementation allocates a buffer that would fit the
> rest of the missing fragments -- obviously exacerbating the problem a
> bit. BUt still i this cases, the size of the first frag is not a big deal.

In e.g. VPP limiting fragment size would not help at all.
The scarce resource is number of available buffers. One fragment occupies at least one buffer regardless of how much smaller than 2K (default buffer size) it is.

Mitigations against attack is highly likely to be implementation specific.
As an example see:
https://github.com/FDio/vpp/blob/master/src/vnet/ip/ip6_reassembly.c

Default reassembly timeout is 100ms (constrasting that with the RFC 60s)
Maximum consequtive reassemblies in progress is limited to 1024.
And in other virtual reassembly algorithms we have also limited maximum allowed number of fragments in chain to 5.

Now, if we in the IETF think we can provide some guidance here, I will second Erik’s suggestion of getting more research.

The packet traces I have looked at in the past, the majority of fragmeted packets looked like attacks. UDP port 80, DNS queries to “thisdomainnamewillgiveaverylongresponsepurelyforthepurposeofattack.org”,
didn’t reassemble, 64K size… But it would be interesting to understand fragmentation behaviour in various parts of the network.

- how long are fragment chains (both in packets and in time span)
- ratio of out of order fragments
- which applications use fragments
- ratio of attack traffic using fragments
- average/min/maximum sizes, same for numbers of fragments in chain
- ratio of complete fragment chain following the same path in the network
- ratio of fragments to total traffic

Cheers,
Ole