Re: Non-Last Small IPv6 Fragments

Ole Troan <otroan@employees.org> Fri, 11 January 2019 14:40 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 134E41228B7 for <ipv6@ietfa.amsl.com>; Fri, 11 Jan 2019 06:40:16 -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 ImShrKBbvHsl for <ipv6@ietfa.amsl.com>; Fri, 11 Jan 2019 06:40:14 -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 8C16A12426E for <ipv6@ietf.org>; Fri, 11 Jan 2019 06:40:14 -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 1BBB2FECBBF7; Fri, 11 Jan 2019 14:40:14 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 17993C67B7E; Fri, 11 Jan 2019 15:40:12 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Subject: Re: Non-Last Small IPv6 Fragments
From: Ole Troan <otroan@employees.org>
In-Reply-To: <0e0c3141-889e-ff60-2787-2889b3a9af6b@si6networks.com>
Date: Fri, 11 Jan 2019 15:40:11 +0100
Cc: Timothy Winters <twinters@iol.unh.edu>, "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>, 6man WG <ipv6@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A9497CD3-67BD-47A8-9FE9-88F3672158C7@employees.org>
References: <CAOSSMjV0Vazum5OKztWhAhJrjLjXc5w5YGxdzHgbzi7YVSk7rg@mail.gmail.com> <2AB3F16C-FC0E-4EF7-B1ED-1A97F2CEC69B@gmail.com> <BYAPR05MB42458F851962F26AE1E15CC4AE840@BYAPR05MB4245.namprd05.prod.outlook.com> <CAAedzxofmhokstWuq7mRWnd5PTz5WQaiDNnE8O_VHXF_PbK6nw@mail.gmail.com> <BYAPR05MB4245388FB800873A5A8ED12AAE840@BYAPR05MB4245.namprd05.prod.outlook.com> <66bf652a-2bc0-6814-6ded-a63eece7fbe2@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>
To: Fernando Gont <fgont@si6networks.com>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/1uJgY3sqvlpnnL0by6onOibC1_s>
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: Fri, 11 Jan 2019 14:40:16 -0000

>> As Tom mentioned he has started a discussion on the Linux Network list
>> about FragmentSmack.  I'll report back if they have a more elegant
>> solution to the problem.
>> 
>> This is the best write-up I've found discussing the issue.
>> 
>> https://access.redhat.com/articles/3553061
>> 
>> Based on the general comments on list and reading about this attack I'm
>> going to create a draft to give some guidance to implementors for this
>> attack.
> 
> Guidance: whenever there is some data structure that could potentially
> grow without bounds, or a resource that consumed until it is exhausted,
> and that would affect the system or the communications in which the
> system is directly or indirectly involved, enforce limits and try to
> avoid fair use of such resource. Otherwise, we will keep disvovering the
> same kind of vulnerabiities we have discovered during the last 30 years
> or so.
> 
> :-)
> 
> IP fragmention is no special.

That’s not quite true. IP reassembly is made an easy target because it forces the receiver to complete reassembly before it can determine that the complete packet was unwanted.
Isn’t there a reason we see many IP reassembly attacks and not TCP segmentation attacks?
(And that we encourage deprecation of fragmentation at the network layer).

Cheers,
Ole