Re: Is Fragmentation at IP layer even needed ?

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Wed, 10 February 2016 07:50 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 4F92B1B37F5 for <ietf@ietfa.amsl.com>; Tue, 9 Feb 2016 23:50:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.608
X-Spam-Level:
X-Spam-Status: No, score=0.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RP_MATCHES_RCVD=-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 GVTb4GBAlMEJ for <ietf@ietfa.amsl.com>; Tue, 9 Feb 2016 23:50:36 -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 58F011B37F9 for <ietf@ietf.org>; Tue, 9 Feb 2016 23:50:36 -0800 (PST)
Received: (qmail 21854 invoked from network); 10 Feb 2016 07:31:20 -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; 10 Feb 2016 07:31:20 -0000
Subject: Re: Is Fragmentation at IP layer even needed ?
To: Fernando Gont <fgont@si6networks.com>, 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> <56BAD346.6090601@necom830.hpcl.titech.ac.jp> <56BAE126.5050302@si6networks.com>
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-ID: <56BAEBC6.3050003@necom830.hpcl.titech.ac.jp>
Date: Wed, 10 Feb 2016 16:50:30 +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: <56BAE126.5050302@si6networks.com>
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/8SOEBXK1jB81mZZ55zCvMbFqV_g>
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: Wed, 10 Feb 2016 07:50:40 -0000

Fernando Gont wrote:

> Hi, Masataka,

Hi,

>> The reality is that wise operators denied deployment of
>> stupid idea of extension headers including that for IP
>> reassembly.

>> Wrong. The worst kind of obscurity is a transport header at
>> the end of a chain of 1000 or more IPv6 extension headers.
>>
>> Note that the transport header may not be placed in the
>> first fragment.

> RFC7112 imposes some basic constraints: the entire EH chain must be
> present in the first fragment.

Thank you for the information. But, I'm afraid the fix is too late
and too insufficient to change the reality above. That is, my point
on DOS is still valid and, worse, some combination of extension
headers may results in yet unnoticed vulnerability, which is
partially why allowing extension headers is a stupid thing to do.

Moreover, the rfc should also limit header chain length below
256B or so. Though DNS message over UDP over IPv4, with 576B
reassembly buffer, can be 508B (in practice, 548B) long, DNS
message over UDP over IPv6, with 1280B reassembly buffer,
can be less than 100B, if header chain is lengthy.

Worse, though the rfc require an entire upper layer header
included in the first fragment, the requirement is too much.

According to rfc792, the first 8B should be enough. As for
ICMPv6, ICMPv6 should also be required to contain all the
header chain up to the first 8B of an upper layer header.

						Masataka Ohta