Re: Is Fragmentation at IP layer even needed ?

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Thu, 18 February 2016 08:28 UTC

Return-Path: <mohta@necom830.hpcl.titech.ac.jp>
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 F05531B32B3 for <ietf@ietfa.amsl.com>; Thu, 18 Feb 2016 00:28:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.603
X-Spam-Level:
X-Spam-Status: No, score=0.603 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RP_MATCHES_RCVD=-0.006] 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 bvKXUVJgboQA for <ietf@ietfa.amsl.com>; Thu, 18 Feb 2016 00:28:03 -0800 (PST)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 0BAB71B3130 for <ietf@ietf.org>; Thu, 18 Feb 2016 00:28:02 -0800 (PST)
Received: (qmail 63730 invoked from network); 18 Feb 2016 08:08:41 -0000
Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 18 Feb 2016 08:08:41 -0000
Subject: Re: Is Fragmentation at IP layer even needed ?
To: ietf@ietf.org
References: <CAOJ6w=EvzE3dM4Y2mFFR=9YyPBdmFu_jkF4-42LjkdbRd3yz_w@mail.gmail.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> <56BFD7B3.9080505@necom830.hpcl.titech.ac.jp> <56C14D50.4040802@isi.edu> <56C21C4B.50304@gmail.com> <56C42A84.1040207@necom830.hpcl.titech.ac.jp>
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-ID: <56C5808C.1090906@necom830.hpcl.titech.ac.jp>
Date: Thu, 18 Feb 2016 17:27:56 +0900
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <56C42A84.1040207@necom830.hpcl.titech.ac.jp>
Content-Type: text/plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/v55pddodK3_vMGkHV4Y5lgIjDw0>
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, 18 Feb 2016 08:28:12 -0000

Masataka Ohta (I) wrote:

> The RFC is a complete mess, in various ways. It says flow IDs are
> good because it is random, but, at the same time, it says flow
> IDs may not be random.

I found the rfc is even worse.

The most important thing the rfc must have stated (it
does not, of course) is:

	(SRC1, DST1, flow_ID1)

of a stateful flow MUST be unique (not used by packets
not belonging to the flow) within the Internet,
which can be guaranteed only by an end (source or
destination), which is a straight forward manifestation
of the end to end argument.

But, the rfc allow routers (firewalls) change flow IDs to
nonzero value.

So, if a router changes flow ID of (SRC1, DST1, flow_ID2),
from flow_ID2 to flow_ID3, then, there is a possibility
that flow_ID1==flow_ID3, which is fatal for the stateful
flow, if the modified packets are merged to the stateful
flow (certain protection against merging possible but
not robust against route changes).

Of course, section 6.1 of the rfc on covert channels is
abstract nonsense, because covert channels may be created
in various ways to carry information, for example, with
extension headers (fragmentation boundaries, for example,
can be arbitrary), which means firewalls should reject
packets with extension headers.

					Masataka Ohta