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

[Gorry Fairhurst <[e-mail]>]

On 28/06/2023 15:35, Tom Herbert wrote:
> On Tue, Jun 27, 2023 at 11:59 PM Gorry Fairhurst <[e-mail]> wrote:
>> On 27/06/2023 21:45, Tom Herbert wrote:
>>> On Tue, Jun 27, 2023 at 2:15 AM Gorry Fairhurst <[e-mail]> wrote:
>>>> On 26/06/2023 23:13, Tom Herbert wrote:
>>>>> On Mon, Jun 26, 2023 at 2:47 PM C. M. Heard <[e-mail]> wrote:
>>>>>> On Mon, Jun 26, 2023 at 12:59 PM Tom Herbert wrote:
>>>>>>> On Mon, Jun 26, 2023 at 10:17 AM C. M. Heard wrote:
>>>>>>>> I believe that the issue was originally stated as:
>>>>>>>>
>>>>>>>> Section 7: Resolution is needed whether the OCS 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. See:
>>>>>>>>
>>>>>>>> https://mailarchive.ietf.org/arch/msg/tsvwg/YvGoCxtsqVqx_nsfR7_IErRInZM/
>>>>>>>>
>>>>>>>> I note that there is a use case (fully reassembled datagrams, see
>>>>>>>> Section 9.4) where this concern would not apply.
>>>>>>> Yes. The primary concern here is UDP packets that are received on the
>>>>>>> wire with surplus space and UDP length != 8 (not fragments or
>>>>>>> reassembled packets).
>>>>>> And also (if I correctly understood what you wrote), the presence or
>>>>>> absence of OCS, not UDP CS.
>>>>> 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 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.
>>>> 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. I
>>>>
>>>> - 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.
>>>>
>>>> - 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.
>>>>
>>>>
>>>>> 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
>>>>>
>>>>> Tom
>>> Hi Gorry,
>>>
>>>> - 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?
>>> Is it okay for a sender that is not able to generate a TCP checksum
>>> over the checksum area to send a zero TCP checksum? ;-)
>>>
>>> Anyway, the short answer to your question is "no". If it were
>>> generally okay for devices that don't support checksum to do it, then
>>> it should be okay for all devices which is not true unless it can be
>>> demonstrated that there is zero risk in not using a checksum in all
>>> use cases. 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.
>>>> ... 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.
>>> I'm not sure what you mean, but RFC6936 only covers the case when
>>> UDPv6 is used for tunneling; there is no consideration in that RFC for
>>> checksumming the UDP surplus area.
>> 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 dame endpoint where the UDP datagram is reassembled. The OCS covers an individual fragment and the operation is similar to IPv6 fragmentation.
>>
> Perhaps, but again RFC6936 is about use of UDPv6 CS=0 for tunneling,
> use of UDP Options or UDP fragmentation is not generally a form of
> tunneling and RFC6936 says nothing about surplus space checksum. There
> may be an argument that a UDP CS=0 could be used with UDP Length=8
> with some logic similar to RFC6936, but as I said that needs to be an
> update to RFC8200.
That decision about whether this changes RFC8200, would eventually need 
to be put to the 6man WG.
> But, even if the zero UDP checksum is allowed in
> that case then there should be a separate analysis of the risk of
> mis-interpreting something as a UDP Options fragment. So under these
> conditions I believe it might be acceptable to not have a surplus area
> checksum to appease those devices that can't compute checksums.
Being able to reject bogus fragments before the final re-assembled 
packets is sent up the stack seems important.
> In
> other cases, particularly when UDP Length <> 8, I believe that the
> surplus area checksum (or at least a magic number) is a MUST needed to
> address the risk of misinterpretation of the surplus area.
>
I think you are suggesting that the options space ought to be protected, 
even when the payload is not.

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?

>>>> 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.
>>> 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?
> It's the UDP packet containing UDP Options that crosses firewalls. I
> believe the reason that OCS is required when UDP CS is non-zero is
> because some firewall validate the UDP checksum and assume the
> checksum area goes to the end of the packet instead of end of UDP
> length

I am unsure: I see a firewall could have a rule to discard a packet to 
discard  a UDP datagram with  a checksum of zero (some do by default).

If it does not have that rule, then it ought not to compute a UDP 
checksum, and the OCS has no additional value in assuring a correct 
checksum is reached.

>>> If the intent is to allow UDP
>>> CS=0 when UDP Length=8, then I believe that is an update to RFC8200
>>> (fragmentation is not equivalent to tunneling). On the other hand,
>>> there is still a risk in the fragmentation case. It's conceivable that
>>> someone might send a packet with UDP Length=8 and some non-UDP Options
>>> surplus. If that packet is interpreted as a fragment it may be
>>> reassembled and some UDP payload with nonsensical data may be
>>> delivered (i.e. result would be a data corruption)
>> See previous reply: As I understood, there is no desire to allow new
>> cases where a zero UDP checksum is permitted.
>>
>>> An alternative to checksum for those devices that can't support it,
>>> may be to include a magic number in the fixed header to identify UDP
>>> Options. If that is something like a 64-bit pseudo-random number that
>>> should give pretty good confidence that UDP Options won't be
>>> misinterpreted, but obviously offers no integrity check over the
>>> surplus area.
>>>
>>> Tom
>> Gorry
>>>> Gorry
>>>>
>>>>>> Mike

Gorry