Re: [tsvwg] Alternative version of the UDP FRAG option

[Gorry Fairhurst <[e-mail]>]

Tom, I don't agree with some of this...

On 18/03/2019, 20:54, Tom Herbert wrote:
> On Mon, Mar 18, 2019 at 11:10 AM Gorry Fairhurst<[e-mail]>  wrote:
>> On 18/03/2019, 16:27, Tom Herbert wrote:
>>> On Mon, Mar 18, 2019 at 8:58 AM Tom Herbert<[e-mail]>   wrote:
>>>> On Mon, Mar 18, 2019 at 8:40 AM Gorry Fairhurst<[e-mail]>   wrote:
>>>>> I think I missed something between these emails....
>>>>>
>>>>> On 18/03/2019, 15:13, Tom Herbert wrote:
>>>>>> On Mon, Mar 18, 2019 at 7:43 AM C. M. Heard<[e-mail]>    wrote:
>>>>>>> On Sat, Mar 16, 2019 at 9:06 AM Tom Herbert wrote:
>>>>>>>> Thinking about this, it occurs to me be that the LITE option isn't
>>>>>>>> needed. The assumption in the UDP options draft is that a receiver
>>>>>>>> needs the UDP payload to immediately follow the UDP header, but the
>>>>>>>> UDP payload can be anywhere in the surplus area as long as it's
>>>>>>>> aligned to four bytes. A receiver will know how to handle it and
>>>>>>>> deliver the UDP data to the application (e.g. by maintaining a pointer
>>>>>>>> to the data).
>>>>>>>>
>>>>>>>> So that allows a format like:
>>>>>>>>
>>>>>>>> UDP header (Length=8) | Surplus area header | Options | Payload
>>>>>>>>
>>>>>>>> The surplus area header contains the header length and a checksum
>>>>>>>> covering the surplus space (four bytes altogether). The three headers
>>>>>>>> can thought of as an extended UDP header, so the format becomes:
>>>>>>>>
>>>>>>>> Extended UDP header | Payload
>>>>>>>>
>>>>>>>> Which looks a whole lot like any other protocol format with a variable
>>>>>>>> length header such as TCP or IPv4.
>>>>>>> A major downside to this approach is that is does not let you add
>>>>>>> "optional to process" options such as MSS, Echo Request, and Echo
>>>>>>> Response to UDP datagrams that are intended to be processed normally
>>>>>>> by legacy receivers that do not understand UDP options or the extended
>>>>>>> UDP header format. You can do that with the option trailer as
>>>>>>> currently proposed.
>>>>> Right, so this really re-designs UDP as a sublayer to another transport.
>>>>> To me, this looks very like an encaps like DCCP-in-UDP or GRE-in-UDP,
>>>>> etc. So this isn't an "option" it's an encapsulation.
>>>>>> Mike,
>>>>>>
>>>>>> The converse is also true. We can't put options in a trailer that
>>>>>> *must* be processed by the receiver (fragmentation, compression,
>>>>>> security, etc.).
>>>>>>
>>>>>> Tom
>>>>> Why this? I thought that if you make a request to negotiate to use say
>>>>> enhanced integrity checking or some security option, then you can
>>>>> require the option to be present at the receiver?
>>>> Gorry,
>>>>
>>>> How does negotiation work with a transport protocol that is stateless?
>>>> Negotiation implies state is maintained between two endpoints.
>>>>
>>> Also, if there is a negotiation then there communicating endpoint is
>>> known to not be a legacy receiver so the extended header can be used.
>>> Then if the packet is received by some other legacy node (e.g. because
>>> of VIP, address corruption, peer rebooted and state is lost) the
>>> packet is "dropped" (a zero length UDP datagram is received by the
>>> peer).
>>>
>>> Tom
>> So I wa sthinking that the app "knows" what is "negotiated". It could be
>> that the app decides it needs security or enhanced integrity check and
>> therfore configures to add this at the sender and check at the receiver.
>> Whether this "knowing" is hard-coded or uses an upper layer handshake
>> isn't so significant to me. An upper layer handshake/protocol could also
>> include some sort of fall-back.
>>
>> For an apps that is itself stateless it just has to be designed to use a
>> UDP Option or not. In the same way that it chooses TCP or could use SCTP
>> etc.
> Gorry,
>
> If negotiation is an integral mechanism in UDP options then we really
> need the specification for it.
I'm really unsure we need much extra.
> For important options received in a packet (frag, security, integrity
> check, etc.) the requirements are straightforward: either the option
> is processed and appropriately verified, or the packet must be
> dropped. An alternative that allows a receiver to just ignore them and
> still receive the data like nothing happened is a non-starter.
>
> For UDP options this means:
>
> 1. If there are important UDP options present then the receiver must
> process the option space or drop the packet. For this reason,
> important options cannot be in trailers (legacy mode in UDP options
> draft).
I don't think this is correct.
> 2. If there is an important option that is unknown to the receiver or
> can't be processed by the receiver then the packet must be dropped. In
> other protocols (e.g. DO, HBH options in IPv6) the option type
> includes an indication of what to do if type is unknown to the
> receiver (basically skip option or drop).
That makes sense at the network layer - e.g. where a tunnel
does not know what is being transported.

For UDP Options, that operate on endpoints, I can't figure out
why coding for a sending app would add an option and code
for a receiving app would not be correspondingly updated. If they
are different versions of the endpoint code, then that's an app
problem.
> UDP options should adopt this.
You may think so, I don't.
> 3. Important options themselves need to be protected. We can't allow a
> single bit corruption to make an important option just disappear. This
> is a motivation for options to always be covered by a checksum. There
> is a peculiarity that should be documented in that the checksum might
> be used to protect an option holding a stronger integrity check (like
> a CRC option).
If the app relies on the option - then it will look for it, and discard when
it is not found. That includes if you look for a CRC. The code we have
simply throws the packet when expecting a CRC and not finding one,
as if the CRC were wrong. The checksum provides a pre-check including
the pseudo-header.

If the options space is corrupted then the UDP packet should be thrown
away. (OK, one could have LITE
> Tom
Gorry
>>>> Tom
>>>>
>>>>> Am I misunderstanding something?
>>>>>
>>>>> Gorry
>>>>>>> Mike Heard
>> Gorry
>>