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

[Tom Herbert <[e-mail]>]

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.

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).
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). UDP options should adopt
this.
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).

Tom

> >> Tom
> >>
> >>> Am I misunderstanding something?
> >>>
> >>> Gorry
> >>>>> Mike Heard
> Gorry
>