Re: [tsvwg] Remaining issues for draft-ietf-tsvwg-udp-options-22

["C. M. Heard" <[e-mail]>]

Greetings,

To follow up on the OCS discussion:

1. I remain convinced that the following normative requirements are the
right ones:

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

though I think it is appropriate to add a capability for the application
to control the behaviour when OCS is unused (see point #4 and subsequent
discussion below).

2. I endorse adding a warning that if OCS is unused in a UDP datagram
with a non-empty surplus area, then in the absence of other assurances
that the surplus area actually contains options, there is a possibility
of the surplus area being misinterpreted to contain UDP options when
it actually contains unrelated data. And if it's not already obvious,
also warn the user that in the absence of other integrity checks, not
using OCS leaves the surplus area vulnerable to corruption from
transmission errors.

3. I think that a warning is sufficient, and I do not endorse making OCS
mandatory in any case when UDP CS == 0. Having warned the user of the
consequences, I would then follow Joe's dictum to "let the user decide."

4. In order to actually let the user decide, it would be necessary to
provide a means for the application layer to ask that a surplus area
with OCS == 0 be discarded unless the UDP layer can determine that it
is protected by other known integrity checks. "Other known integrity
checks" would obviously include the protection reassembled datagrams
receive when UDP fragments that are themselves protected by OCS
(clearly, these fragments, and the data within them, originate from
the same options-aware source, so there is no question of the surplus
area of either the fragments or the reassembled datagram fortuitously
containing unrelated data). In this case both the payload and the
surplus area of the reassembled datagram are protected by the OCS on the
fragments. Cases where there would be no other known integrity checks --
at least as far as the UDP layer is able to determine -- would include
UDP packets received off the wire with a surplus area that has OCS == 0.
These packets could be UDP fragments (UDP length == 8 with a FRAG option
present), PLPMTUD probe packets or probe responses (UDP length == 8
with a REQ option and padding or a just RES option), or complete
UDP datagrams with user data and a surplus area. The application layer
would need to have the ability to invoke this switch independently for
each 5-tuple.

In order to cover all known cases of interest, it would also be
necessary for the application layer to have a means to ask that UDP
packets received on the wire with CS == 0 be discarded; this should
also be specifiable independently for each 5-tuple. This switch would
default to ON for UDP over IPv6 (aka UDPv6) and to OFF for UDP over
IPv4 (aka IPv4) in order to be consistent with existing practice. Such
a switch is mandated by RFC 6936 for implementations of UDPv6 that allow
UDP CS == 0, and it is allowed by RFC 1122 for implementations of UDPv4.

Here are the behaviours for the various combinations these switches:

A.) Discard packets with UDP CS == 0 if received on the wire: in this
case the surplus area of all on-the-wire packets with OCS == 0 will be
discarded as a consequence of discarding packets with UDP CS == 0, so
the state of the switch in #4 above does not matter. That would apply
both to complete UDP datagrams and UDP fragments. Both the user data and
the surplus area of UDP datagrams that are reassembled from fragments
that are accepted are protected by the OCS on the fragments, and such
datagrams are known to come from an options-aware source; thus, the
surplus area of reassembled datagrams with OCS == 0 would be accepted
(i.e., sent to the options processing logic for further examination).

B.) Accept packets with UDP CS == 0 if received on the wire, discard
any surplus area with OCS == 0 unless protected by other known integrity
checks: both complete UDP datagrams and UDP fragments received on the
wire will have the surplus area discarded if OCS == 0, irrespective of
the UDP CS value. A datagram that is reassembled from fragments will
have its surplus area discarded if OCS == 0 unless all fragments have
OCS != 0 (this last stipulation could be relaxed if the reassembly
machine keeps track of the byte ranges in the reassembled packets that
came from fragments with OCS != 0, but IMO it is an unreasonable
burden to require of an implementation).

C.) Accept packets with UDP CS == 0 if received on the wire, accept
any surplus area with OCS == 0 or OCS that passes: this allows both
fragments and full datagrams received on the wire with UDP CS == 0 and
OCS == 0 to be accepted in full, though OCS may be calculated at the
option of the sender and must be checked if it is. Similarly, a
reassembled datagram will be accepted even if OCS == 0 in one or more
constituent fragments, and its surplus area will be accepted even if
OCS == 0, though an OCS may be calculated at the option of the sender
and must be checked if it is.

I would now like to reply to some points in the prior discussion

On Mon, Jun 26, 2023 at 8:16 AM Tom Herbert started things with:
> On Mon, Jun 26, 2023 at 2:03 AM Gorry Fairhurst wrote:
> > Are there other key issues?
>
> Section 7: Resolution is needed whether the UDP checksum should be
> mandatory in all cases where UDP length != 8 in order to be robust to
> sufficiently discriminate the presence of UDP Options from other
> potentially preexisting or inadvertent uses of the UDP surplus space.

AFAICT, it is not correct to single out UDP length != 8 as the only case
where preexisting or inadvertent uses of the UDP surplus space could
be seen and have effects. As a consequence, my point #2 above does not
make reference to this condition. That being said, support for UDP
fragmentation by RFC6936-style tunnels requires the behaviour described
in (C) only for UDP fragments, which have UDP Length == 8.

On Tue, Jun 27, 2023 at 2:15 AM Gorry Fairhurst wrote:
> On 26/06/2023 23:13, Tom Herbert wrote:
> > Yes, IMO the OCS should not be optional and hence should always be in
> > a fixed header at the beginning of the surplus area for UDP options.
> >
> > In the current draft, the OCS is required if the UDP CS is zero,

That should say "the OCS is optional if the UDP CS is zero"

> > which is only possible in the case of IPv4 or some narrow use cases
> > when UDPv6 is used with tunnels. As I mentioned previously, there is
> > no correlation between the UDP checksum and a checksum in the surplus
> > area. If the sender chooses to send a zero UDP checksum that the
> > implication is that either there are sufficient mechanisms to ensure
> > integrity of the UDP payload or that the risks of misdelivery with a
> > zero UDPv6 checksum are understood and mitigated; the use of a zero
> > UDP checksum has no bearing on the risks of the UDP surplus area being
> > misinterpreted to contain UDP options when it contains unrelated data.

And it is entirely appropriate to provide a warning for that.

> I note that text in draft-ietf-tsvwg-udp-options-22, I think does place
> the OCS at fixed location and 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."
>
> - Which I understand as the OCS value is required when the UDP checksum
> is non-zero.
>
> - My understanding of the second requirement here is when the checksum
> is zero, the OCS has no impact on the NAT traversal - since a zero
> checksum is usually passed by a NAT.

When UDP CS != 0 it's certainly true that OCS needs to be non-zero in
order for UDP Options to have a decent chance to traverse middleboxes,
and when UDP CS == 0, it is also true that UDP Options have no impact
on middlebox traversal. This is supported by empirical data; see

https://datatracker.ietf.org/meeting/103/materials/slides-103-maprg-a-tale-of-two-checksums-tom-jones

and

https://tma.ifip.org/2020/wp-content/uploads/sites/9/2020/06/tma2020-camera-paper70.pdf

Note that the data reported in the references cited above do not allow
definite conclusions to be made about NAT and UDPv6 with CS == 0, since
the end-to-end drop rate for UDPv6 with CS == 0 is very high and may be
primarily due to endpoints, not middleboxes. Still, UDP options do not
seem to make a noticeable difference in the end-to-end success rate.

Another important consideration for having OCS != 0 when UDP CS != 0 is
that it is essential to enable protocol-agnostic checksum offload. See

https://mailarchive.ietf.org/arch/msg/tsvwg/9_1YWp-TApI9mcCuia8U6jfCwTA/

and

https://datatracker.ietf.org/meeting/113/materials/slides-113-tsvwg-71-checksum-offload-00

A third reason is to provide a comparable level of protection against
transmission errors for both UDP user data and UDP options, just as the
TCP checksum provides for TCP user data and TCP options.

All of these are good reasons to require OCS != 0 whenever UCP CS != 0.

> - Options integrity is another reason we would need an OCS, as you note
> (quoted from above) " the use of a zero UDP checksum has no bearing on
> the risks of the UDP surplus area being misinterpreted to contain UDP
> options when it contains unrelated data."  I didn't see text about that.

Actually, options integrity is discussed in the draft:

   The OCS consists of a 16-bit Internet checksum [RFC1071], computed
   over the surplus area and including the length of the surplus area
   as an unsigned 16-bit value. The OCS protects the surplus area from
   errors in a similar way that the UDP checksum protects the UDP user
   data (when not zero).

   The primary purpose of the OCS is to detect non-standard (i.e., non-
   option) uses of that area and accidental errors. It is not intended
   to detect attacks, as discussed further in Section 22.

So, the two stated purposes of OCS are: to protect against transmission
errors (accidents) and misinterpretation of possible non-option uses.
Both of these protections are lost if OCS is not used, unless there is
some other means of protection. I agree that a warning is in order.

> > Note, there was never a requirement to not use the surplus area, and
> > as they say "what is not prohibited is allowed", so UDP Options must
> > be robust to properly handle non-UDP Options surplus space. I believe
> > a mandatory checksum would be a sufficient discriminator
>
> - Which could motivate a question about what cases a sender is not be
> able to generate an OCS over the checksum area, and is a zero OCS OK?
> ... and as far as I recall (others can remind us otherwise) the only
> exception seemed to be when the payload contains a fragment of a
> datagram, in which case the reassembly would I hope have a checksum, ala
> RFC6936.

It's actually the other way around: the OCS on the fragments protects
the fragment user data, and thereby protects the reassembled datagram
(including its surplus area), provided that it appears in every fragment.
There is no requirement to compute the UDP checksum of the original
unfragmented datagram, and there is no provision to transmit it. There
would be little, if any, added value, in transmitting the UDP checksum of
the original unfragmented datagram: any error affecting only the fragment
user data (which is typically is most of the content of a fragment) that
would not result in a failed OCS would also not result in a failed UDP
checksum in the reassembled datagram. (That isn't true of APC, which uses
an entirely different algorithm.)

This protection is lost if any of the fragments has OCS == 0.

> However, if a fragment is allowed to have options, this use-case also
> becomes blurred for me - and I agree deserves clarity on when a zero OCS
> is allowed and how protection is provided in this case.

Protection of per-fragment options, if provided, is indicated by having
OCS != 0 on all fragments. If OCS == 0 on any fragment, then the options
in that fragment have no protection, other than what might be provided
against transmission errors by a lower layer.

On Tue, Jun 27, 2023 at 11:59 PM Gorry Fairhurst wrote:
> On 27/06/2023 21:45, Tom Herbert wrote:
> > [...] RFC6935 and RFC6936 show how to carve out exceptions to
> > define conditions in which it is okay to use a zero UPDv6 checksum,
> > but that is hardly trivial and applying that to a particular tunnel
> > protocol still required many requirements (see section 6.2 in RFC8086
> > for what requirements were needed to use a zero checksum in GRE/UDP).
> >
> Including options in the datagram does not change the rules for when you
> are permitted to send a zero checksum. If that isn't clear it ought to be.

That seemed clear to me, and I take that to mean:

- For IPv6, UDP CS == 0 is permitted only when the conditions in RFC
6936 are satisfied. From an implementation standpoint, that means
providing a capability to the application to accept datagrams with
UDP CS == 0.

- For IPv4, UDP CS == 0 is always permitted, though per RFC 1122, "an
application MAY optionally be able to control whether UDP datagrams
without checksums should be discarded or passed to the application."

> RFC6936 does discuss fragmentation by tunels (sect 3.1) which may be
> relevant, since in this proposed spec, the UDP Fragments are all
> passed to the [same] endpoint where the UDP datagram is reassembled.
> The OCS covers an individual fragment and the operation is similar to
> IPv6 fragmentation.

This observation is very relevant because an IPv6 tunnel may find it
advantageous to use UDP fragmentation in place of IPv6 fragmentation to
avoid well-known issues with IPv6 fragments being arbitrarily discarded
in transit. If the same issues that motivated the use of UDP CS == 0 in
IPv6 tunnels remain valid -- in particular, inability of some systems
to process data for only a limited distance into a packet -- then
computing OCS on the UDP fragments would be no more viable than would be
computing UDP CS and then performing IPv6 (outer) fragmentation. So
this would be a use case for OCS == 0. When OCS == 0, the level of
protection on fragmentation control information is the same -- i.e.,
none at all -- for UDP and IPv6 fragmentation. Empirical results are
not conclusive, but the data in the references cited above suggest that
the chance of middlebox traversal for UDPv6 with CS == 0 is unaffected
by the presence of UDP options.

IPv4 tunnels using UDP fragmentation with OCS == 0 may likewise be
useful in situations where the tunnel ingress and egress points have
restricted access to the packet payload and non-initial IPv4 fragments
are not treated properly by the intervening path. In this instance
UDP CS == 0 on the length 8 header is definitely the right thing to do
to maximize the chances of middlebox traversal. Though such tunnels are
not constrained by RFC 6936, common sense suggests that they are
appropriate only in controlled environments where the tunnel endpoints
are known to each other and the transported traffic is robust in the
face of errors that may be introduced in the tunnel.

> > I believe that even when UDP Length=8, the checksum is needed to
> > ensure that packet transits firewalls.
>
> Why is the OCS needed to transit a firewall?

All available evidence suggests that a properly calculated OCS is needed
to transit middleboxes if UDP CS != 0 but not otherwise. I don't know of
any published tests showing that UDP Length == 8 behaves the same as
UDP Length > 8, but I also don't know of any evidence to the contrary.

On Thu, Jun 29, 2023 at 10:37 AM Gorry Fairhurst wrote:
> On 29/06/2023 18:24, Tom Herbert wrote:
> > On Thu, Jun 29, 2023 at 9:19 AM Gorry Fairhurst wrote:
> > > I think you are suggesting that the options space ought to be
protected,
> > > even when the payload is not.
> >
> > Specifically, the surplus checksum is needed when the UDP CS=0. The
> > user may justify setting the UDP CS to zero since there are other
> > mechanisms in the UDP payload that protect the payload. Having an
> > alternative method to protect the payload is one of the requirements
> > in RFC6936, but the use of such a mechanism obviously wouldn't protect
> > the surplus area.
>
> I understand that logic.
>
> > > Hence when the payload is corrupted, or the surplus area was be used
in
> > > some other way - this would mean that a UDP options receiver would
still
> > > intrepet the surplus part. That seems plausible, and motivate that the
> > > OCS ought to be calculated when UDP Length <> 8. Is that correct?
> >
> > Yes.
>
> OK, then to me, this is a better understanding of why we need this.

Except that this has nothing in particular to do with UDP Length <> 8. The
same considerations apply when UDP Length == 8. It's just that in the latter
case we need to allow OCS == 0 in order to support RFC6936-style tunnels.

> I still don't see an OCS as useful to traversing NAT/Firewall when the
> UDP CS is zero.
>
> Because, there is no checksum to update by the OCS value when the
> checksum was suppressed by the sender setting the value to zero.

That, I think, is correct.

> Data  is in Sect IV.B  of
> https://dl.ifip.org/db/conf/tma/tma2020/tma2020-camera-paper70.pdf.

This is the same reference that I mentioned above.

Mike Heard