Re: [tsvwg] UDP options and header-data split (zero copy)

Michael Tuexen <michael.tuexen@lurchi.franken.de> Sun, 01 August 2021 22:22 UTC

Return-Path: <michael.tuexen@lurchi.franken.de>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2E5E3A15BB for <tsvwg@ietfa.amsl.com>; Sun, 1 Aug 2021 15:22:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.489
X-Spam-Level:
X-Spam-Status: No, score=-1.489 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_NONE=0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 sYGkDzB3ZMMH for <tsvwg@ietfa.amsl.com>; Sun, 1 Aug 2021 15:22:18 -0700 (PDT)
Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 276073A15A8 for <tsvwg@ietf.org>; Sun, 1 Aug 2021 15:22:17 -0700 (PDT)
Received: from smtpclient.apple (ip1f100e9c.dynamic.kabel-deutschland.de [31.16.14.156]) (Authenticated sender: lurchi) by mail-n.franken.de (Postfix) with ESMTPSA id 7FE8D721E2807; Mon, 2 Aug 2021 00:22:10 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Michael Tuexen <michael.tuexen@lurchi.franken.de>
In-Reply-To: <04C250F8-7C10-4300-862B-7FFD739CA8B3@strayalpha.com>
Date: Mon, 02 Aug 2021 00:22:09 +0200
Cc: Tom Herbert <tom@herbertland.com>, tsvwg <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <C65F0BB6-BA2D-49F3-A473-32EEDF6C9467@lurchi.franken.de>
References: <058C1360-D1BF-4C15-A0E3-D1C98DC8C45F@lurchi.franken.de> <04C250F8-7C10-4300-862B-7FFD739CA8B3@strayalpha.com>
To: Joe Touch <touch@strayalpha.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/CeogxNT7Fn--tAkBoH4VRswLiL0>
Subject: Re: [tsvwg] UDP options and header-data split (zero copy)
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 01 Aug 2021 22:22:32 -0000

> On 2. Aug 2021, at 00:14, Joe Touch <touch@strayalpha.com> wrote:
> 
> Right, but for UDP the receive MTU is the one we care about. 
Ahh, OK.

Best regards
Michael
> 
> Joe 
> 
>> On Aug 1, 2021, at 3:05 PM, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:
>> 
>> 
>>> 
>>> On 1. Aug 2021, at 23:43, Tom Herbert <tom@herbertland.com> wrote:
>>> 
>>>> On Sun, Aug 1, 2021 at 2:24 PM Joseph Touch <touch@strayalpha.com> wrote:
>>>> 
>>>> 
>>>> 
>>>>> On Aug 1, 2021, at 2:19 PM, Tom Herbert <tom@herbertland.com> wrote:
>>>> 
>>>> 
>>>> 
>>>> On Sun, Aug 1, 2021, 12:42 PM Joseph Touch <touch@strayalpha.com> wrote:
>>>>> 
>>>>> 
>>>>> ...
>>>>> Had we limited the option length as a few suggested when this work started, we would not have FRAG.
>>>>> 
>>>>> We don’t know what others are, but we also don’t know that the first frag will have hundreds of bytes of available space either.
>>>> 
>>>> 
>>>> Actually, we do know that. The minimum MTU in IPv6 is 1280 and the minimum MTU for IPv4 is 576.
>>>> 
>>>> 
>>>> The min MTU for IPv4 is 68..
>>> 
>>> Per RFC791 it's 576 bytes.
>> RFC 791 makes a requirement on the receiver, not on the links.
>> 
>> Page 25 of RFC 791 reads:
>> 
>>   Every internet module must be able to forward a datagram of 68
>>   octets without further fragmentation.  This is because an internet
>>   header may be up to 60 octets, and the minimum fragment is 8 octets.
>> 
>> Therefore, the min MTU for IPv4 is 68.
>> 
>> Best regards
>> Michael
>>> 
>>>> 
>>>> If someone we're so inclined they could fill up the first fragment packet with nothing but options and start the payload in the second. That means you'll have at least 520 bytes for options.
>>>> 
>>>> 
>>>> That includes BOTH per-fragment and per-reassembled datagram options.
>>>> 
>>>> But all this is academic since there's no use case other than DoS attack that would need anything close to that much space.
>>>> 
>>>> 
>>>> That was true until FRAG too.
>>>> 
>>>> Again, this is a new decision - to limit the option space.
>>> 
>>> I don't know what that means.
>>> 
>>>> 
>>>> Joe
>>> 
>> 
>