IETF Logo Mail Archive

Re: Non-Last Small IPv6 Fragments

Erik Kline <ek@loon.co> Thu, 10 January 2019 22:20 UTC

Return-Path: <ek@google.com>
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 877611312A2 for <ipv6@ietfa.amsl.com>; Thu, 10 Jan 2019 14:20:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.499
X-Spam-Level:
X-Spam-Status: No, score=-9.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=loon.co
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 MOdZkV2z8twx for <ipv6@ietfa.amsl.com>; Thu, 10 Jan 2019 14:20:16 -0800 (PST)
Received: from mail-it1-x135.google.com (mail-it1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F5AE13129C for <ipv6@ietf.org>; Thu, 10 Jan 2019 14:20:16 -0800 (PST)
Received: by mail-it1-x135.google.com with SMTP id c9so945104itj.1 for <ipv6@ietf.org>; Thu, 10 Jan 2019 14:20:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=loon.co; s=google; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=A872+xGTkNg3LzDBp/GlcOhk8rYJF0TfqMB9qNxM5PE=; b=l5sBFel/zs3n8rQ4yfYSnDLtfAuyaYjbdNI6/YOLxonaeJIegxuwvOdFThDVk9sJzX MefJldymEI3aR6qdumpVMu5/NrBr9QaZ4qUdAWuVyvlFASsB8ktnnVO37a3n6EdZOSdU sBsJ3YC9lkRVrkKmWVMhCbaJWrlUTOvngK0iM=
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:reply-to :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=A872+xGTkNg3LzDBp/GlcOhk8rYJF0TfqMB9qNxM5PE=; b=c94U1kWiCmbQvSYpwE+JmAMgaZomYS8ctWpdUCprmO/7v/RdMtKGsat27V8VOhQIxh KQpdSRGAY5+FqbxpSfgLNhxpPMKgls3NTyADZD+SCy5n0U7jstkLiNBX0OAANLgXI+Vw aFg02RqFljqk4XuPBk1YOj24/E+f6xUBRJWKJS802YFFmNEf4mVO8R8nFNzV9m43JCCh yZIkJE6zMaBmYqaJ2dhm+4VmM77pFt14Ep88OrXVj+qQQ0ZYcmRNnaKoSUT15s0qjxwV yOwa2kfXOA21SoQyV+RBUJz5PHltfVblxpl3SyiVuM3Tp0/df5fOVeK4zAN7Q1Ks4rfu uTLA==
X-Gm-Message-State: AJcUukcGYd5kqbgLn4H4GCBXLLjcDeVBvk4sOr1WkgBJCvCm1SqxLWeo GiIhrB9jM2x3FVedS4sLeI8OZ/sQaVEfNxxLB0Fe678V0m8=
X-Google-Smtp-Source: ALg8bN6xAYIUkTLS0QXdOoS5Ivphkx1m5vIIaHeDshFeqXjLS85esSPYl214Qc0xaT5qFhR/AxfLLxAFX+GUSeRsHak=
X-Received: by 2002:a02:8943:: with SMTP id u3mr8192079jaj.92.1547158815212; Thu, 10 Jan 2019 14:20:15 -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> <CALx6S35QkKhRFVV+FE0Cnb-CrNHTj96QqQGNsHqrxjQYV5qB0Q@mail.gmail.com> <0F7E883A-E31B-476F-A01B-4362F09ECAA1@thehobsons.co.uk> <CAAedzxqUAG=1CcQ1YL1tc35Ji6=yDga90Kq+WmjEwAkKZXYHaQ@mail.gmail.com> <1BFDFCDC-9165-4172-BACE-C3EAAE45827B@isc.org>
In-Reply-To: <1BFDFCDC-9165-4172-BACE-C3EAAE45827B@isc.org>
Reply-To: ek@loon.co
From: Erik Kline <ek@loon.co>
Date: Thu, 10 Jan 2019 14:20:03 -0800
Message-ID: <CAAedzxpSnbZpxnR+0L+kjVBtoEdOk9s5yrm0iMbjycNrxA+eFA@mail.gmail.com>
Subject: Re: Non-Last Small IPv6 Fragments
To: Mark Andrews <marka@isc.org>
Cc: Simon Hobson <linux@thehobsons.co.uk>, IPv6 List <ipv6@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Te-zOx9s2NSoDdA5CY8eneQMXuU>
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: Thu, 10 Jan 2019 22:20:25 -0000

On Thu, 10 Jan 2019 at 13:58, Mark Andrews <marka@isc.org> wrote:
>
>
>
> > On 11 Jan 2019, at 8:44 am, Erik Kline <ek@loon.co> wrote:
> >
> > On Thu, 10 Jan 2019 at 13:39, Simon Hobson <linux@thehobsons.co.uk> wrote:
> >>
> >> Tom Herbert <tom@herbertland.com> wrote:
> >>
> >>> That might be reasonable, however requiring intermediate fragments to
> >>> be at least 1280 MTU in IPv6 also solves that without needing to
> >>> define some aritrary new limit.
> >>
> >> In setting a minimum payload size for a fragment, is there a risk of conflicting with some known, or future unknown, link type with a small MTU ?
> >
> > Technically that link wouldn't meet the 1280 min mtu requirement for
> > IPv6, right?
> >
> > Even with 1280 byte min fragment sizes, a reassembly engine still
> > probably needs to place some limits in practice on the resources it
> > will devote to reassembly.  An attacker and sent 1280-sized fragments
> > for an endless series of 65535-sized datagrams…
>
> approximate packet counts.
>
> 65535/1280
> 51
>
> 65535/1500
> 43
>
> or even
>
> 65535/640
> 102
>
> but a IPv6 node doesn’t have to support reassembly up to 65535
>
> If you are worried about too many fragments, count and limit the fragments
> not the fragment size.  If you get too many fragments for a packet just
> discard them all.

I don't yet see the need to limit the fragment size (but perhaps some
persuasive argument will emerge).

What I was trying to describe was: take all of those numbers you
reference per 32bit fragment ID.

An attacker could forge the source address and send 50 of the 51
packets for each of 4 billion fragment IDs.  The missing fragment
could even be the one with the L4 header too (to try to circumvent L4
ACLs that might cause the rest of the fragments to be dropped).

I think reassembly implementations may well want to manage several
resources, including: the total number of fragments, the lifetime of
the fragments, and possibly the total reassembled size (based on
expected legitimate traffic patterns).

v2.23.0 | Report a Bug | By Email