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

[Joe Touch <[e-mail]>]

> On Jan 2, 2020, at 6:03 PM, Tom Herbert <[e-mail]> wrote:
> 
> On Thu, Jan 2, 2020 at 5:11 PM Joe Touch <[e-mail]> wrote:
>> ...
>> 
>> Negotiation doesn’t *have to work*. But if you don’t negotiate some sort of state, you can’t use options that can’t be silently dropped - regardless of whether they modify contents or not. That’s already stated in Sec 13.
>> 
> 
> Joe,
> 
> I don't know what you mean by "Negotiation doesn't *have to work*".

Correct use of options does not require bidirectional negotiation. 

> What I do know is that there is insufficient description in the draft
> for how a negotiation of options in a stateless protocol like UDP can
> generally work correctly or robustly.

It’s an application issue. UDP isn’t stateful and these options don’t change that.

> For instance, by the definition
> of "soft-state", it is possible that after negotiation, one side of a
> communication reboots and changes its configuration such that the
> state held by the peer is out of date.

That’s why it’s called soft, not hard.

> An option previously negotiated
> may now be unrecognized by the receiver and thus it would accept an
> option that is otherwise supposed to be ignored. It will continue to
> incorrectly ignore the option until a renegotiation happens. Ignoring
> an option that can't be ignored is fundamentally not correct. TCP does
> not have this problem since options that are used on a connection are
> explicitly negotiated and connection semantics are used.

TCP doesn’t have that problem because it has hard state, not soft state. However, its up to EACH option to decide whether it is negotiated during a SYN exchange or not. If not, then TCP is in exactly the same situation as UDP.

> IPv6 options
> solve this problem by the "drop if unrecognized" bit so no negotiation
> is ever necessary.

That is ONE way to solve things, but its hardly “solved" when nearly nobody uses it.

But it’s also not relevant here because IPv6 baked that rule in from the start. We can’t - there’s NOTHING we can do to make a legacy receiver drop packets with unknown options, regardless of the flags per se. All we can do is design them so the options and data are invisible together, which LITE+FRAG already supports.

> It's also easy to contrive other scenarios where
> supported options may change between packets (e.g. destination is an
> anycast address, NAT state for a UDP flow changes).

Yes, and that’s why soft state needs to be updated if used that way.

> What *specifically* in soft-state negotiation prevents these types of
> scenarios from leading to the incorrect behavior of a receiver
> accepting an option it is supposed to ignore?

Soft state remains soft. If you need assurances that options fate share with data, LITE+FRAG works. A bit in the option doesn’t.

Joe