Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-14.txt

From: [email-masked]
Date: Tue, 01 Mar 2022 21:31:00 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Area Working Group WG of the IETF.

        Title           : Transport Options for UDP
        Author          : Joe Touch
	Filename        : draft-ietf-tsvwg-udp-options-14.txt
	Pages           : 39
	Date            : 2022-03-01

Abstract:
   Transport protocols are extended through the use of transport header
   options. This document extends UDP by indicating the location,
   syntax, and semantics for UDP transport layer options.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-14

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-udp-options-14

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 1 Mar 2022 21:35:12 -0800

Hi, all,

LOTS of changes. Mostly as discussed in past IETF reports, focusing on:
- moving OCS to a required field
- moving UNSAFE options to a simper, reserved subset of the kind range

I also did a full deep pass for clarity through the first 7 sections.

I *tried* to keep up with the >100 messages and update suggestions, but won’t pretend I caught them all. Any omissions are my fault; please let me know if you notice any I missed.

Joe
—
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com

> On Mar 1, 2022, at 9:31 PM, [email-masked] wrote:
> 
>

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 1 Mar 2022 21:39:26 -0800

PS - note that I’m also suggesting that REQ/RES be included in the required options, otherwise we won’t get PLPMTUD off the ground.

And ACS was renamed to APC (alternate payload checksum), to avoid confusion with OCS (which is a checksum on the options area).

Again, LOTS of changes.

Note also that this is one of my first uses of an alternate publication pipeline, using Word -> PDF -> text directly on a Mac, without use of a PC and a “text only” printer. So if there are any errant spaces (e.g., in the middle of words), please ignore (and it would be helpful to let me know).

Joe

—

> On Mar 1, 2022, at 9:35 PM, [email-masked] wrote:
> 
> Hi, all,
> 
> www.strayalpha.com <http://www.strayalpha.com/>
> 
>> On Mar 1, 2022, at 9:31 PM, [email-masked] <mailto:[email-masked]> wrote:
>> 
>> 
>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/ <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/>
>>

---

From: <[email-masked]>
Date: Wed, 2 Mar 2022 07:42:43 +0000

Hi Joe,

Thanks for this update.

I see that your suggestion to tag REQ/RES as required was already implemented in -14. I support maintaining that change. With this change, I consider that the point currently discussed in the dplpmtud-03 thread is closed. Still, some tweaks are needed to the dplpmtud I-D to sync with udp-options-14.

Joe, please find below a nit and a change:

(1)

OLD: 7*      6         Response (RESP)

NEW: 7*      6         Response (RES)

(2) Please add an explicit pointer to the section where fragmentation is discussed in dplpmtud:

OLD:

   Note also that the FRAG option is

   not used when sending DPLPMTUD probes to determine a PLPMTU [Fa22<https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-14#ref-Fa22>].

NEW:

   Note also that the FRAG option is

   not used when sending DPLPMTUD probes to determine a PLPMTU (Section 4.1<https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-dplpmtud#section-4.1> of [Fa22<https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-14#ref-Fa22>]).

Thank you.

Cheers,
Med

De : tsvwg <[email-masked]> De la part de [email-masked]
Envoyé : mercredi 2 mars 2022 06:39
À : TSVWG <[email-masked]>
Objet : Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-14.txt

Again, LOTS of changes.

Joe

—
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com<http://www.strayalpha.com>

On Mar 1, 2022, at 9:35 PM, [email-masked]<mailto:[email-masked]> wrote:

Hi, all,

Joe
—
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com<http://www.strayalpha.com/>

On Mar 1, 2022, at 9:31 PM, [email-masked]<mailto:[email-masked]> wrote:

Abstract:

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Erik Auerswald <[email-masked]>
Date: Thu, 3 Mar 2022 09:20:15 +0100

Hello Joe,

> Note also that this is one of my first uses of an alternate publication
> pipeline, using Word -> PDF -> text directly on a Mac, without use of
> a PC and a “text only” printer. So if there are any errant spaces
> (e.g., in the middle of words), please ignore (and it would be helpful
> to let me know).

The draft has lost all "Figure #" prefixes in
the figure captions from version -13 to -14, see
<https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-tsvwg-udp-options-13.txt&url2=https://tools.ietf.org/id/draft-ietf-tsvwg-udp-options-14.txt>.

This might be related to the publication pipeline change.  The text
still references figures by numbers, so it seems those should be part
of the figure's caption.

HTH,
Erik
-- 
Always use the right tool for the job.
                        -- Rob Pike

---

From: Erik Auerswald <[email-masked]>
Date: Thu, 3 Mar 2022 13:43:46 +0100

Hello Joe,

On Thu, Mar 03, 2022 at 09:20:15AM +0100, Erik Auerswald wrote:
> On Wed, March 02, 2022 05:35 UTC, Joe Touch wrote:
> > 
> > Note also that this is one of my first uses of an alternate
> > publication pipeline, using Word -> PDF -> text directly on a Mac,
> > without use of a PC and a “text only” printer. So if there are
> > any errant spaces (e.g., in the middle of words), please ignore
> > (and it would be helpful to let me know).
> 

In section 12 on page 26, in the inner bullet list a space has moved
from before the 'E' to after it:

Draft version 13: o E.g., […]

Draft version 14: oE .g., […]

HTH,
Erik

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 3 Mar 2022 08:32:01 -0800

—

> On Mar 3, 2022, at 12:20 AM, Erik Auerswald <[email-masked]> wrote:
> 
> Hello Joe,
> 

It is - apparently Word on a Mac generates PDF with figure captions as *images* instead of text, so pdftotext ignores them on output.

Ick.

I’m less concerned about the lack of bullet spacing, but that’s not great either.

I’ll repost.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Thu, 3 Mar 2022 16:02:40 -0800

Joe,

Thanks for the updated draft.

Please use RFC2119 language in section 6 when describing requirements for OCS.

>From the draft:
"Like the UDP checksum, OCS use is optional and contains zero when not
used. UDP checksums can be zero for IPv4 [RFC791] and for IPv6
[RFC8200] when UDP payload already covered by another checksum, as
might occur for tunnels [RFC6935]. The same exceptions apply to the
OCS, as well as for its use in UDP fragmentation (see Section 8.4)."

I don't see how RFC6935 or the fact that the UDP payload is already
covered by another checksum is pertinent. The surplus space is not
part of the UDP payload so it is neither covered by the UDP checksum
nor any checksum or CRC in the UDP payload. The zero OCS checksum
could only be safely used it were deployed in a limited domain where
the domain is controlled to be essentially error free and it is
guaranteed in the limited domain that there are no other uses of the
surplus space, or any possible misinterpretation of the contents the
surplus area is known to be innocuous.

Tom

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 3 Mar 2022 17:45:20 -0800

Hi, Tom,

> On Mar 3, 2022, at 4:02 PM, Tom Herbert <[email-masked]> wrote:
> 
> Joe,
> 

Will do.

> covered by another checksum is pertinent.

Because if a UDP packet - including the surplus area - is a payload of another layer that has protection (IPsec, e.g.), then there’s no need to bother with UDP checksums at that layer. The same argument holds for OCS if the key issue is errors. It’s up to the user to decide whether they think other OCS errors are of concern or not.

> The surplus space is not

A reason OCS might not be needed is in a UDP datagram that is fragmented. There’s no need for a datagram-wide OCS if the fragments have OCS already. 

Joe

---

From: Tom Herbert <[email-masked]>
Date: Thu, 3 Mar 2022 19:35:34 -0800

Joe,

But that is not what RFC6935 and RFC6936 are about. The very reason
that the UDP checksum is required in IPv6 is that IPv6 has no header
checksum like IPv4 has. In particular, the UDP pseudo header for
checksum includes the IP addresses when against corruption causing
misdelivery of the packet. So the concern of these RFCs isn't about
corrupted UDP payload, it's about corrupted metadata in the packet
that causes the packet to be fundamentally misinterpreted. Contrary to
what some people seem to think, RFC6935 and RFC6936 do not provide
arbitrary license to use the zero UDP checksum for UPPv6 tunnels; to
the contrary, to define a robust protocol for this there are quite a
bit of conditions and requirements that need to be considered (e.g.
see section 6.2 of RFC8086).

My recommendation is to take out any references to RFC6935 and
RFC6936. If the OCS is optional then the requirements and conditions
for that to maintain correctness and robustness should be fully
described in this document on their own merits, not by trying to draw
an offhand analogy to the unrelated UDP checksum.

Tom

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 3 Mar 2022 19:46:08 -0800

Tom,

> On Mar 3, 2022, at 7:35 PM, Tom Herbert <[email-masked]> wrote:
> 
>> ...
> But that is not what RFC6935 and RFC6936 are about.

The updated text makes it clear that users can decide to omit OCS when protection is provided by the tunnel layer and the primary concern is bit errors - even in the option area, these would be covered by the tunnel protocol. This is the same case as for those RFCs.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Fri, 4 Mar 2022 07:57:32 -0800

Joe,

The requirement in the draft is "OCS MAY be unused, as indicated by a
zero value". So this allows the user to disable the checksum, but the
draft doesn't provide any guidance or discussion to the user on the
risks or mitigations of disabling the checksum. Again to contrast
this, in RFC8086 it took us two pages to describe how zero UDPv6
checksum can be used with GRE/UDP.

The risks and effects of disabling the OCS checksum are not the same
as disabling the UDP checksum. For instance, the WG identified cases
where routers may incorrectly compute the UDP checksum if the surplus
area is not checksummed. There's a reference in the draft about this,
but no requirements to mitigate the problems. Minimally, it seems like
if the UDP checksum is non-zero then the OCS checksum MUST or at least
SHOULD be enabled to save the user from having to debug this when
their packets happen to hit a router dropping packets.

Also, what is the RECOMMENDED implementation default setting. IMO,
this should be that the OCS is enabled.

Tom

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 4 Mar 2022 08:15:42 -0800

—

> On Mar 4, 2022, at 7:57 AM, Tom Herbert <[email-masked]> wrote:
> 
> risks or mitigations of disabling the checksum.

I just discussed this with Gorry.

Yes, this needs to be updated. There are three reasons:

1. If the entire IP datagram is in a tunnel, notably if it is encrypted or compressed
	- at that point, the middle box can’t see the UDP CS or the fact that there is a surplus area at all
	- this is the RFC 6935 case

2. The endpoints know they don’t traverse middle boxes that incorrectly need OCS for traversal
	- e.g., inside a datacenter, where avoiding the extra checksum at the end could have performance value
	- other examples include inside enterprise networks or other controlled areas
	- there’s also the case where the endpoints either know or don’t care — this is a user choice, after all

3. If the UDP datagram is fragmented
	- in that case, we would create a datagram with a zero OCS, THEN fragment it
	- each fragment has its own OCS that protects the fragment as it traverses middle boxes
	- but the endpoints now can avoid doing OCS over the pre-fragmented or post-reassembled datagram

I do need to update the text with this context, including the statement that:

>> OCS SHOULD be used (nonzero), except where the user accepts the risks (user choice) or in cases that include the three above.

Would that address your concern? Or do you disagree with the above?

Joe

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 4 Mar 2022 08:46:12 -0800

Minor update below...
—

> On Mar 4, 2022, at 8:15 AM, [email-masked] wrote:
> 
> 
> —
>> On Mar 4, 2022, at 7:57 AM, Tom Herbert <[email-masked] <mailto:[email-masked]>> wrote:
>> 

>> OCS SHOULD be used (nonzero) in each UDP unfragmented or pre-fragmented datagram, except where the user accepts the risks (user choice) or in cases that include the three above.

>> OCS SHOULD be used (nonzero) in each UDP datagram fragment, except where the user accepts the risks (user choice) or in cases that include #1 or 2 above.

.- end.

---

From: Tom Herbert <[email-masked]>
Date: Fri, 4 Mar 2022 10:03:50 -0800

> - this is the RFC 6935 case
That's a very narrow use case. The predominant use cases of UDP don't
involve tunnels at all like QUIC, DNS, and other application
protocols. That needs to be the first focus when specifying the
protocol requirements.

> - there’s also the case where the endpoints either know or don’t care — this is a user choice, after all
I don't see how this could work. Again, the common usage of UDP in a
datacenter is not for tunneling, but for application protocols.
Application protocols are not part of the network infrastructure, the
"user" deploying these UDP applications is not a network
administrator, it's an application developer that really doesn't care
about the internal characteristics of every possible path such that
they could disable the checksum. But from an application developer
point of view it's a moot question. Unlike routers that needed RFC6935
and RFC6936, end hosts have all the necessary support for computing
checksums efficiency so they aren't going to see any performance
benefit from disabling the checksum, at least any benefit that would
justify the risk and the work needed to disable it. So unless there's
some very specific reason not to or some edge cases, there is no
reason not to make the checksum enabled by default.

> Would that address your concern? Or do you disagree with the above?

Maybe "OCS SHOULD be enabled and it is RECOMMENDED that the default
setting for an implementation is that the checksum is enabled. If the
UDP checksum is zero then the OCS MUST be enabled unless the user has
explicit knowledge on a per path basis that intermediate nodes
properly compute the UDP checksum."

Tom

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 4 Mar 2022 11:02:21 -0800

Hi, Tom,

I’d like to hear from others on the list too, but some notes below.

Joe
—

> On Mar 4, 2022, at 10:03 AM, Tom Herbert <[email-masked]> wrote:
> 

It’s a specific exception, and I don’t think it’s as rare as do you.

Notably LOTS of people run VPNs now - mostly EVERYONE working from home, more than before COVID.

> reason not to make the checksum enabled by default.

This works as I stated - if you know the path and know you don’t have broken middle boxes, then this is wasted effort.

We don’t yet know where this will be implemented; turning it off is reasonable when it isn’t needed and COULD have a performance impact.

> properly compute the UDP checksum.”

The default applies only where the SHOULD applies, so there doesn’t need to be a separate requirement IMO.

If we make any statement about intermediate nodes, it should be clear that they have NO BUSINESS computing or validating the UDP checksum. But that ‘explicit knowledge’ exists if I’m sending traffic over a tunnel (encrypted or not, it’s unlikely intermediate nodes would bother to look that far inside a packet).

I think the text I suggested is already sufficient in this regard; let’s see what others think, though…

--

---

From: Tom Herbert <[email-masked]>
Date: Fri, 4 Mar 2022 12:41:32 -0800

In section 11 the draft mentions that if the OCS check fails then the
options are ignored, and also the draft states:

>> All options except UNSAFE options MUST result in the UDP payload being passed to the application layer, regardless of whether all options are processed, supported, or succeed.

But then later in that section it reads:

 o  if the option is required (e.g., by override of the default
behavior at the receiver) and missing or incorrectly formed, silently
drop the packet.

It seems like these might be contradictory requirements. How are these
different requirements rectified? For instance, if the OCS
verification fails but there are required options then does that mean
the packet is accepted per the first set of requirements above or
discarded per the second?

"The above requirements prevent using any option that cannot be safely
ignored unless it is hidden inside the FRAG area (i.e.,
 UNSAFE options). Legacy systems also always need to be able to
interpret the transport payload fragments as individual transport
datagrams"

This should be spelled out in requirements like "UNSAFE options MUST
NOT be used except when hidden inside a FRAG area" and "If a receiver
receives an UNSAFE option in the non-FRAG area the packet MUST be
discarded".

Tom

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 4 Mar 2022 15:24:54 -0800

Hi, Tom,

I think the doc does mix up a few things:

The following call into questions all options, either by definition or (in the last case) by fiat:
- failed OCS
- option parsing failure (any type of options)
- UNSAFE option used in where SAFE options are expected
- UNSAFE options that individually fail (e.g., incorrect UENC)
	drop all options silently, but forward UDP payload data (if any, i.e., none for an individual fragmen, but still a zero-length packett)

NOTE: we should NEVER do “better” than a legacy endpoint for these.

The following are a user’s prerogative:
- options that the receiver explicitly configures as “drop if missing” (e.g., TIME, REQ, etc.) or “drop of incorrect” (e.g., AUTH, APS)
	do what the receiver is configured to do (user decision), e.g., drop silently, drop with count, etc.

I don’t see these as contradictory, though the doc should be more clear.

Is that the issue you’re raising?

Joe

—

> On Mar 4, 2022, at 12:41 PM, Tom Herbert <[email-masked]> wrote:
>

---

From: Tom Herbert <[email-masked]>
Date: Fri, 4 Mar 2022 16:52:48 -0800

> Is that the issue you’re raising?
If a packet is received, the OCS is bad and there is a required
option, what is the correct disposition of the packet? Drop or accept
it?

Also, there's

>> Option lengths MUST NOT exceed the IP length of the packet. If this occurs, the packet MUST be treated as malformed and dropped

A receiver that doesn't support UDP options wouldn't be able to check
option lengths, so the requirement could be that only receivers that
understand UDP options drop. What that means is that whether or not a
packet is malformed is dependent on the receiver's interpretation.
It's a bit of an odd situation, since if the exact same packet is
received by two receivers, one may see the packet as correctly formed
and accept it, and the other may see the packet is malformed and drop;
however per the spec they are both correct! I don't know what the
consequences of this are.

Also, are there any limits to the number of options in a packet that a
receiver must process. We know that unbounded lists of TLVs can be
exploited as a DoS attack (this is a motivation to allow limits for
the number of HBH and Destination options in RFC8504 and
draft-ietf-6man-eh-limits).

Tom

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 4 Mar 2022 17:55:02 -0800

Hi, Tom,

> On Mar 4, 2022, at 4:52 PM, Tom Herbert <[email-masked]> wrote:
> 
>> ...

If OCS is bad, everything stops immediately (I should have noted in the rules I gave that “whatever happens first…”. 

The surplus area is dropped, but the packet is delivered (to be consistent with legacy endpoints).

If that were to happen for a FRAG, it would mean a zero-length packet. None of the fragment data would be delivered.

> understand UDP options drop.

Sorry - that’s wrong; it should be “if option lengths are malformed, then drop the surplus area and deliver the UDP payload”, i.e., same as if OCS failed.

> What that means is that whether or not a

How does that happen? I don’t think that can.

> receiver must process.

No. There are only limits to the number of NOPs in a row.

We can do the same as 8504:

   A host MAY impose a limit on the maximum length of Destination
   Options or Hop-by-Hop Options extension headers.  This value SHOULD
   be configurable, and the default is to accept options of any length.

> We know that unbounded lists of TLVs can be

See above; the default is to accept any number of IP destination options, and so should UDP.

Joe

---

From: Gorry Fairhurst <[email-masked]>
Date: Sat, 5 Mar 2022 08:51:05 +0000

See below.

>> I just discussed this with Gorry.
So, with no chair-hat, but just replaying previous discussion here, I do 
have comments.

1. I think this is an IPv4-centric change, which I would really love to 
avoid. The conditions under which IPv6 can be used as a tunnel 
encapsulation without checksum are strictly limited, and were designed 
for the case where the sender was unable to read the payload of the 
packet - i.e., could access only the first few bytes. Clearly UDP 
Options exist as a trailer, and I question whether there are many 
devices that are unable to read the middle of a packet bnut can read the 
header and append a trailer. This is a different use.

2. We have discussed traveral properties many times in tsvwg. The NAPT 
traversal case,  or some other on-path device that computes a checksum 
on path, is an important case. I think we need to design to resolve this 
- it arises from unclarity in how UDP checksums are processed and was 
found prevalent.  Before -13, we had more text on this, and I think some 
of this text/arguments needs to be added back to motivate and explain 
why the checksum design is critical to deployability. Put simply: if we 
add the UDP-Option support and then packets fail to traverse a path, 
then I think the method fails to be useful.

3. The latest text seems to be suggest avoiding multiple checksum 
passes. I'd suggest we should not choose easy optimisation against 
deployability -  I will argue that would be a poor design. All 
datagrams, even fragments, benefit when there is better traversal across 
Internet paths in general.

4. I can see there could be a case for a varient for use in constrained 
environments, where the endpoints know they do not traverse middle 
boxes, if we think that the cost of endpoint checksum processing is 
significant and not optimisable (which I doubt), it could be worth 
discussing how this alternative use is controlled/specified. First, we 
should decide if this is important enough?

> protocols. That needs to be the first focus when specifying the
If it's compressed, then that could be a compression optimisation. One 
could similatly apply ROHC etc before encryption,... so I agree with 
Tom, this is a specific case.
> reason not to make the checksum enabled by default.
See above. On this I also agree RFC6935&RFC6936 address a different 
problem.
> properly compute the UDP checksum."

.... I'd suggest it would need to be IPv4-specific, and then I'd 
hessitate at specify a transport that behaves differently based on IP 
version. ...

Gorry

---

From: "[email-masked]" <[email-masked]>
Date: Sat, 5 Mar 2022 09:54:37 -0800

Hi, Gorry,

> On Mar 5, 2022, at 12:51 AM, Gorry Fairhurst <[email-masked]> wrote:
> 
> See below.
> 
> So, with no chair-hat, but just replaying previous discussion here, I do have comments.
> 
> 1. I think this is an IPv4-centric change, which I would really love to avoid.

It has nothing to do with IPv4.

Both IPv4 (always) and IPv6 (for tunnels) allow UDP CS=0.

> The conditions under which IPv6 can be used as a tunnel encapsulation without checksum are strictly limited, and were designed for the case where the sender was unable to read the payload of the packet - i.e., could access only the first few bytes. Clearly UDP Options exist as a trailer, and I question whether there are many devices that are unable to read the middle of a packet bnut can read the header and append a trailer. This is a different use.

The issue is whether middle boxes incorrectly checking or wholly recomputing UDP CS would fail if OCS=0. That case doesn’t come up for tunnels that are encrypted or compressed, which it either can’t (the former) or is very unlikely (the latter, e.g., decompress, recalculate, recompress).

> 2. We have discussed traveral properties many times in tsvwg. The NAPT traversal case,  or some other on-path device that computes a checksum on path, is an important case. I think we need to design to resolve this - it arises from unclarity in how UDP checksums are processed and was found prevalent.  Before -13, we had more text on this, and I think some of this text/arguments needs to be added back to motivate and explain why the checksum design is critical to deployability. Put simply: if we add the UDP-Option support and then packets fail to traverse a path, then I think the method fails to be useful.

I’ll dig out some of the text - I might have removed too much. But we don’t need the “flip the bytes” text anymore.

> 3. The latest text seems to be suggest avoiding multiple checksum passes. I'd suggest we should not choose easy optimisation against deployability -  I will argue that would be a poor design. All datagrams, even fragments, benefit when there is better traversal across Internet paths in general.

Please see slides from the last two IETFs:

- IETF 112, fall 2021, slide 2, which was summarizing changes intended for -14
	this notes the OCS=0 case

- IETF 110, spring 2021, slide 2
	which mentions the OCS 0 issue

OCS=0 is about performance, but that matters too, just like putting it in a fixed location enables offload hardware.
OCS=0 does not interfere with deployability any more than UDP CS=0 does.

> 4. I can see there could be a case for a varient for use in constrained environments, where the endpoints know they do not traverse middle boxes, if we think that the cost of endpoint checksum processing is significant and not optimisable (which I doubt), it could be worth discussing how this alternative use is controlled/specified. First, we should decide if this is important enough?

Again, these uses are provably safe. If UDP CS=0, OCS=0 cannot matter. OCS=0 in the main packet before frag/after reassembly is visible only at the frag/reassy endpoints - and the FRAGs ***DO*** have OCS !=0 (unless, again , UDP CS=0 in that frag or known compressed/encrypted).

This was converged in -08 or before - what’s the new concern?

Joe

---

From: Gorry Fairhurst <[email-masked]>
Date: Sat, 5 Mar 2022 19:14:34 +0000

See below,

> On 5 Mar 2022, at 17:55, "[email-masked]" <[email-masked]> wrote:
> 
> Hi, Gorry,
> 
For IPv6 tunnels Using UDP, if the endpoints are specifically configured to do this, otherwise checksum needed. For IPv6 network later tunnels, this is required end-to-end.... see later for something clearer.

> The issue is whether middle boxes incorrectly checking or wholly recomputing UDP CS would fail if OCS=0. That case doesn’t come up for tunnels that are encrypted or compressed, which it either can’…
We don’t seem to agree on the Va;use of the cross-layer optimisation.

> I’ll dig out some of the text - I might have removed too much. But we don’t need the “flip the bytes” text anymore.
OK - agree the “flip” is not needed, because of the change to the header.

> OCS=0 does not interfere with deployability any more than UDP CS=0 does.
I  need to understand this better - are you saying ocs=o only when UDP CS=0? 

> Again, these uses are provably safe. If UDP CS=0, OCS=0 cannot matter

Yes, that may be the condition that matters here, as above.

> . OCS=0 in the main packet before frag/after reassembly is visible only at the frag/reassy endpoints - and the FRAGs ***DO*** have OCS !=0 (unless, again , UDP CS=0 in that frag or known compressed/encrypted).
> 
Confusion probably For this reader - so some text seems needed.

> Joe

Best wishes,
Gorry

---

From: Tom Herbert <[email-masked]>
Date: Sat, 5 Mar 2022 11:25:34 -0800

Joe,

That seems to contradict:

I would extrapolate that if the receiver receives a packet and
requires an option but the options are malformed or not even there
then that means the packet MUST be dropped. So in order to be
compatible with legacy mode, that means that a receiver MUST never
enforce required options unless it's options in frag encoding.

What exactly does it mean to "drop the surplus area"?

> How does that happen? I don’t think that can.
Very easily. For instance, a packet with UDP options could be
multicast to a set of receivers where some of them support UDP options
and some don't. To be consistent between them that would have to mean
the presence of UDP options can never cause the packet to be dropped,
except the case where the options are sent in frag mode.

>    be configurable, and the default is to accept options of any length.
The relevant text in RFC8405 for number of options is:

"A host MAY impose a limit on the maximum number of non-padding
options allowed in the destination options and hop-by-hop extension
headers.  If this feature is supported, the maximum number SHOULD be
configurable, and the default value SHOULD be set to 8."

> See above; the default is to accept any number of IP destination options, and so should UDP.
Please add appropriate text to the draft describing the potential for
DoS attack and any mitigations with UDP options.

Tom

---

From: "[email-masked]" <[email-masked]>
Date: Sat, 5 Mar 2022 13:49:53 -0800

Hi, Tom,

> On Mar 5, 2022, at 11:25 AM, Tom Herbert <[email-masked]> wrote:
> 

We can do one of two things:
- discuss what the overall set of rules should be
- go through the text and fix those rules

I’m hoping we can do the former first, which means YES - it MAY contradict the text UNTIL the text is edited.

> then that means the packet MUST be dropped.

I want to be very clear.

SILENT TOTAL DROP never actually happens for ANY packet unless the receiver sets that up.

What actually happens is that the surplus is dropped, which means UDP payload data goes to the user.

For non-frag packets, that’s whatever the user payload data is.

For frag packets (and thus UNSAFE options, which MUST be inside FRAGs - even a singleton FRAG), this means a zero-length packet arrives.

But in all cases, unless the receiver asks the protocol to do otherwise, no matter what error happens in options, user data (or a zero-length) packet is sent to the user.

> So in order to be

There are two differences between options outside a frag (safe ones) and options inside (which can include unsafe):

- options inside a frag never send payload data up, but they can still send zero-length packets
- safe options that don’t fail structure NEVER prevent payload data from going up
	i.e., AUTH that fails is still delivered; it’s up to the user to decide what to do with it (based on the associated option info, e.g., indicating AUTH failed)
- failures of structure (OCS is bad, incorrectly formed options) AND failures of UNSAFE options stop option processing

UNSAFE are different only in that:
	- they preempt the rest of option processing if they semantically fail
	- they are always used inside FRAGs

> What exactly does it mean to "drop the surplus area"?

Stop processing it.

> except the case where the options are sent in frag mode.

Packets are - I repeat - NEVER DROPPED. Only the payload data is omitted at most, and which point a zero-length packet arrives.

So let’s say a packet has malformed options. Then both it and a legacy receiver get a packet with the payload data. Same behavior.

Let’s say a packet has non-malformed options. Then a legacy receiver gets the payload data and an options-aware receiver processes the options. In that case, behavior could be different, based on the options. E.g., a solitary FRAG with UENC would be a zero-length packet to a legacy receiver but could deliver decrypted data to an options-aware receiver.

So what’s the problem??

> configurable, and the default value SHOULD be set to 8."

MAY impose a limit. That means it’s OK if they never do it at all.

However, the rest is ambiguous; when supported, even though the max has a default of 8, it’s not clear that checking the count is “on” (because of the MAY). Merely implementing it doesn’t seem to warrant overriding the first MAY. E.g.:
	if this feature is supported, it SHOULD default to OFF, the maximum number SHOULD be configurable. If configurable, the default for that configuration SHOULD be set to 8.

Would that work?

Joe

---

From: "[email-masked]" <[email-masked]>
Date: Sat, 19 Mar 2022 17:12:38 -0700

FYI - I tried to go through the doc top-down for consistency of these issues.

It might be useful to see whether -16 is more consistent in that regard.

Joe

—

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 22 Mar 2022 12:12:21 -0700

On Sat, Mar 5, 2022 at 11:15 AM Gorry Fairhurst wrote:
> > On 5 Mar 2022, at 17:55, Joe Touch wrote:
> > OCS=0 in the main packet before frag/after reassembly is visible
> > only at the frag/reassy endpoints - and the FRAGs ***DO*** have
> > OCS !=0 (unless, again , UDP CS=0 in that frag or known
> > compressed/encrypted).
> >

I for one am generally satisfied with the text in Section 7 of -16,
which says:

   >> OCS MUST be non-zero when the UDP checksum is non-zero.

   >> When the UDP checksum is zero, the OCS MAY be unused, and is then
   indicated by a zero OCS value.

That's sufficiently clear to me. I would like to point out a couple of
things, though, that I think could be improved:

1. The text in Section 9.5 could be more explicit, in fact, it should
saying that the OCS value for the reassembled datagram SHOULD be zero,
since EITHER UDP CS = 0 (in which case no checksum is needed) OR
OCS != 0 in each of the fragments.

2. The pseudo-code in Section 12 does not take into account that
OCS != 0 is required if UDP CS != 0.

3. The requirement to make OCS 4-byte aligned seems overkill, since
neither the UDP checksum nor the IPv4 header checksum are 4-byte
aligned (in fact, their alignment is 4n+2, relative to the start of
the IP header). For that reason, two-byte alignment should be
sufficient for OCS.

I'll provide suggested text for these issues in a forthcoming message.

Mike Heard

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 22 Mar 2022 13:55:27 -0700

Thanks - yes, text would be useful. Though the issues below are fairly straightforward to address.

Joe

—

> On Mar 22, 2022, at 12:12 PM, C. M. Heard <[email-masked]> wrote:
>