Re: Is Fragmentation at IP layer even needed ?

Joe Touch <touch@isi.edu> Thu, 11 February 2016 17:58 UTC

Return-Path: <touch@isi.edu>
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 15E281B3833 for <ietf@ietfa.amsl.com>; Thu, 11 Feb 2016 09:58:30 -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, RP_MATCHES_RCVD=-0.001] autolearn=ham
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 FYQ7qD6tMM-I for <ietf@ietfa.amsl.com>; Thu, 11 Feb 2016 09:58:28 -0800 (PST)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A11251B386D for <ietf@ietf.org>; Thu, 11 Feb 2016 09:58:28 -0800 (PST)
Received: from [128.9.184.104] ([128.9.184.104]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u1BHwEYq025791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 11 Feb 2016 09:58:15 -0800 (PST)
Subject: Re: Is Fragmentation at IP layer even needed ?
To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>, ietf@ietf.org
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>
From: Joe Touch <touch@isi.edu>
X-Enigmail-Draft-Status: N1110
Message-ID: <56BCCBB4.4050909@isi.edu>
Date: Thu, 11 Feb 2016 09:58:12 -0800
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <56BC9516.6050305@necom830.hpcl.titech.ac.jp>
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-MailScanner-ID: u1BHwEYq025791
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/oVL0MmDKaUd4gOp7oG2HrjCuFiY>
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: Thu, 11 Feb 2016 17:58:30 -0000


On 2/11/2016 6:05 AM, Masataka Ohta wrote:
> Joe Touch wrote:
> 
>> I repeat: nodes that encap or decap are acting as sources or sinks, not
>> relays.
> 
> I'm afraid firewalls are relays.

A firewall that filters on L3 is a router regardless of which side you
look at.

A firewall that encaps/decapsulates is a host on the public side and a
router on the private side. A firewall that inspects beyond L3 is a host
as well, for similar reasons.

So the term "firewall" isn't the issue; it's the behavior that is.

>> Nodes such as NATs and firewalls act as end hosts on the public side and
>> routers on the private side. Which is why they need to obey RFC1122
>> semantics on the public side.
> 
> So, you think firewalls should reassemble fragments. Wow!

And yet that is exactly the correct conclusion regarding most behaviors
that firewalls perform that act like end hosts. Once you realize that
inspecting L4 or encaps/decaps is acting like a host, the requirements
become very clear - even if you don't like them.

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).

The model takes you to exactly the right conclusion.

Joe