[tsvwg] draft-ietf-tsvwg-udp-options-13: Comments concerning Fragments
Gorry Fairhurst <gorry@erg.abdn.ac.uk> Tue, 31 August 2021 10:26 UTC
Return-Path: <gorry@erg.abdn.ac.uk>
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 87F513A3F24 for <tsvwg@ietfa.amsl.com>; Tue, 31 Aug 2021 03:26:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 Db2p8C8lomjg for <tsvwg@ietfa.amsl.com>; Tue, 31 Aug 2021 03:26:56 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 462DB3A3F1C for <tsvwg@ietf.org>; Tue, 31 Aug 2021 03:26:56 -0700 (PDT)
Received: from GF-MBP-2.lan (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 95C561B0022D; Tue, 31 Aug 2021 11:17:38 +0100 (BST)
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
To: "tsvwg@ietf.org" <tsvwg@ietf.org>
Cc: Joe Touch <touch@strayalpha.com>
Message-ID: <3e9a51f4-1520-b730-39a1-84fdda2cd881@erg.abdn.ac.uk>
Date: Tue, 31 Aug 2021 11:17:38 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/j7GSSosMKoIGTuv2i05B-A0dStA>
Subject: [tsvwg] draft-ietf-tsvwg-udp-options-13: Comments concerning Fragments
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: Tue, 31 Aug 2021 10:27:00 -0000
I have the following questions relating to the text about Fragments. Best wishes, Gorry (as an individual) === In section 5.3: Frag: “ Legacy receivers interpret FRAG messages as zero-length payload packets (i.e., UDP Length field is 8, the length of just the UDP header), which would not affect the receiver unless the presence of the packet itself were a signal.” - can you supply a reference here? (If no other then sect 5 of RFC8085). === Concerning Frag: “ This allows either pre-reassembly or post-reassembly UDP option effects.” - I think I understand a use case and it would be nice to have an example of using both per-fragment and per-datagram options: could this be used with fragments req/res options to determine a suitable PMTU, and the time options used per reassembled datagram (since in many case this needs to measure the time across the reassembled end-to-end datagram path). === Concerning Frag: >> UDP reassembly space limits SHOULD NOT be implemented as an aggregate, to avoid cross-socketpair DOS attacks. - Please explain “aggregate” (is this across multiple socket-pairs?) === Concerning Frag: Any additional UDP options, if used, follow the FRAG option in the final fragment and would be included in the reassembled packet. - I don’t like the word “additional” here, can you find a better word (per-datagram?) === In 5.7: Maximum Reassembled Segment Size (MRSS) - I’m going to make a suggestion here, that was earlier brought up by Tom Jones: Why don’t we fix the DEFAULT MRSS to 2 packets when MRSS is supported. Larger values might be supported, which would be fine, but the case of 2 might have some immediate benefit: - A receiver can then fragment a UDP packet to tunnel of include UDP options, likely in many current cases a second fragment will be enough. - A receiver can greatly simplify its processing if it tries to reassemble whenever it receives a second fragment of the same datagram. The simplification here mitigates some worry about attacks that target reassembly buffers or processing costs. He previously had not implemented fragment support because it was cumbersome to include in the OS he worked with. - Thoughts?
- [tsvwg] draft-ietf-tsvwg-udp-options-13: Comments… Gorry Fairhurst
- Re: [tsvwg] draft-ietf-tsvwg-udp-options-13: Comm… touch@strayalpha.com
- Re: [tsvwg] draft-ietf-tsvwg-udp-options-13: Comm… Gorry Fairhurst
- Re: [tsvwg] draft-ietf-tsvwg-udp-options-13: Comm… touch@strayalpha.com