Re: [tsvwg] Rregarding soft-state and UDP options

[Joe Touch <[e-mail]>]

> On Jan 5, 2020, at 12:13 PM, Tom Herbert <[e-mail]> wrote:
> 
> On Sun, Jan 5, 2020 at 11:21 AM Joe Touch <[e-mail]> wrote:
>> 
>> Malformed packets are dropped as with TCP and the base UDP spec.
>> 
> And packet with unknown options that cannot be ignored need be dropped
> (IPv6 HBH and destination options for instance).

You keep citing network protocols, not transport.

Transport protocols don’t have this behavior - and it’s IMPOSSIBLE to implement for legacy UDP receivers.

> Such a packet is
> equivalent to a malformed packet since these packet cannot be
> correctly processed by the receiver.

I cited the section of RFC 1122 that indicates this is incorrect. It is also reiterated as incorrect in both TCP-MD5 and TCP-AO.

TCP receivers silently and individually ignore unknown options unless they indicate a parsing error.

To put it more directly, malformed != unknown. That’s true for ALL protocols of which I am aware.

> In any case, send a malformed UDP options to an options aware receiver
> then the packet is dropped, send the same packet to a legacy receiver
> then a zero length packet is received. There is no consistency there,
> and neither does that conform to the requirement in normative language
> that you just proposed

UDP options are supposed to *ignore all options* if the options are malformed - NEVER just drop the packet. The packet and its body data (NOT the FRAG data, the conventional body data) would still be received, just without the options (and no, that’s not yet in the doc, but should have been).

This is the relevant existing text:
   >> Receivers MUST silently ignore unknown options. That includes
   options whose length does not indicate the specified value.
The text that follows regarding options that are too long is incorrect in v08; it should say that the options are all silently ignored when any are malformed.

Joe