* Section 9.4: Should new codes be defined for ICMPv4 and ICMPv6 Time Exceeded messages to indicate UDP reassembly failures?

[Mike-Heard]

draft-ietf-tsvwg-udp-options-22 Section 9.4 included the following text:

UDP reassembly expiration MAY generate an ICMP error, but this MUST NOT use the existing IP reassembly timeout error type and code.

[TBD: ?? Should we define a new code for this purpose?]

The idea is to have something analogous to the Port Unreachable codes for the ICMPv4 and ICMPv6 Destination Unreachable messages. See https://mailarchive.ietf.org/arch/msg/tsvwg/CnPYSXjPPmLtNkBtjJ4BSgMX2Ck/

[Mike-Heard]

One question that arises: if an ICMP message is sent as a result of a reassembly timeout, what does the quoted packet look like? In the case of IP reassembly, it is basically a reconstituted version of the initial fragment, and an ICMP message can't be sent if the initial fragment is missing. UDP fragmentation is different in this respect. What needs to get back to the source are the IP and UDP headers for any fragment and the Identification value.

[gorryfair]

Or... do we silently drop reassembly timeouts to avoid reducing feedback (silently drop also avoids us needing to complete an analysis of the implications of triggering from invalid packets, e.g. whether this can be exploited for DDos)

[Mike-Heard]

Or... do we silently drop reassembly timeouts to avoid reducing feedback (silently drop also avoids us needing to complete an analysis of the implications of triggering from invalid packets, e.g. whether this can be exploited for DDos)

I would prefer to see that solution.

[jtouch]

As Mike noted, we don't need to have the first packet to send an ICMP error; we could generate it from any packet. The time-exceeded principle still exists - this is no more or less exploitable than IP-layer time-exceeded would be, and equally likely to be blocked. But it's a useful diagnostic tool and could be useful to the application layer (e.g., to either avoid UDP fragmentation or to possibly retransmit), so my preference is to define it and recommend that it SHOULD be rate limited.

NO CHANGES to -23 at this time until resolved further.

[gorryfair]

I agree any fragment could generate this. .. A notification can be returned to the process/transport protocol entity that originated it when the quoted packet in the ICMP message contains the UDP header that demultiplexes to the socket (or whatever way the process) that identifies the end-to-end flow. (In other cases, when the UDP Option area is appended to an existing datagram, the could be challenges in quoting enough payload to find the UDP Options.)

[gorryfair]

I'm still unclear how useful it would be to have am ICMPv4 and ICMPv6 Time Exceeded messages to indicate UDP reassembly failures?

[jtouch]

It's a bit like how it's useful to IP; it can be used by an upper layer protocol to change its application MTU.

[jtouch]

I agree any fragment could generate this. .. A notification can be returned to the process/transport protocol entity that originated it when the quoted packet in the ICMP message contains the UDP header that demultiplexes to the socket (or whatever way the process) that identifies the end-to-end flow. (In other cases, when the UDP Option area is appended to an existing datagram, the could be challenges in quoting enough payload to find the UDP Options.)

The info is in the FRAG header, which is intended to come as early as possible after OCS. So we should probably state that the ICMP response SHOULD include as much of the packet as possible, but MUST include at least the bytes through the FRAG option.

[gorryfair]

It's a bit like how it's useful to IP; it can be used by an upper layer protocol to change its application MTU. That seems a bit weird to me. Why doesn't the upper layer use an option to do that rather than ICMP?

[jtouch]

Because the upper layer never knows when frag failure occurs; for legacy reasons, we send empty datagrams up, but not the FRAG IDs.

[gorryfair]

I don't think this is a helpful way to organise things. Much better for the sender to do PLPMTUD to discover a size and use that for fragments, or to explicitly report a failure option at the UDP layer. Sending an ICMP message and hoping this is delivered, and then sent to the originating application seems weird.

[jtouch]

PLPMTUD won't tell you why or where it didn't work. ICMP is exactly for the diagnostics that would. It can be disabled by default, but provides a powerful tool to help implementers and operators. FWIW, it's no more weird IMO than any other ICMP - recall that there are ICMPs that tell you that a port isn't there too.

[Mike-Heard]

Like Gorry, I question the value of adding an ICMP message for a UDP reassembly timeout. There is also the practical issue of having to go to the intarea and/or 6man WGs to get consensus to extend ICMP in this way.

[jtouch]

I'm not quite sure we need permission per se; ICMP is extensible by design and this is transport feedback for which there is already precedent (port not found). Yes, they should definitely review it, though.,

[gorryfair]

I spoke to Eric Vyncke today, and he confirmed what I expected, that as an INT AD, he would not expect UDP to generate an ICMP message as a result of UDP-Options fragmentation issues, rather any errors ought to be handled (if needed) by the application running over UDP.

I'm therefore recommending that we do not specify new ICMP message types.

Gorry

[jtouch]

AOK. -25 fixes the text accordingly. — Dr. Joe Touch, temporal epistemologist www.strayalpha.com

On Nov 10, 2023, at 7:18 AM, Gorry Fairhurst @.***> wrote:

I spoke to Eric Vyncke today, and he confirmed what I expected, that as an INT AD, he would not expect UDP to generate an ICMP message as a result of UDP-Options fragmentation issues, rather any errors ought to be handled (if needed) by the application running over UDP.

I'm therefore recommending that we do not specify new ICMP message types.

Gorry

— Reply to this email directly, view it on GitHub https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/16#issuecomment-1805920479, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJVISE3YJCVARPSMAEGKILYDZAUHAVCNFSM6AAAAAAZ6BM3B6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBVHEZDANBXHE. You are receiving this because you commented.

[Mike-Heard]

Based on the text in -28, I recommend that we close this issue.

[gorryfair]

The new text has says ICMP messages MUST NOT be sent for UDP reassembly timeout or UDP fragment overlap.