Re: [tsvwg] draft-ietf-udp-options issues from IETF 104

[Tom Herbert <[e-mail]>]

On Tue, Jul 16, 2019 at 2:25 PM Joe Touch <[e-mail]> wrote:
>
> Focusing on the end part...
>
>
>
> On 2019-07-16 13:42, C. M. Heard wrote:
>
> In-line followups where where they seem to be warranted.
>
> ...
>
> > Many of these simply won't work as automatically legacy-compatible with
> > draft-herbert; the legacy data can easily exceed its limits, at a minimum.
>
> My take (as stated in the long message) is that we probably want both the
> trailer format pretty much as defined in draft-ietf-tsvwg-udp-options-07
> for the backward compatible / safe to ignore  options (MSS, TIME, REQ, RES,
> dummy FRAG used for negotiation) and and a variant of the header format as
> defined in draft-herbert for the others.
>
>
> Safe-to-ignore needs the current structure, which isn't draft-herbert compatible (because data can easily exceed the limit).
>
> udp-options in general aren't draft-herbert compatible because we do not have (nor IMO do we want) a strict limit on using the option length for udp-options.

IPv6 extension headers began without a limit, and then we realized we
needed to limit them to fit into one MTU, and then we realized that
unbounded limits are a good DOS attack vector so we added more limits
to the receiver which are now default in Linux. Saying that we need
unlimited options is an academic statement and doesn't reflect
realities of deplyment.

If needed, it's easy enough to extend USH with an type that indicates
a next header. Given that in all the history of options being defined
in any protocol, I don't think this a high priority. I see no purpose
in defining a protocol that allow 65,500 bytes of options in a single
packet.

Tom

> Unsafe-to-ignore can use LITE, at which point we can add - if needed - a flag to force receivers to check OCS on receipt (to differentiate the closest we can come to LITE vs. something close enough IMO to the draft-herbert header approach)..
>
> Joe