Re: Non-Last Small IPv6 Fragments

David Farmer <farmer@umn.edu> Fri, 11 January 2019 21:13 UTC

Return-Path: <farmer@umn.edu>
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 41D8C12008A for <ipv6@ietfa.amsl.com>; Fri, 11 Jan 2019 13:13:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu
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 M6eGJiy9-vaN for <ipv6@ietfa.amsl.com>; Fri, 11 Jan 2019 13:13:26 -0800 (PST)
Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EE95128B14 for <ipv6@ietf.org>; Fri, 11 Jan 2019 13:13:26 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id 6B512D99 for <ipv6@ietf.org>; Fri, 11 Jan 2019 21:13:25 +0000 (UTC)
X-Virus-Scanned: amavisd-new at umn.edu
Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WbzlNUyBqT_M for <ipv6@ietf.org>; Fri, 11 Jan 2019 15:13:25 -0600 (CST)
Received: from mail-vk1-f198.google.com (mail-vk1-f198.google.com [209.85.221.198]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id 185F5D94 for <ipv6@ietf.org>; Fri, 11 Jan 2019 15:13:24 -0600 (CST)
Received: by mail-vk1-f198.google.com with SMTP id l125so3294560vkb.22 for <ipv6@ietf.org>; Fri, 11 Jan 2019 13:13:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Pa0PNlh3XNszIVnTJoBeU4NIjbJYcl7BDZ9Q1/4NA8Y=; b=D8RNgFxjjDpzczbnV5xpDE27QhahraxbP5iqu4ufkD0mNhw33f/sX1Cw9DOah9+Td8 qUse7nY+UNjBrGQKV0b1FCBIgW2hz6aFHA5U1vHLLm3hpyo7pUVYP4tsC5CRIbX0PLvj 18FBTe+J9eF1HXSLikFUnWBQn93DzSNS9NQKR5szYZinS/fOM8eQ20msr4cQmapan0Ri uD8xFu0ZV/vsSdRF54+Tvdecyc0BRxdiUSHM/H/KEBiLPfFwLfQ7MTdD5Hm+/tBq5AMX erKj1cpRWTWawiJBvcLkrsga4D2kIo75Sn+3vnChHO0N7ZpTIfYhz9dDs7yDB9bRI+xC VS3w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Pa0PNlh3XNszIVnTJoBeU4NIjbJYcl7BDZ9Q1/4NA8Y=; b=jKv/7gxYCzc/Qy3QuxDxYLFFtDPbCvauNO4AaKW9CUj2PVArMy/dPlnHwVGbFJeO+W p8kTAhfg5c/EnVtNBIyBzUmOObMK/fjk+6T2+1Z5XhhJWT+Ms0CSXxq9LpNHOkPxzlCz Roqx06+59txP+CjHJyFF3LBGMWaZCiwfvSDibpofGX0eWoEB3SyeRzo6MRCOoKsdZSQa TajEt63Q62MEGfAZv8wzqU1/GGszRtg9tsUl6AvUArMc/9PZ9d9eg82nYDOfdT9nNjHp RJ31KsyO/IyjPZsiu9qDvvoimoSqW8aMEzqGyPY/7X4mAZpYhOkFCq4YMVDjueZgO8p3 Rneg==
X-Gm-Message-State: AJcUukeN8wYj3XvcEBLgQw5mqo4JF22E7GgiesgfXju+8yLKGfA6cxYk Kgsi4JnFWbwx6xWT4kuerxw7uyoGfYEFchDQWvig4XQgmUtl3d4eQ1ks7/hEBQNxLnuv310ijKH 9jGNViROwzdCuNkZtnVrrj3fA
X-Received: by 2002:a67:ff02:: with SMTP id v2mr6609983vsp.176.1547241204117; Fri, 11 Jan 2019 13:13:24 -0800 (PST)
X-Google-Smtp-Source: ALg8bN5TvlHPAtuSDqhfZLOG2SthfT5Q22kNa4ugAnLvyd1yzjDLNXT8LVVCDJ3Q1r4hI3x8Zgo0Nh9CHas82a9gq68=
X-Received: by 2002:a67:ff02:: with SMTP id v2mr6609966vsp.176.1547241203731; Fri, 11 Jan 2019 13:13:23 -0800 (PST)
MIME-Version: 1.0
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> <748DA428-5AB2-4487-A4FB-F2DABF5BF8BE@thehobsons.co.uk> <8b43af81-1c49-5cea-6472-97703674e661@si6networks.com>
In-Reply-To: <8b43af81-1c49-5cea-6472-97703674e661@si6networks.com>
From: David Farmer <farmer@umn.edu>
Date: Fri, 11 Jan 2019 15:13:06 -0600
Message-ID: <CAN-Dau1HwG5RndacpSA+si+zKuTdpSvA=QA1A11A==rMNe=4+w@mail.gmail.com>
Subject: Re: Non-Last Small IPv6 Fragments
To: Fernando Gont <fgont@si6networks.com>
Cc: Simon Hobson <linux@thehobsons.co.uk>, IPv6 List <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000054a442057f352ac2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/k9lpRd7ga5_3axQXbNAzGEV2Su0>
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 21:13:28 -0000

On Fri, Jan 11, 2019 at 1:58 PM Fernando Gont <fgont@si6networks.com> wrote:

> On 11/1/19 15:38, Simon Hobson wrote:
> > Fernando Gont <fgont@si6networks.com> wrote:
> >
> >> ... enforce limits ...
> >
> > The guidance also needs to suggest sensible limits - otherwise what one
> implementer (eg the Linux stack that discards any small fragment that isn't
> the last)
>
> IMO, this is bad behavior advice. As an attacker, I'd fire 1280-sized
> frags, and your check hasn't achieved anything.
>
>
> >may not interoperate with another (eg make the last two fragments
> approximately equal in size). In a significant part, that seems to
> > have been what this thread has been about - what is reasonable
> guidance for this.
>
> In general, what you do is AIMD (additive increase, multiplicative
> decrease). The numbers limits are a few thousand packets. Which allow
> fragments to work for some cases - few connections, rather low
> throughput, but will not allow system breakage when the attacker wants
> to play.
>
> Dropping small frags as in Linux is bad, because you hurt
> interoperability without any significant/real gain.
>
> OTOH, limiting the number of frags is good, because limits kick in at a
> point in which "you need to do something, because otherwise - DoS".
>
> Obviously, you cannot expect big pipes with fragmentation to work. Given
> high bandwith, multiply 60s * throughput, and you'll need a lot of
> memory to hold the frags.
>
> Adapting the Frag reassembly time out can also help -- there's not much
> of a point to keep a frag in memory for 60s, particularly when under
> heavly load. -- well before that TCP timers will fire, or the frag si
> not useful anymore, anyway.
>

I just had a thought for the guidance;

1. System-wide limit the number of fragments based on the overall system
resources available.
2. As you near said limit, maybe 75% of the limit, drop outright, or at a
high probability, non-final fragments smaller than (1280/2) 640 bytes.

The reasonable fragmentation algorithms I can think of do not generate
non-final fragments that are less than 640 bytes. Nevertheless, such
fragments SHOULD NOT be dropped except for when the system is under
stress.

What do others think?

-- 
===============================================
David Farmer               Email:farmer@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================