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

[Joe Touch <[e-mail]>]

> On Jan 6, 2020, at 8:19 AM, Tom Herbert <[e-mail]> wrote:
> 
> On Sun, Jan 5, 2020 at 4:37 PM Joe Touch <[e-mail]> wrote:
>> ...
>> TCP SYNs are transport and stateless. Yes, they’re the right model.
>> 
> TCP SYNs are a protocol fragment, not a protocol.

They are very similar to UDP with options - by themselves they are stateless. The only difference is that TCP knew it had options from the beginning.

> Also, they don't
> carry any data

Yes, they can.

> so I'm not even sure how you could say they are
> transport seeing that they don't transport anything. Has it occurred
> to you that the reason all options can be ignored in a TCP SYN is that
> there's no data that could be incorrectly delivered to the
> application?

Data in the TCP SYN is retained and presented to the application layer if a final ACK is received.

> 
>> IPv6 is largely designed for intermediate devices - that’s not what we’re designing for here.
> 
> The design is adding options to a stateless, connectionless, datagram
> protocol that works over unicast, multicast, anycast, and broadcast.
> IPv6, RFC8200 specifically which is full Internet standard, shows
> exactly how to do this.

It shows us how NOT to do it too, in several ways. Lots of options - few (if any) actually in use, except IPsec.

> 
>> 
>> ...
>> First, it fails to be motivated by an example.
>> 
>> Encryption option.
>> 
>> 
>> We already have a solution for that with FRAG+LITE.
>> 
>> Is there any example of a packet whose contents aren’t modified but MUST NOT be accepted if the option fails?
> 
> Any form of integrity checks that sender has set up and requested.

Yes, except that we are already defining two (auth and ACS). Many protocols have tried to define many others - but interestingly NONE are used.

> This includes checksums, ACS, HMACs, etc. This includes the
> possibility to add new algorithms in the future per evolving needs.
> For instance, the current ACS is CRC32c, that is a strong integrity
> check however could very well be prohibitive to support on low powered
> IoT devices. For this reason ACS should not be required to be
> implemented, and the possibility of adding a CRC check more feasible
> to these devices should not be precluded.

So let me understand - you don’t trust the IP checksum but want something simpler than CRC32c. Any idea what that unicorn algorithm is?

And if it’s so useful, can you explain why nobody uses one for IP?

> A virtual network identifier, anycast instance identifier, or any
> other ancillary information that provides more specific information to
> correctly deliver the packet than that in the IP header and ports.
> Ignore a virtual identifier for instance, and the packet is allowed to
> cross virtual networks thereby breaking required isolation.

Those are network IDs. We have those - IP in IP, VPN-IDs, etc. - at the *network* layer where they belong - and are WIDELY already used.

> UDP options compression option. Similar to Van Jacobson compression in
> PPP, when the same options are used repeatedly they could be
> compressed to save overhead.

Oh - right, compression. Remember that anything that modifies the data is already covered by the regular option space because it would *modify the data* in the FRAG_LITE method.

Then again, we really need to consider that case. Consider how popular PPP is and how that sort of mechanism has already been widely deployed as an option for IP and TCP. (not).

You might consider why compression of net and transport protocols focuses on headers, not payloads. Because if an app either compresses or encrypts, there’s no further point. Compression in particular works best on long sequences and/or when the message structure is known. None of this is true at the network or transport layer.

> 
> These are the ones I can think of now. However, there is no reason to
> believe that this could an exhaustive list.

Oh, yes. I have seen the point for a while in this thread.

These options are a playground for experiments. The best part of that is how we document the way our protocols have been littered with these experiments over the years.

Silly me. I thought we were trying to learn from past experience and make this clean, simple, and likely to actually be used.

Joe