Re: Is Fragmentation at IP layer even needed ?

Warren Kumari <warren@kumari.net> Fri, 12 February 2016 19:11 UTC

Return-Path: <warren@kumari.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A61B1A88B6 for <ietf@ietfa.amsl.com>; Fri, 12 Feb 2016 11:11:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 KZ1TPxy8o1ER for <ietf@ietfa.amsl.com>; Fri, 12 Feb 2016 11:11:04 -0800 (PST)
Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (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 7F29F1A01D5 for <ietf@ietf.org>; Fri, 12 Feb 2016 11:11:04 -0800 (PST)
Received: by mail-yw0-x229.google.com with SMTP id q190so72161390ywd.3 for <ietf@ietf.org>; Fri, 12 Feb 2016 11:11:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=7vuGvidWahqjmw2V6v8T/PiCNXB3DEcuVtyhUO6dQ7I=; b=fkzwrrbZL69x9HWrZMug/DjDm+kbttvMiN2ifWXiJT/FJjQgAMzny3SXf+hGnupRmQ cpUEPLXIUrBiViHG/vWex2HtAZ5gS/MN2aQ4DaiBlsxq2JbeIo5k3rJAOateKEHb1WnD F4yKYu7r8FWnK7O3bHH3UJWsiugCPU/KCq1R0d+M+dF8IdEEumScrB1lCU13TvlPfm5i 2VXwaOCj74CE1yVyuECK392zKEWJJqskA+YlLpoF22Xi+s5WPjPE6cEtg5kjLGnSFvfO 2+s1u6/Ck+7etiFcw6yXtaUwb5zE+fVxsiWiNmrjkC3GK3Ap/6WRPDaADpKSQ3yiQf2G 9cNg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; bh=7vuGvidWahqjmw2V6v8T/PiCNXB3DEcuVtyhUO6dQ7I=; b=KlvXkY/aNIj5e7POw7thxVKy+BXL/nYcNVSVau7iZMO+R8v6i1dwQUMjwNq0OTQr7U fsYH5t1qMfq9IVSUwR9BgUbpi/plRv0hXcfFbKdPWqPaHak7eO/iLFumtLIBfmfBEYcz neJ2UN9HSpl/apdNAU41wd17JvPsyKp62F/KaO/KlgY9FCjdUyAvveg78Bs3GQxSvNtE hacf44gYBJ/dNLE7KEg50OzRONpTbnpn05HklR0xEWNnZLmh8lLdjzdmDOaS905U+3Fu 6A4j9j/IbW4nb2GYA/4WVwU/tkniiPASTX56hM+ud75HYGZ1lzZZwFSYv6JKhr+gcghF qwfA==
X-Gm-Message-State: AG10YORikMwuAR60yDEyJGxNB3ZHlXLvMYxkm8cvxGtev+KGcY23GMdbGmOXcBJDTBZKNBdede+xIxbBLWNF9vJW
X-Received: by 10.129.70.8 with SMTP id t8mr1974742ywa.105.1455304263714; Fri, 12 Feb 2016 11:11:03 -0800 (PST)
MIME-Version: 1.0
References: <CAOJ6w=EvzE3dM4Y2mFFR=9YyPBdmFu_jkF4-42LjkdbRd3yz_w@mail.gmail.com> <BLUPR05MB1985F5F2BB3118362C67B921AED50@BLUPR05MB1985.namprd05.prod.outlook.com> <20160208200943.A615941B5B96@rock.dv.isc.org> <CAMm+LwgLoYpQ1TNOTOuJzh+cu+GyRBf9=y_K7K35boQ9WcZKjA@mail.gmail.com> <56B92A96.9050200@si6networks.com> <CAMm+LwifTXvVd1mPZOfcOOR03Fnj-82H9aDVS01=wGezePtnXw@mail.gmail.com> <56BA4BC7.1010002@isi.edu> <CAMm+Lwi-n=be4AWGibs+Zq9egYw5pSDmPGb-4P0LDEcX1E6osA@mail.gmail.com> <56BA68CE.7090304@isi.edu> <CAMm+LwiM2sFUeejgJZe650UQbVHrh7EHrEF2omvPrZJPodgJLA@mail.gmail.com> <56BA739D.7060309@isi.edu> <CAMm+Lwij1dOkK0b2ZnJiPMtba=wc823WgYjqw0iwAApa3KBYcg@mail.gmail.com> <56BA95C7.8060109@isi.edu> <56BAD6CC.2030209@necom830.hpcl.titech.ac.jp> <56BBAAF7.6020903@isi.edu> <56BC9516.6050305@necom830.hpcl.titech.ac.jp> <56BCCBB4.4050909@isi.edu> <56BCF514.6040401@necom830.hpcl.titech.ac.jp> <56BE23F0.4090403@isi.edu>
In-Reply-To: <56BE23F0.4090403@isi.edu>
From: Warren Kumari <warren@kumari.net>
Date: Fri, 12 Feb 2016 19:10:54 +0000
Message-ID: <CAHw9_i+gjL=Wq8M8y3aiu9gqLPnzVD_jG-zct7ZMDvWm=Umb7w@mail.gmail.com>
Subject: Re: Is Fragmentation at IP layer even needed ?
To: Joe Touch <touch@isi.edu>, Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>, ietf@ietf.org
Content-Type: multipart/alternative; boundary="001a114d71a8adfc88052b976d37"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/h5N1uA_SS1WA48Fydiwtp0fO4-w>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Feb 2016 19:11:06 -0000

On Fri, Feb 12, 2016 at 1:27 PM Joe Touch <touch@isi.edu> wrote:

>
>
> On 2/11/2016 12:54 PM, Masataka Ohta wrote:
> > Joe Touch wrote:
> ...
> >> So yes, a firewall that inspects L4 or encap/decaps either needs to
> >> reassemble fragments or act like that's what's happening (e.g., to
> >> retain a copy of the first fragment of a set to direct later fragments
> >> within that set).
> >
> > Remember, with IPv6, the firewall can't fragment the reassembled
> > packets.
>
> Routers shouldn't reassemble, but then routers aren't supposed to look
> beyond L3. You cannot have it both ways.
>

You keep saying that.... and then a bunch of operators say "Yeah, but I
have an actual network to run, and I need to look beyond L3 because my
customers want me to mitigate their DoS, I want to filter on L4 before
handing data to internal services, and I use ECMP and need L4 because I
cannot rely on flow labels".


>
> Once you inspect L4, you *are* acting as a host.
>
>
So, this entire thread (which has reminded me why I stopped participating
in v6ops) is just a terminology issue? ;-)
Actually, I've just noticed that this thread is actually on ietf@ --
perhaps it should be moved to v6ops?


> As Mark pointed out, you don't need to strictly reassemble (i.e., to
> emit a corresponding reassembled packet). You just need to reassemble
> the information.
>

Which requires keeping state, yes? This is not realistic in modern large
network devices.
Saying "vendors should jolly well do a better job and redesign their gear
so that it can, and operators should simply pay whatever the cost is... oh,
and redesign their networks for flow consistency, because *that's what the
specifications require*" is likely to continue having people say "Yeah,
sure, whatever. But I've got a real network to run...."


>
> > So, no, unless the firewall output reassembled packets,
> > which may be larger than MTU of an outgoing link, it is not "act
> > like that's what's happening".
>
> As Fred pointed out, existing devices already emulate reassembly without
> emmitting the reassembled result.
>
> --
>
> Remember too, that if the firewall is "translating" the headers it ends
> up completely acting as a host - because it sources IP packets with its
> own IP addresses. In that case, it can apply source fragmentation.
>
> Yes - this also means that a firewall that changes headers needs to
> assign new, unique ID values for any fragmented packets too.  And it
> needs to act as a terminus for ICMP PTB errors to adjust its
> fragmentation size.

Again, the model leads you to the correct conclusions.
>

... and yet we see lots of evidence that fragments (and EH) have issues in
real world testing.

W


>
> Joe
>
>