Re: Non-Last Small IPv6 Fragments

Timothy Winters <twinters@iol.unh.edu> Fri, 11 January 2019 13:45 UTC

Return-Path: <twinters@iol.unh.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 93287124BAA for <ipv6@ietfa.amsl.com>; Fri, 11 Jan 2019 05:45:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iol.unh.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 GaqIstx4oCwC for <ipv6@ietfa.amsl.com>; Fri, 11 Jan 2019 05:45:00 -0800 (PST)
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 580561228B7 for <ipv6@ietf.org>; Fri, 11 Jan 2019 05:45:00 -0800 (PST)
Received: by mail-wr1-x429.google.com with SMTP id u4so15256103wrp.3 for <ipv6@ietf.org>; Fri, 11 Jan 2019 05:45:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bfB++1VedaaLdaSLpEBRLUscH4F0N5pcopQaJVNuoe0=; b=Qd1iE92kgLxFyD6cVWO62Fjh+ydGoo2IxfULb9b36DYmBxcKcRYS1sN9K5RCdIT48B o0Wkz0V3ePD0BAmsFA1pWdLfR9CW1aozMK2+TeGlQyvVdTNE4Jz4veMpvsGTOivl+vRG ci89djZZ0VGJIxDu5B8FsIjHBystgtGhrH9Mc=
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=bfB++1VedaaLdaSLpEBRLUscH4F0N5pcopQaJVNuoe0=; b=TMqDwhb7n82KnXG8h2QXfG6j7PFA+WP4pKIrtUKs/pRPRTLhRIiZpYMlW6k3KCcOBd p/YVoCzh2MJjkmxNO4p/p7pPnHPEfSt1b0cuthRHOb56vfMmiODTJQC1LRjm4AsbMd/l aZ1xUys6CkmQvAVkkzblRtWayosb/zofEoNDJvMiGODV4V0psi2XMJS30AOwJEjh3aY1 XlnCT1iBBtsuoi+xdGrRX3qrae51zHEkz4b2nea4gMAlRSTcOXjl85W4v937In5PtslL fCkOtE8OeqWidu/KXcwbSJhxdJu7dZtUzRwB1uaYOv0hPpXui9e9zn4RVUvnYzoRRxYU 0OJw==
X-Gm-Message-State: AJcUukd6RbK+8eVw4hn0IilUAuHALQ4K8s12S7UjhNgheDPoTwPLb+sz L7HajuKbTfJf7V7YqUfGhoFW5dcttZet/nQWSZk7LA==
X-Google-Smtp-Source: ALg8bN5zWgxuoIuG494fzlDmdr1ntnbdFe4+a1mC9baQ/eV+7NJLipjvil0/HbzoGsFoIuQfH69zAQKj/CTyN9Jo9V4=
X-Received: by 2002:adf:e407:: with SMTP id g7mr13051984wrm.277.1547214298636; Fri, 11 Jan 2019 05:44:58 -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>
In-Reply-To: <16A642DC-D3A4-452C-B7D1-20CA0EEEDDA2@lists.zabbadoz.net>
From: Timothy Winters <twinters@iol.unh.edu>
Date: Fri, 11 Jan 2019 08:44:47 -0500
Message-ID: <CAOSSMjWS9po2XuBHJ5hbN9hfNDKZ1diecH08Kt697-15jRtAvg@mail.gmail.com>
Subject: Re: Non-Last Small IPv6 Fragments
To: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, IPv6 List <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a98e32057f2ee624"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/rwuxxVx2dgOQVEHYTbFuPRLQTKI>
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 13:45:04 -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.

~Tim

On Fri, Jan 11, 2019 at 8:31 AM Bjoern A. Zeeb <
bzeeb-lists@lists.zabbadoz.net> wrote:

> On 11 Jan 2019, at 3:02, Brian E Carpenter wrote:
>
> Hi,
>
> > If an RFC7195 translator receives an IPv4 fragment, it will translate
> > it into an IPv6 fragment. So if the IPv4 fragment is "small" by some
> > definition, so is the IPv6 fragment.
> >
> > I think that's a legitimate route to non-last fragments shorter than
> > 1280, regardless of what is considered normal for IPv6.
>
> I think this topic has been re-hashed in the past often enough.
>
> I want us to stop thinking that there’s anything but IPv6 if we ever
> want fragments to be “clean” and sorted and usable and working.
> It’s a total waste of time to sort this out for a transition
> technology as it’d be a major change to IPv6 implementations and
> involving end nodes and translator nodes (*) and by that time that would
> have happened IPv4 is no longer relevant.
>
> Can we please start looking ahead to the decades of IPv6-only before we
> need to extend “real-time” communications to Mars and outside of our
> galaxy? (+)
>
>
> /bz
>
>
> (*) If you really wanted to you’d need a way to signal the min-MTU
> violation from the translator exception case to the end not and you’d
> probably need some kind of extension header for that.  Sadly this
> wasn’t done 20 years ago and neither for 8200.
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>