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

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 31 Aug 2021 11:17:13 +0100

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.
- 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).
===
In section 5.3: OCS:
The Option Checksum (OCS) option is conventional Internet checksum
    [RFC791]
- Insert a word: “the” or “a” before “conventional”.
- 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?
====
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?
===

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?
===

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?
- How does this relate to the NOPs statement earlier?
- 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?)

---

From: Tom Herbert <[email-masked]>
Date: Tue, 31 Aug 2021 09:09:48 -0700

> 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.

> NOP padding before OCS. (See more on this topic later).

Or more generally, if anything appears before the option that
increases the chances that the OCS might be missed and a corrupted
packet is accepted. As I've noted many times on the list, putting an
optional checksum in a TLV reduces the effectiveness of the checksum
to detect corruption.

>     >> When present, the OCS SHOULD occur as early as possible, preceded

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.

Tom

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 31 Aug 2021 17:42:43 +0100

See below Tom,

On 31/08/2021 17:09, Tom Herbert wrote:
> to be first. A receiver has to be prepared for that.

I'm not sure this is so. An offload engine could validate the OCS and 
return the result. Since the   OCS MUST be included when the UDP 
checksum is nonzero and UDP options are present, this to me, seems 
worthwhile.

The host could use that result, in combination with parsing the TLV to 
complete the processing. From what  read, the TLV is normally at the 
start, the draft says ">> When present, the OCS SHOULD occur as early as 
possible, preceded by only NOP options for alignment."

The offload knows where to look (if the sender does as recommended). If 
the TLV were to be malformed, or not where expected, then the offload 
hasn't done useful work in this particular case.

> If the idea is

So, to be sure I understand: including exactly either none or one NOP 
before the OCS to achieve 16-bit alignment will help in the case of offload?

And I think you suggest that a byte swap would NOT be helpful to offload?

Gorry

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 31 Aug 2021 10:51:22 -0700

Trying to catch these in order…

—
Joe Touch, temporal epistemologist
www.strayalpha.com

> On Aug 31, 2021, at 3:17 AM, Gorry Fairhurst <[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:
> 
> - 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).

> - 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.

> - 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.

> - 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.

> - 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.

> - 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.

Joe

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 31 Aug 2021 11:01:33 -0700

—

> On Aug 31, 2021, at 9:09 AM, Tom Herbert <[email-masked]> wrote:
> 
> As I've noted many times on the list, putting an

For UDP CS not zero, it has no effect.

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.

Joe

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 31 Aug 2021 20:42:21 +0100

On 31/08/2021 18:51, [email-masked] wrote:
> 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:
>>
>> - 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.
>
> if surplus checksum is zero, either OCS worked or you got “lucky” with 
> a zero sum, but either way 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).
>
>> misplaced, and detect a zero. That might suggest a good reason to 
>> avoid NOP padding before OCS. (See more on this topic later).
>
OK - this was explained elsewhere, no worries here.
>> 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?
> Again, this being a user protocol, IMO, let the user decide if this is 
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.
>> - I think more is needed to undersand what is implied by 
>> “coordinated”. Could that word be explained here?
>
Hmmm... so allowing two ways seems to fight against methods for 
offloading, I think that consideration should be weighed carefully.
>> - 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?

Gorry

---

From: Tom Herbert <[email-masked]>
Date: Tue, 31 Aug 2021 14:09:55 -0700

On Tue, Aug 31, 2021, 3:42 PM Gorry Fairhurst <[email-masked]> wrote:

> if surplus checksum is zero, either OCS worked or you got “lucky” with a
> zero sum, but either way keep the options
> - 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).
>
>
> - 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:
> - 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?
>
>
> Not everyone uses offload; this allows for an optimization for non-offload
> users who don’t want to use a NOP pad before OCS.
>

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

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 31 Aug 2021 16:15:22 -0700

In the current draft (-13), OCS is a 4-byte option and can be at any alignment, preceded by 0-7 NOPs as desired by the transmitter.

Joe

—

> On Aug 31, 2021, at 2:09 PM, Tom Herbert <[email-masked]> wrote:
> 
> 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

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 31 Aug 2021 16:25:51 -0700

Notes below >JT tagged
—

> On Aug 31, 2021, at 12:42 PM, Gorry Fairhurst <[email-masked]> wrote:
> 
> On 31/08/2021 18:51, [email-masked] <mailto:[email-masked]> wrote:
>> www.strayalpha.com <http://www.strayalpha.com/>
>> 
>>> On Aug 31, 2021, at 3:17 AM, Gorry Fairhurst <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> ...
> We'd need to be clear. If we allow 0=don't check, then we can make the OCS mandatory?

If we do, we’re putting unnecessarily load on software-based implementations, which are where that cost is most expensive (esp. low-power devices).

> 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.

The trade is unambiguity vs. overhead. Do we pick 2-byte, 4-byte, or 8-byte alignment? That’s the problem with optimizing for hardware, IMO.

> Hmmm... so allowing two ways seems to fight against methods for offloading, I think that consideration should be weighed carefully. 

I don’t see it affecting offloading; it just affects what gets put in the OCS checksum field. The odd-byte needs to be in the odd-byte place, the even in the even. That means swapping the bytes if the location of the field is not half-word aligned..

> To me, this is one we should continue to discuss a little more. I think the tradeoff is:
> 
> or (b) burn one byte of NOP when mis-aligned and enable potential easier offload.
> 
Possibly, but the NOP needs to be checked if it’s there anyway, negating the effect of the swap code (which is almost always a single 1-cycle opcode these days, given it’s already prevalent in other net header processing).
> Are there many cases where this misalignment would actually occur? How many IPv6 EH (etc) result in an odd byte alignment? Any?
> 
There are shim layers that may have impact as well.

Joe

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 31 Aug 2021 16:33:39 -0700

Ignore the tag note; my mail removed them (I think they weren’t’ ASCII).
—
Joe Touch, temporal epistemologist
www.strayalpha.com

> On Aug 31, 2021, at 4:25 PM, [email-masked] wrote:
> 
> Notes below >JT tagged
> —
>> On Aug 31, 2021, at 12:42 PM, Gorry Fairhurst <[email-masked] <mailto:[email-masked]>> wrote:
>>