Re: [tsvwg] UDP options and header-data split (zero copy)

[Joseph Touch <[e-mail]>]

> On Aug 1, 2021, at 12:03 PM, Tom Herbert <[e-mail]> wrote:
>> ...
>> Again, that means that the FRAG option itself would float far inside the TLV list, which complicates DMA.
>> 
> I don't understand your concerns. The method I am describing is
> functionally equivalent to how fragmentation is done in IPv6. There is
> a fragment extension header that "floats" inside the IPv6 header
> chain, options that are before the fragment extension header are
> applied per packet and those after the extension header are applied to
> the reassembled packet. This is no issue with DMA since there are no
> trailers and we can use header-data split with fragments.

We moved the FRAG header to the front due to previously expressed concerns - notably long TLV processing prior to DMA.

>> Also, the trailing variant allows per-reassembled options to be arbitrarily long (limited by the reassembled length), rather than requiring them to fit inside a single fragment.
>> 
>> That’s a key reason for using trailing options - no limit on length, even with fragmentation. That’s why we need a version that allows that, otherwise the options would be limited to what will fit in exactly one option.
>> 
> Deployment experience has shown arbitrarily long lists of TLVs in a
> datapath protocol is more a problem than a benefit. Implementations
> have a lot of trouble with these and to date the only use case for
> this is DoS attack.

The issue isn’t just whether it’s arbitrarily long; it’s also that it’s restricted to a single fragment, which could be quite small.
>> ...
>> We need to keep a way to allow arbitrary option lengths;
> 
> Why? Can you provide a *specific* example of an option or set of
> options that needs hundreds of bytes of options?

Had we limited the option length as a few suggested when this work started, we would not have FRAG.

We don’t know what others are, but we also don’t know that the first frag will have hundreds of bytes of available space either.

...
>> We’ve been down the path of fixed headers before.
> 
> And we've been down the path of protocols that allow arbitrarily long
> lists of TLVs. See IPv6 Hop-by-Hop options and Destination options.
> There is about no deployment of these and a major reason is that
> implementations efficiently implement necessary support.

RFC8504 discusses these; they are all MAY limits via receiver configuration, notably that the default is that it accepts both sets of options of any length.

Your suggestion would limit options by design, not receiver configuration.

>> It wastes space for some uses to conserve it for others. E.g., in tunnel cases where UDP CS==0, it would waste space for OCS when not needed.
> 
> Somehow the whole purpose of having a checksum in protocol is lost in
> this draft. The point of a checksum is that it's an integrity check of
> the protocol. Frankly, the requirements described in the draft seem
> more concerned with making sure the checksum is set properly to
> packets to get through some misbehaving routers on the Internet. The
> argument that UDP Options doesn't need a checksum is disingenuous
> given that UDP doesn't have options in the first place so making the
> checksum required in UDP to cover options; however the other major
> transport protocol of IETF, namely TCP, has a checksum that always
> covers TCP options. Similarly, the argument that the IPV6 UDP tunnels
> can have a zero checksum is disingenuous. If you read RFC6935 and
> RFC6936 you'll find that the conditions for which a zero checksum can
> be safely set are quite narrow. One of those conditions is if the
> encapsulated protocol has an integrity check of its own.

Yes, but that’s actually the dominant case where Mike’s optimization fails, i.e., where UDP CS==0 but OCS is optional. In that case, if OCS fails, the TLV chain still needs to be checked to decide whether to drop the packet. It’s only when it succeeds that it need not be checked.

> IMO, a checksum should always be required over the surplus area.

This, like the proposal for fixed headers, has already been discussed.

New discussions would be useful; rehashing previous ones can probably be left to the interim.

Joe