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

[Tom Herbert <[e-mail]>]

On Thu, Jul 18, 2019 at 9:56 AM Joe Touch <[e-mail]> wrote:
>
>
>
>
>
> On 2019-07-18 08:35, Tom Herbert wrote:
>
> ...
>
> A single bit in the option type to indicate that the option can be
> skipped if unrecognized should be sufficient.
>
> Tom
>
>
>
> That bit has two meanings:
>
> - for legacy receivers, it's simply ignored for legacy data
>
> - for option-aware, if the flag is set, what does it mean?
>   - it should never mean drop the legacy data, otherwise an options-aware endpoint can't decide to act as legacy
>   - it could mean drop non-legacy data
>
> Right now, the onus is on the receiver to decide what to do with the data. The info is passed to the user - NOT decided by UDP.
>
> I.e., cuurrently:
>
> - unknown options are ignored by both legacy and option-aware endpoints
> - UDP processing skips over all such options
> - users can decide/negotiate what to do with those options on a per endpoint basis
>
> Note: the first time you send something, if you want a response to help you know what the endpoint will do, you need to set "ignore" anyway, which is what the default does. Otherwise you won't get a response and won't know why (the packet could have been dropped).
>
> So this only makes sense for negotiated soft-state anyway, at which point the user can either configure the endpoint UDP socket to drop if unknown or accept.
>
> Why would we NOT give the user this choice?
>
Joe,

Consider that someone invents the compression option a year from now.
The option cannot be ignored by a receiver since delivering compressed
data to the application would be jibberish. So someone starts using
compression and performs a "soft-state" negotiation with a timeout of
30 seconds in the example algorithm you previously described for
soft-state negotiation. So the sender is sending compression option to
some receiver. But, at some point, say 10 seconds into a timeout
period, the receiving host changes to a different configuration that
doesn't support the compression option-- maybe the host address is
virtual IP and packets are now routed to a different backend, or maybe
someone reboots the receiving hosts with a new configuration. The
sender doesn't know the receiver has changed and continues sending the
compression option. The new receiver sees the options but doesn't
recognize it. If the receiver ignores the option and delivers the data
to the application then that's data corruption. That's not robust.

The "drop packet on unknown option" is the conventional and cheap way
to avoid situations like this and make stateless options robust.

Tom

> Joe
>
>