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

[Tom Herbert <[e-mail]>]

On Tue, Mar 19, 2019, 9:28 AM Gorry Fairhurst <[e-mail]> wrote:

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

Gorry,

Suppose we create a compression option whereby UDP payload is compressed
and decompressed at the receiver. The option must be processed or the
packet containing it must be dropped, lest the application receives
gibberish. Now suppose a host receives a packet with the option, but hasn't
yet implemented it so it is an unknown type. Regardless of whether the
sender is "allowed" to send the option, the robustness principle dictates
that the host needs to be prepared deal with it when it is received. The
correct behavior is that the host drops the packet. It does this because
the option is unknown and it's bad to ignore. So to ensure correct
behavior, either the bit is needed or all packets with any unknown options
need to be dropped.

Tom


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

Right, and the only way to detect a corrupted

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