Re: Non-Last Small IPv6 Fragments

Ole Troan <otroan@employees.org> Sat, 12 January 2019 19:45 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 85EB9130FF8 for <ipv6@ietfa.amsl.com>; Sat, 12 Jan 2019 11:45:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 sC4v-TXqOCnb for <ipv6@ietfa.amsl.com>; Sat, 12 Jan 2019 11:45:14 -0800 (PST)
Received: from bugle.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E99D130FF9 for <ipv6@ietf.org>; Sat, 12 Jan 2019 11:45:14 -0800 (PST)
Received: from [192.168.10.191] (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 CD4F0FECBF3D; Sat, 12 Jan 2019 19:45:12 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
Subject: Re: Non-Last Small IPv6 Fragments
From: Ole Troan <otroan@employees.org>
X-Mailer: iPhone Mail (16C101)
In-Reply-To: <CALx6S34YbBe8xBod3VsWVO33TpZcdxh2uV1vaO8Z_NKnVXp66g@mail.gmail.com>
Date: Sat, 12 Jan 2019 20:45:09 +0100
Cc: 6man WG <ipv6@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A3C3F9C0-0A07-41AF-9671-B9E486CB8246@employees.org>
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> <312A771E-9E5B-4E33-926F-EDF46C4CB925@employe es.org> <CALx6S36V7vrVyoTP0G6+S5XeFNB3KWS5UaNnVi20xogRERdCfg@mail.gmail.com> <973A1649-55F6-4D97-A97F-CEF555A4D397@employees.org> <CALx6S34YbBe8xBod3VsWVO33TpZcdxh2uV1vaO8Z_NKnVXp66g@mail.gmail.com>
To: Tom Herbert <tom@herbertland.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/JuBqteyB2v0ljkpk_VWhoU7Yfrs>
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 19:45:17 -0000

Tom,

> On 12 Jan 2019, at 20:27, Tom Herbert <tom@herbertland.com> wrote:
> 
>> On Sat, Jan 12, 2019 at 10:50 AM Ole Troan <otroan@employees.org> wrote:
>> 
>> 
>> 
>>>> On 12 Jan 2019, at 18:17, Tom Herbert <tom@herbertland.com> wrote:
>>>> 
>>>> On Sat, Jan 12, 2019 at 1:49 AM Ole Troan <otroan@employees.org> wrote:
>>>> 
>>>> 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.
>>>> 
>>> Ole,
>>> 
>>> I don't know what the protocol requirements are for virtual
>>> reassembly. Is there an I-D or RFC on this?
>> 
>> Virtual reassembly is just an optimization. The protocol requirements are the same.
>> 
> The same as what requirements? RFC8200 defines how reassembly occurs
> at a destination (the addressed node), not how an intermediate node in
> the network reassembles packets. It is not the same thing. For
> instance, there is an additional implicit requirement in virtual
> reassembly that all fragments are routed through the same node. Also,
> Hop-by-Hop options and Destination options can precede the fragment
> header, so is the requirement that same that nodes MUST process these
> before the fragmentation header is processed?
> 
> If virtual reassembly is brought up in the context of standard
> protocol discussion, it would really be nice to have a normative
> desciption of that protocol mechanism.

The code example I gave was for host reassembly.
I didn’t intend with my comment any more than that this is quite implementation specific, that it’s not obvious that the IETF can provide anything useful here, apart from removing network layer fragmentation, and I was absolutely not suggesting we should have a document on in-network reassembly. 

Cheers 
Ole
> 
> Tom
> 
>> Cheers
>> Ole
>> 
>> 
>>> 
>>> Thanks,
>>> Tom
>>> 
>>>> 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
>>>> 
>>>> 
>>>> 
>>>> 
>>>> --------------------------------------------------------------------
>>>> IETF IPv6 working group mailing list
>>>> ipv6@ietf.org
>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>> --------------------------------------------------------------------
>>