Subject: [Spud] related draft in TSVWG

From: Joe Touch <[email-masked]>
Date: Mon, 27 Jun 2016 14:14:46 -0700

Hi, all,

The following draft may be of potential utility in SPUD/PLUS:

     draft-touch-tsvwg-udp-options

It describes an extension to UDP to allow for trailing options at the
transport layer.

NOTE: I'm not sure what space makes the most sense; for on-path info,
IMO IP is a more appropriate location than transport, but IF there is
info that is useful to exchange at the transport layer in the header,
this might be useful for UDP.

It will be briefly presented by the chairs in TSVWG.

FYI.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Mon, 27 Jun 2016 15:53:14 -0700

> It describes an extension to UDP to allow for trailing options at the

Hi Joe,

>From the draft:

"This length field is typically redundant with IP datagram length and
header length information as follows:

                  UDPlen = IPlen - IPhdrlen - 8

As a result of this redundancy, the UDP length field can be used in other ways."

"typically" is a key word here; this is not a requirement of UDP. As
long as the UDP length is less than or equal to IP payload length it
would be a valid UDP packet. The draft exploits this characteristic,
however that does not preclude that packets with smaller UDP length
than IP payload length already exist (maybe even using the same trick
to extend UDP!). Seems like that leads to a potential ambiguity?

Tom

> _______________________________________________
> Spud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spud

---

From: Joe Touch <[email-masked]>
Date: Mon, 27 Jun 2016 16:12:41 -0700

> to extend UDP!). Seems like that leads to a potential ambiguity?

First, yes, if this were a strict requirement, than UDP implementations
would discard UDP segments that were smaller than the IP payload -- in
practice, they don't.

The good news is that there are no known specs (at least none I've heard
of yet or know of otherwise) that use this trick except:

a) UDP-lite, which uses a different transport protocol number and has
different semantics
    in UDP-lite, the entire IP payload is treated as the UDP payload,
which isn't compatible with RFC768

    i.e., it basically delivers both what UDP considers the payload AND
the extended area to the app layer

b) there's a defensive patent that talks about this, which we already
know about but AFAIK never got beyond the though level

    (it's the typical patent with permissions compatible with IETF
standards, again AFAIK)

This does appear to be the first system that will spec this out. We do
include the new OCS (option checksum), which might help avoid accidental
ambiguous use (I.e., UDP OCS ought to help avoid processing these other
uses as UDP checksum).

We can add text to address this issue, though we would appreciate also
knowing if anyone is aware of existing uses other than the two above.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Mon, 27 Jun 2016 16:34:48 -0700

> would discard UDP segments that were smaller than the IP payload -- in
I would not be at all surprised if there are middle boxes that either
drop such packets or truncate them to UDP length in the name of
security.

> ambiguous use (I.e., UDP OCS ought to help avoid processing these other
You might want to look at magic numbers for this purpose also.
Unfortunately, similar to the idea of putting bits in UDP payload for
interpretation in the network, protocol correctness in this method is
only probabilistic. That is the best we could achieve is 99.999..%
correctness, not 100%.

> knowing if anyone is aware of existing uses other than the two above.
Probably should also expressly forbid the network to modify options in
flight, that is where things get really scary in the above ambiguous
identification problem.

Tom

---

From: Joe Touch <[email-masked]>
Date: Mon, 27 Jun 2016 16:39:44 -0700

> drop such packets or truncate them to UDP length in the name of
We haven't done exhaustive tests, but so far we've seen good behavior.

> You might want to look at magic numbers for this purpose also.

A checksum is just a dynamic, context-sensitive magic number. There's a
lot lower chance of a checksum being correct in a random sequence than a
magic number.

> only probabilistic. That is the best we could achieve is 99.999..%
That's true for everything. Anyone could have deployed an unassigned TCP
option number in an unknown way too.

> flight, that is where things get really scary in the above ambiguous
Oh, yes. FYI, the OCS is just over the option space, not over the UDP
payload, UDP header, or IP pseudoheader.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Mon, 27 Jun 2016 16:53:34 -0700

> option number in an unknown way too.

Using an unassigned option number is non-standard, and if a
non-standard use of protocol conflicts with the standard use then the
non-standard case is in error. But, if a protocol allows for two
alternate interpretations of the same data both of which claim to
conform to the standard, then the protocol itself is incorrect. I'm
sure there's a good analogy somewhere here involving a man wearing two
watches ;-)

Tom

---

From: Joe Touch <[email-masked]>
Date: Mon, 27 Jun 2016 17:11:37 -0700

> sure there's a good analogy somewhere here involving a man wearing two
Sure - that's in some respects why this ID is intended to resolve that
ambiguity. Note that it's also strictly OK per RFC768 to send an packet
whose UDP payload indicates a length *longer* than the IP payload
indicates too.

This should also be resolved in an update to RFC1122, eventually.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 28 Jun 2016 14:48:34 -0700

Thinking further on this, I have the following language in the update:

>> UDP options are intended for use only by the transport endpoints.
They are no more (or less) appropriate to be modified in-transit than
any other portion of the transport datagram.

UDP options are are transport options. Generally, transport datagrams
are not intended to be modified in-transit. However, the UDP option
mechanism provides no specific protection against in-transit
modification of the UDP header, UDP payload, or UDP option area.

I.e., I agree that these shouldn't be modified, but IMO neither should
UDP ports. The only way that such mods make sense is when they are
carried out "on behalf of" the transport endpoints, but again they key
is that "this is no different than any other portion of the UDP
datagram" IMO.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Tue, 28 Jun 2016 15:04:42 -0700

On Tue, Jun 28, 2016 at 2:48 PM, Joe Touch <[email-masked]> wrote:
>>> UDP options are intended for use only by the transport endpoints. They
>>> are no more (or less) appropriate to be modified in-transit than any other
>>> portion of the transport datagram.
>
> UDP options are are transport options. Generally, transport datagrams are
> not intended to be modified in-transit. However, the UDP option mechanism
> provides no specific protection against in-transit modification of the UDP
> header, UDP payload, or UDP option area.
>
>
> I.e., I agree that these shouldn't be modified, but IMO neither should UDP
> ports. The only way that such mods make sense is when they are carried out
> "on behalf of" the transport endpoints, but again they key is that "this is
> no different than any other portion of the UDP datagram" IMO.
>
It is different because of the payload identification problem.
Intermediate nodes modifying the UDP option area carries more risk of
data corruption than if they modify the UDP header or TCP options.
This probably would have less risk than modifying UDP payload itself
though.

Tom

---

From: Joe Touch <[email-masked]>
Date: Tue, 28 Jun 2016 15:07:57 -0700

> This probably would have less risk than modifying UDP payload itself
I agree they're all a little different, but I don't know if I'd take a
bet on whether any of this is more or less likely to mess things up.

E.g., changing ports affects in-band refs to port numbers too.

Joe