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

[Tom Herbert <[e-mail]>]

On Sun, Jul 2, 2023, 2:13 PM C. M. Heard <[e-mail]> wrote:

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

Considering that this is a new protocol for which there is no deployment
and no one yet understands all the security and deployment ramifications,
just saying "let the user decide" seems trite to me without providing some
meaningful guidance. The discussions about the interactions with UDP
checksum and RFC6936, and firewalls have been very nuanced and complicated
to the extent that I wouldn't know the conditions that it's safe to not use
a surplus checksum in my deployment-- I think a typical user trying to
figure this out for their deployment would be lost.

So, to simplify the things, I'd like to suggest this text:

"By default, an implementation MUST send the OCS and an implementation MUST
expect and validate the OCS checksum on receiving UDP packets with a
surplus area. An implementation MAY allow the OCS to be configurable to
both send and validate in receive. A user should fully consider the risks
and ramifications of disabling the surplus area checksum, especially the
risks of misinterpreting surplus area as containing UDP options when in
fact it contains unrelated data"

So basically, this is saying that if the user decides to disable the
surplus area checksum they are doing it at their own risk. This could apply
across use cases, so there's no need to tie this to the UDP checksum being
zero, nor reference RFC6936. If there are concerns about some firewalls
that want the surplus area to be checksummed, that can be mentioned as one
thing that should be considered, but if user wants to disable checksum
anyway they can.

Tom




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