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

[Tom Herbert <[e-mail]>]

On Sun, Jan 5, 2020 at 4:37 PM Joe Touch <[e-mail]> wrote:
>
>
>
> On Jan 5, 2020, at 3:28 PM, Tom Herbert <[e-mail]> wrote:
>
> On Sun, Jan 5, 2020 at 1:57 PM Joe Touch <[e-mail]> wrote:
>
>
> ...
> It is TCP SYNs. They have to be interpreted without context.
>
>
> TCP SYNs is the best you could come up with? One small part of a
> protocol that typically doesn't carry user data, doesn't work with
> multicast and is part of a stateful protocol 3WHS. Nope, IPv6 is the
> better model.
>
>
> TCP SYNs are transport and stateless. Yes, they’re the right model.
>
TCP SYNs are a protocol fragment, not a protocol. Also, they don't
carry any data 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?

> 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.

>
> ...
> 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.
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.

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.

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.

These are the ones I can think of now. However, there is no reason to
believe that this could an exhaustive list. Once the protocol is
deployed new options may be needed that we can't even conceive
beforehand. This happens for other protocols that have options, and
will happen for UDP options if it achieves considerable deployment.
Fundamentally, it's the essence of an extensible protocol to allow the
protocol to adapt beyond the limited view of how things will evolve
when the protocol is first designed.

Tom


>
> ...
> Fail. That causes the same packet to be silently dropped by option-aware receivers and received as zero-length by legacy receivers.
>
>
> There is no such requirement.
>
>
> I’m claiming there should be a requirement to behave the same in these cases and I explained why.
>
> And as I pointed out if there were the
> draft would need to be changed to eliminate all cases where packets
> are dropped on error since that too  "causes the same packet to be
> silently dropped by option-aware receivers and received as zero-length
> by legacy receivers."
>
>
> I already said that text was being changed.
>
> ...
>
>
>
> - If an option is received with [he needed signal]
>
>
> (again, the rest of this sentence is implementation, not requirement)
>
> and the receiver does not recognize the option,
> then the packet MUST be dropped.
>
>
> Same problem. Different behavior for legacy and option-aware.
>
>
> Same response. Show me the requirement established by consensus of the
> WG that this violates.
>
>
> We’re designing a system that has to work with legacy receivers. Having two distinctly different behaviors in those cases creates protocol complexity.
>
>
>
> Declaring that an option CANNOT BE IGNORED affects ONLY THAT OPTION. We can decide to make it trash all other options, but we can’t make it drop a packet as a whole.
>
> The whole point of an option that cannot be ignored is that it is
> incorrect to process the packet if ignored.
>
>
> The whole point is that it is incorrect to process the OPTIONS if ignored. Not the packet We can’t claim that it’s incorrect to process a packet if options are ignored - exactly because that’s what legacy receivers already do.
>
> Joe
>