Subject: Re: [tsvwg] draft-ietf-tsvwg-udp-options-13: Comments concerning OCS

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 1 Sep 2021 09:02:57 +0100

On 31/08/2021 22:09, Tom Herbert wrote:
>
>
> On Tue, Aug 31, 2021, 3:42 PM Gorry Fairhurst <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     On 31/08/2021 18:51, [email-masked]
>     <mailto:[email-masked]> wrote:
>>     Trying to catch these in order…
>>
>>     —
>>     Joe Touch, temporal epistemologist
>>     www.strayalpha.com <http://www.strayalpha.com>
>>
>>>     On Aug 31, 2021, at 3:17 AM, Gorry Fairhurst
>>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>>     I reviewed the latest revision (13) of the draft and have the
>>>     following comments/questions relating to the use of OCS.
>>>
>>>     Best wishes,
>>>
>>>     Gorry
>>>
>>>     (as an individual)
>>>
>>>     ===
>>>     Also in section 4: OCS:
>>>
>>>        Note that a receiver can compute the OCS checksum before
>>>     processing
>>>        any UDP options, but that computation would assume OCS is
>>>     used and
>>>        would not be verified until the OCS option is interpreted.
>>>
>>>     - I’m not sure I understood from the email thread I thought it
>>>     was quite OK to evaluate OCS without explicitly traversing the
>>>     TLV chain and then decide to silently discarded all UDP options
>>>     when OCS fails to compute. Either way, I think this could be
>>>     better explained.
>>
>>     There’s no text in the doc about this yet.
>>
>>     Here’s what I understand:
>>
>>     - if UDP CS is non-zero (OCS is required)
>>     if surplus checksum is zero, keep the options
>>     if surplus checksum is nonzero, drop the options as corrupted
>>     - if UDP CS is zero (OCS optional)
>>     if surplus checksum is zero, either OCS worked or you got “lucky”
>>     with a zero sum, but either way keep the options
>>     if the surplus checksum is nonzero, either there was no OCS or it
>>     failed
>>     this is the only case where you need to check the TLV
>>     if there’s no OCS, then keep the options
>>     if there is an OCS, then drop the options as corrupt (*this
>>     should be caught by higher layer tunnel mechanisms)
>>
>>     Yes, UDP CS zero case is risky, but that’s a known risk because
>>     it is assumed the entire IP payload is covered by other layers of
>>     protection (tunnel).
>>
>>>     - I also have a concern: if we allow a NOP (0) before the OCS,
>>>     then I fear this amplifies the chance that reading of the OCS
>>>     could be misplaced, and detect a zero. That might suggest a good
>>>     reason to avoid NOP padding before OCS. (See more on this topic
>>>     later).
>>
>>     I see no rationale for that (see below).
>>
>     OK - this was explained elsewhere, no worries here.
>>>     ===
>>>     In section 5.3: OCS:
>>>     The Option Checksum (OCS) option is conventional Internet checksum
>>>        [RFC791]
>>>     - Insert a word: “the” or “a” before “conventional”.
>>
>>     Yes.
>>
>>>     - This also raises the question whether the OCS can be
>>>     suppressed as zero, as its could for IPv4 and can’t by default
>>>     be for IPv6. However, if you allowed that I think it would also
>>>     negate the NAT-traversal capability, and hence create a weird
>>>     traversal case for any packet that happens to compute to a zero
>>>     OCS value? Have I understood this correctly?
>>
>>     This is a user protocol. If that’s what the user wants, they get
>>     what it delivers. It might be useful to avoid duplicate software
>>     checksumming for tunnels.
>>
>     We'd need to be clear. If we allow 0=don't check, then we can make
>     the OCS mandatory?
>>>     ====
>>>     In section 5.3: OCS:
>>>        >> When present, the OCS SHOULD occur as early as possible,
>>>     preceded
>>>        by only NOP options for alignment.
>>>     - This seems to imply that NOP options are required for
>>>     alignment. Is that the case or not? In fact, are they are
>>>     desirable at all?
>>
>>     It doesn’t imply a requirement; it ALLOWS them if desired.
>>
>>     Again, this being a user protocol, IMO, let the user decide if
>>     this is helpful or not.
>>
>     This is the real point where I am not yet convinced. I can see
>     that specifying the wire format unambiguosuly for the OCS would
>     perhaps help offloading. So that may perhaps be a tradeoff.
>>>     ===
>>>
>>>     In section 5.3: OCS:
>>>
>>>     >> OCS MUST be half-word coordinated
>>>     - I think more is needed to undersand what is implied by
>>>     “coordinated”. Could that word be explained here?
>>
>>     Yeah - it’s basically that we swap the bytes if not half-word
>>     aligned.
>     Hmmm... so allowing two ways seems to fight against methods for
>     offloading, I think that consideration should be weighed carefully.
>>
>>>     ===
>>>
>>>     In section 5.3: OCS:
>>>
>>>     >>  If the OCS checksum field is aligned to the start of the options
>>>        area, then the checksum is inserted as-is, otherwise the checksum
>>>        bytes are swapped before inserting them into the field.
>>>     - I think the "otherwise " case is only when this is odd-aligned?
>>
>>     Yes.
>>
>>>     - How does this relate to the NOPs statement earlier?
>>
>>     It doesn’t per se, though I can’t imagine why anyone would add
>>     NOPs except to avoid this swap.
>>
>>>     - It later states “OCS SHOULD be the first option, when present.”
>>>     - Do we need to allow two ways to do this? (I know they are
>>>     supposed to have equivalent effect, but it changes the wire
>>>     image, and I’m unsure we need to allow both. The earlier offload
>>>     calculation example could also suggest this could be problematic?)
>>
>>     Not everyone uses offload; this allows for an optimization for
>>     non-offload users who don’t want to use a NOP pad before OCS.
>
>     To me, this is one we should continue to discuss a little more. I
>     think the tradeoff is:
>
>     (a) save one byte when mis-aligned and add a tiny bit of code to
>     swap;
>
>     or (b) burn one byte of NOP when mis-aligned and enable potential
>     easier offload.
>
>     Are there many cases where this misalignment would actually occur?
>     How many IPv6 EH (etc) result in an odd byte alignment? Any?
>
>
> All IPv6 EH are multiples of eight bytes in length. All network and 
> transport headers that I know of are at least multiple of two bytes 
> and typically four. The only time UDP options space could be odd byte 
> aligned is if the surplus space follows UDP data with an odd length. 
> In the current draft I believe the checksum would naturally be 
> unaligned because it's a three byte TLV (i.e. if option space is 
> aligned, a checksum as  first TLV is unaligned).
>
> Tom
>
Right, so odd alignment is itself an oddity in transports over IP; but 
is something that might occur in the trailer after the UDP payload.

That makes me wonder still if (b) might not be the better approach.
>>     Joe
>     Gorry
Gorrry

---

From: "C. M. Heard" <[email-masked]>
Date: Thu, 2 Sep 2021 09:02:18 -0700

On Tue, Aug 31, 2021 at 9:10 AM Tom Herbert  wrote:

> On Tue, Aug 31, 2021 at 3:17 AM Gorry Fairhurst  wrote:
> > Also in section 4: OCS:
> >
> >     Note that a receiver can compute the OCS checksum before processing
> >     any UDP options, but that computation would assume OCS is used and
> > - I’m not sure I understood from the email thread I thought it was quite
> > OK to evaluate OCS without explicitly traversing the TLV chain and then
> > decide to silently discarded all UDP options when OCS fails to compute.
> > Either way, I think this could be better explained.
>
> The OCS can appear anywhere in the options, it is only a SHOULD for it
> to be first. A receiver has to be prepared for that. If the idea is
> that the OCS needs to be evaluated before any other options are
> processed, then a receiver has little choice but to make two passes
> over the options in cases that OCS is not required: first to fish to
> see if there is an OCS, second to actually process the options.
>

As Joe noted later in the thread, this is an issue only if UDP CS=0, for
only in that case is OCS optional.

On Tue, Aug 31, 2021 at 11:02 AM Joe Touch  wrote:

> The only possible corruption issue is when UDP CS is zero and OCS is
> required, but that’s an odd case. Perhaps our lives would be a lot easier
> by just stating that if UDP CS is zero, OCS cannot be present. In both
> cases, the packet relies on other layers for protection.
>

I am in strong agreement with that, modulo the following wording change:

When UDP CS=0:

- The transmitter need not (and indeed SHOULD NOT) include OCS in
transmitted options;
- The received MUST NOT check OCS; rather, it must ignore the option if it
is present.

Then checking of OCS, when needed, could always consist of computing the
Internet checksum on the options field and checking whether the result is
equal to the ones complement of the option length. There would never be any
need for the receiver to loop through the options to perform this check, so
Gorry's statement above would be correct. Admittedly this does leave a
waste case where the options just happen to have that checksum without
including an OCS TLV, but I think that can be safely ignored, since it's on
the same level of likelihood of the checksum failing to detect an actual
error.

Later on from Tom's reply to Gorry quoted above:

> > - Do we need to allow two ways to do this? (I know they are supposed to
> > have equivalent effect, but it changes the wire image, and I’m unsure we
> > need to allow both. The earlier offload calculation example could also
> > suggest this could be problematic?)
>
> Yes, byte swapping the checksum breaks TX checksum offload, the
> checksum field must be even byte aligned relative to the start of the
> checksum area. The checksum area itself should be even byte aligned to
> the beginning of the packet as well since some devices will indicate
> offsets that are multiplied by two. Note that every other use case of
> Internet checksum in protocols have properly unaligned checksum
> offsets, and it is unlikely vendors would change their implementation
> to suit the peculiarities of OCS in UDP options.
>

If we make the specification change described above, unaligned OCS would
have NO EFFECT in RX checksum offload, as least with the common
implementation strategy that Tom Herbert has described: the hardware
computes the Internet checksum of the entire UDP packet and so includes
both the UDP checksum and the OCS. The software has to deal with the
pseudo-header, and when there are two checksums involved, it has to
explicitly compute one of them (probably whichever one is shorter).

And while it's true that an unaligned OCS would not play well with TX
checksum offload, if the OCS itself were to be offloaded, the transmitter
always has the discretion to include pads to make the field align (modulo
8) wherever the hardware needs it.

In sum, I see no problem with the current spec except the need to remove
optional OCS when UDP CS=0.

Respectfully,

Mike Heard

---

From: Tom Herbert <[email-masked]>
Date: Thu, 2 Sep 2021 10:31:18 -0700

On Thu, Sep 2, 2021 at 9:02 AM C. M. Heard <[email-masked]> wrote:
> As Joe noted later in the thread, this is an issue only if UDP CS=0, for only in that case is OCS optional.
>
>> The only possible corruption issue is when UDP CS is zero and OCS is required, but that’s an odd case. Perhaps our lives would be a lot easier by just stating that if UDP CS is zero, OCS cannot be present. In both cases, the packet relies on other layers for protection.
>
>
> - The transmitter need not (and indeed SHOULD NOT) include OCS in transmitted options;

IMO, that contradicts the very idea of performing a checksum over the
options area to verify the contents of the options space. Regardless
of whether the UDP checksum is zero or not, there is *no* checksum or
other integrity check in the UDP header or payload that covers the UDP
options. The checksum is important, for instance to distinguish that
the surplus area is actually UDP options as opposed to some random set
of bits that a host or router inserts.

> - The received MUST NOT check OCS; rather, it must ignore the option if it is present.

This would also contradict the well established convention in that if
a checksum is present in the packet it MUST be verified before the
packet is accepted.

>
> Then checking of OCS, when needed, could always consist of computing the Internet checksum on the options field and checking whether the result is equal to the ones complement of the option length. There would never be any need for the receiver to loop through the options to perform this check, so Gorry's statement above would be correct. Admittedly this does leave a waste case where the options just happen to have that checksum without including an OCS TLV, but I think that can be safely ignored, since it's on the same level of likelihood of the checksum failing to detect an actual error.
>
> If we make the specification change described above, unaligned OCS would have NO EFFECT in RX checksum offload, as least with the common implementation strategy that Tom Herbert has described: the hardware computes the Internet checksum of the entire UDP packet and so includes both the UDP checksum and the OCS. The software has to deal with the pseudo-header, and when there are two checksums involved, it has to explicitly compute one of them (probably whichever one is shorter).
>
> And while it's true that an unaligned OCS would not play well with TX checksum offload, if the OCS itself were to be offloaded, the transmitter always has the discretion to include pads to make the field align (modulo 8) wherever the hardware needs it.

>
> In sum, I see no problem with the current spec except the need to remove optional OCS when UDP CS=0.

Then there is no way that allows the receiver to validate UDP options.
IMO, that would be going completely the wrong direction. Just have the
checksum present all the time like it is in TCP. CS=0 is only possible
for IPV4 not IPv6 so that is a vanishing use case (for instance see
https://www.theregister.com/2021/07/26/china_single_stack_ipv6_notice/).
Besides that, making the checksum optional is more work than benefit
in a modern networking stack-- it really doesn't save work as attested
by the fact that both TCP and IPv4 header have a required checksum and
no one is complaining about that. If the checksum is always required
then pretty much all the issues with OCS that have been continually
raised on the list over the past few years just go away.

Tom

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 2 Sep 2021 11:21:37 -0700

Notes below…

—
www.strayalpha.com

> On Sep 2, 2021, at 10:31 AM, Tom Herbert <[email-masked]> wrote:
> 
> options area to verify the contents of the options space.

It states that this is not needed when the UDP data is not checksummed either. In both cases, the assumption is that the traffic goes over a layer that already provides this protection, e.g., a tunnel.

> Regardless

OCS indicates whether there is an error. It is not designed as validation that the area is used as intended. 

What you’re seeking would be provided by AUTH if desired, not OCS.

> a checksum is present in the packet it MUST be verified before the

I think we’re converging on:
	if UDP CS != 0, then OCS must come first (we still need to decide if that is fixed alignment or not)
	if UDP CS ==0, then OCS is not used (IMO, we can allow it but ignore it if present; that’s safer than throwing an error when present)

> Then there is no way that allows the receiver to validate UDP options.

We aren’t designing AUTH here, so agreed.

> for IPV4 not IPv6

UDP CS=0 for IPv6 too when tunneled. And tunnel use is increasing, if anything.

> so that is a vanishing use case (for instance see

---

From: Tom Herbert <[email-masked]>
Date: Thu, 2 Sep 2021 14:53:42 -0400

On Thu, Sep 2, 2021, 2:21 PM [email-masked] <[email-masked]>
wrote:

> It states that this is not needed when the UDP data is not checksummed
> either. In both cases, the assumption is that the traffic goes over a layer
> that already provides this protection, e.g., a tunnel.
>

The payload is protected, but not UDP options.

> if UDP CS ==0, then OCS is not used (IMO, we can allow it but ignore it if
> present; that’s safer than throwing an error when present)
>

No, integrity check is needed.

> UDP CS=0 for IPv6 too when tunneled. And tunnel use is increasing, if

Tunnel use is nothing compared to 1B+ users of QUIC/IPv6 coming up in
China. IMO IETF should be optimizing for them.

You are referring to RFC6935 and RFC6936. These were created because of
routers don't have sufficient hardware to compute payload checksum. That
same hardware is unlikely to support protocol trailers which AFAIK are
still required by UDP options.

Tom

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 2 Sep 2021 12:06:49 -0700

—

> On Sep 2, 2021, at 11:53 AM, Tom Herbert <[email-masked]> wrote:
> 
> 
> 
> On Thu, Sep 2, 2021, 2:21 PM [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>> wrote:
> Notes below…
> 
> —
> www.strayalpha.com <http://www.strayalpha.com/>
> 
>> On Sep 2, 2021, at 10:31 AM, Tom Herbert <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> On Thu, Sep 2, 2021 at 9:02 AM C. M. Heard <[email-masked] <mailto:[email-masked]>> wrote:
>>> 

A tunnel would protect it all, not just the UDP data.

> ...
> Tunnel use is nothing compared to 1B+ users of QUIC/IPv6 coming up in China. IMO IETF should be optimizing for them.

It’s a choice. If you are tunneling, you don’t need OCS on UDP packets *inside* the tunnel. If you aren’t, you do. QUIC/IPv6 would presumably use UDP CS !=0 anyway.

> You are referring to RFC6935 and RFC6936. These were created because of routers don't have sufficient hardware to compute payload checksum. That same hardware is unlikely to support protocol trailers which AFAIK are still required by UDP options.

The case we’re talking about runs UDP with options *inside* something else that is already checksummed. It’s the “something else” those routers need to support, not UDP options per se.

If UDP options are part of the tunnel wrapper they would have UDP CS !=0 anyway.

Joe

---

From: "C. M. Heard" <[email-masked]>
Date: Thu, 2 Sep 2021 13:25:22 -0700

> present; that’s safer than throwing an error when present)

Speaking just for myself, of course, I do not see a need to specify any
particular placement or alignment of OCS when UDP CS!=0.

The reason is that the receiver knows by looking at UDP CS whether the OCS
validation should or should not be done, and then it DOES NOT MATTER where
the OCS TLV resides or whether it is aligned. And when that validation
needs to be done, you just compute the Internet checksum over the options
area and see if it is equal to the ones complement of the length of the
options area. If it is, accept the options; if it is not. discard the
options. That works irrespective of where the OCS TLV is placed and how it
is aligned.

This may get mildly more involved in the presence of checksum offload; but
not much more, and not to the point of having to inspect a single TLV or
parse any part of the options area in order to validate OCS. If that's not
clear I can provide details.

What I find objectionable is not imposing alignment and placement
requirements on a transmitter, but rather imposing requirements that a
receiver should verify that those requirements are satisfied (or even that
exactly one OCS TLV is present). My position is that we should say that the
OCS validation requirements are satisfied if the Internet checksum of the
options area is equal to the ones complement of the options length,
irrespective not only of alignment and placement of the OCS TLV, but also
whether the number of such TLVs. In my experience, it does not pay to force
an implementation to spend code and cycles looking for weird cases that are
not actually harmful. For comparison, consider the weird but harmless
pathologies in Section 4.5 of RFC 8200 following the words "[t]he following
conditions are not expected to occur frequently but are not considered
errors if they do." There is lots of pain and little gain in policing this
stuff, and we shouldn't ask implementations to do so.

FWIW I see no value in allowing UDP CS=0 but then requiring that OCS be
validated. Granted, the biggest evil is making it optional (and thus
forcing me to parse through the option TLVs to decide whether or not to
validate it), but making it mandatory compromises whatever value there may
be for UDP CS=0 (tunnels, primarily, as Joe points out). RFC 1122 permits
an application to have a user-selectable mode that discards all UDP
datagrams with CS=0; that seems protection enough.

Thanks

Mike Heard

---

From: Tom Herbert <[email-masked]>
Date: Thu, 2 Sep 2021 14:08:18 -0700

On Thu, Sep 2, 2021 at 1:25 PM C. M. Heard <[email-masked]> wrote:
>
> On Thu, Sep 2, 2021 at 11:21 AM [email-masked] <[email-masked]> wrote:
>>
> Speaking just for myself, of course, I do not see a need to specify any particular placement or alignment of OCS when UDP CS!=0.
>
> The reason is that the receiver knows by looking at UDP CS whether the OCS validation should or should not be done, and then it DOES NOT MATTER where the OCS TLV resides or whether it is aligned. And when that validation needs to be done, you just compute the Internet checksum over the options area and see if it is equal to the ones complement of the length of the options area. If it is, accept the options; if it is not. discard the options. That works irrespective of where the OCS TLV is placed and how it is aligned.
>
> This may get mildly more involved in the presence of checksum offload; but not much more, and not to the point of having to inspect a single TLV or parse any part of the options area in order to validate OCS. If that's not clear I can provide details.
>
> What I find objectionable is not imposing alignment and placement requirements on a transmitter, but rather imposing requirements that a receiver should verify that those requirements are satisfied (or even that exactly one OCS TLV is present). My position is that we should say that the OCS validation requirements are satisfied if the Internet checksum of the options area is equal to the ones complement of the options length, irrespective not only of alignment and placement of the OCS TLV, but also whether the number of such TLVs. In my experience, it does not pay to force an implementation to spend code and cycles looking for weird cases that are not actually harmful. For comparison, consider the weird but harmless pathologies in Section 4.5 of RFC 8200 following the words "[t]he following conditions are not expected to occur frequently but are not considered errors if they do." There is lots of pain and little gain in policing this stuff, and we shouldn't ask implementations to do so.
>
> FWIW I see no value in allowing UDP CS=0 but then requiring that OCS be validated. Granted, the biggest evil is making it optional (and thus forcing me to parse through the option TLVs to decide whether or not to validate it), but making it mandatory compromises whatever value there may be for UDP CS=0 (tunnels, primarily, as Joe points out). RFC 1122 permits an application to have a user-selectable mode that discards all UDP datagrams with CS=0; that seems protection enough.

Mike,

That contradicts established convention and other uses of Internet
checksum. If a checksum is optional it is the choice of the _sender_
whether to use checksum, _not_ the receiver to make it optional. If a
checksum is present, it's incumbent on the receiver to validate the
checksum before accepting the packet. In other words, if a sender did
all the work to compute and set a checksum in the packet, the
expectation is obviously that it wants the receiver to validate it's
not just ignore it and pretend everything is okay. In any case, if the
checksum is always required when UDP CS!=0 and never required when UDP
UDP CS==0 then just make the checksum a two byte fixed header in the
former case that does not appear in the prior-- that way a sender
never sends a checksum when UDP CS==0, always sends it when UDP CS!=0
and two bytes are saved in that case (no length, type for checksum
TLV).

Also there seems to be some confusion on this point, but in the case
of a UDP tunnel with checksum is zero then the assumption is that the
UDP payload may contain its own integrity checks that serve to mostly
validate the same data that a UDP checksum would, but neither UDP
checksum nor any encapsulated integrity checks offer any protection of
the IP surplus space. If you want to protect UDP options against
corruption then its own mechanism is needed.

Tom

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 2 Sep 2021 14:21:34 -0700

—

> On Sep 2, 2021, at 2:08 PM, Tom Herbert <[email-masked]> wrote:
> 

We have that mechanism - OCS. There are three cases:

	- when UDP with options is a payload in another layer with sufficient protection
		in that case, UDP CS==0 and OCS is not used (absent or “zero”)

	- when UDP with options carries a payload with its own sufficient protection
		in that case, UDP CS==0 and OCS!=0

	- when UDP with options is itself lacking sufficient protections overall
		in that case, UDP CS!=0 and OCS!=0

I see no reason to prohibit any of the three.

It seems fine to include OCS in all cases, where OCS==0 is the signal that OCS is being ignored.

Then the question becomes how to represent OCS. If it’s in a fixed location, then we can use zero to omit it, but we need to decide on alignment.

The trouble with alignment is that most headers assume at least 4-byte alignment, so do we too? Or, given it won’t matter in the way it zeroes out surplus space (and difference in UDP payload length vs. IP length minus headers), do we just put it in the first two bytes and then allow NOPs for alignment of the remainder as desired?

Joe

---

From: "C. M. Heard" <[email-masked]>
Date: Thu, 2 Sep 2021 15:10:37 -0700

On Thu, Sep 2, 2021 at 2:21 PM Joe Touch wrote:

> Then the question becomes how to represent OCS. If it’s in a fixed
> location, then we can use zero to omit it, but we need to decide on
> alignment.
>

That would answer my major objection to supporting OCS present when UDP
CS==0, which is forcing the receiver to fish through a bunch of option TLVs
in order to figure out whether to attempt to validate OCS. That being said,
I consider this a corner case with little operational value (think checksum
offload and whether there is really a use case for a tunnel to use UDP
options, especially in a trailer).

The trouble with alignment is that most headers assume at least 4-byte
> alignment, so do we too? Or, given it won’t matter in the way it zeroes out
> surplus space (and difference in UDP payload length vs. IP length minus
> headers), do we just put it in the first two bytes and then allow NOPs for
> alignment of the remainder as desired?
>

I think that could work. There would be no need for OCS to be a TLV at all,
which eliminates the possibility of too few or too many OCS TLVs.

Receive checksum offload is about the same as with the TLV version of OCS:
the hardware computes the composite checksum over the entire IP payload,
and the software computes whichever of UDP CS or OCS involves less effort.
In the case of UDP CS==0 there is an additional check for OCS==0.

Transmit checksum offload: in case of an options trailer, OCS is
pre-computed in SW and the main UDP checksum is offloaded (after populating
the UDP CS field with the UDP pseudo-header). In the case where UDP Len ==
8, the UDP checksum is precomputed in SW and OCS is offloaded (after
populating it with a UDP pseudo-header that uses the IP payload length).
That works because OCS comes out aligned when UDP Len == 8. In this case
UDP CS==0 and OCS!=0 offload would still work but would require
pre-compensation for the value of the UDP header. IN the trailer case
transit offload would in general need to be turned off when  UDP CS==0 and
OCS!=0.

There is also the possibility of an aligned options header that includes
the option checksum, as Tom Herbert has previously proposed; it would in
general use more space because of padding for alignment.

Mike Heard

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 2 Sep 2021 15:49:08 -0700

—

> On Sep 2, 2021, at 3:10 PM, C. M. Heard <[email-masked]> wrote:
> 
> There is also the possibility of an aligned options header that includes the option checksum, as Tom Herbert has previously proposed; it would in general use more space because of padding for alignment.
> 

Although that’s possible, there’s no real utility AFAICT. Other than OCS, there’s no repeating fields, except as conditional optimizations (e.g., when the user data is zero, we hope we know it must have FRAG, but then we’re back to the pre/post frag issue).

Joe

---

From: "C. M. Heard" <[email-masked]>
Date: Thu, 2 Sep 2021 16:52:47 -0700

On Thu, Sep 2, 2021 at 3:49 PM Joe Touch wrote:

> Other than OCS, there’s no repeating fields, except as conditional
> optimizations (e.g., when the user data is zero, we hope we know it must
> have FRAG, but then we’re back to the pre/post frag issue).
>

Actually, that last is not quite true. DLPMTUD probe packets would
typically consist of some control options (REQ / RES and possibly TIME)
followed by enough EOLs to inflate them to the desired size; a FRAG option
is not needed for that.

Mike

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 2 Sep 2021 17:09:12 -0700

—

> On Sep 2, 2021, at 4:52 PM, C. M. Heard <[email-masked]> wrote:
> 
> Other than OCS, there’s no repeating fields, except as conditional optimizations (e.g., when the user data is zero, we hope we know it must have FRAG, but then we’re back to the pre/post frag issue).
> 
> Actually, that last is not quite true. DLPMTUD probe packets would typically consist of some control options (REQ / RES and possibly TIME) followed by enough EOLs to inflate them to the desired size; a FRAG option is not needed for that.

By “repeating” I mean fields that always occur in different packets, regardless of which options are being used (repeating across different socket UDP option configurations).

Within a single packet, only one field should ever repeat - NOP, and only up to 7 in a row. There should only be one EOL. Everything after the EOL (e.g., padding) must be zero, but doesn’t represent repeating NOPs.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Fri, 3 Sep 2021 07:34:07 -0400

> alignment of the remainder as desired?

When UDP options immediately follows the UDP header it is naturally aligned
to four bytes. When they follow user payload then it would be better to
have preceding padding to align to four bytes. Options other than checksum
can have alignment restrictions, and if the UDP options is guaranteed to be
four byte aligned this means we can use the just copy a block of options
for each packet in a flow, otherwise the options list needs to be
constructed for each packet.

Implementations already do this for IPv6 HBH and destination options where
options are set on a socket and the options block with necessary padding is
constructed just once. When a packet is sent on the socket the block is
copied into the packet such that options in packets in a flow always have
the same order and consistent format and this is good for performance.

Adding a few bytes (up to three only in the legacy mode) for alignment is
inconsequential relative to the benefits. Also, if the alignment padding
precedes the checksum then the odd align checksum problem goes away and the
byte swap is unnecessary to specify.

Tom