Subject: [tsvwg] More comments on UDP options

From: Tom Herbert <[email-masked]>
Date: Fri, 7 Sep 2018 17:05:16 -0700

>From the draft:

"UDP options 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,
except as provided by the options selected (e.g., OCS, ACS, or AE)."

IMO, that is far too weak. The requirement should be "Intermediate
nodes MUST NOT modify UDP options or the UDP option space". If they do
decide to it anyway we can't prevent it, but at least we can call them
out for not conforming to the protocol. We've seen too many cases
where intermediate nodes modify bits in-flight that they're not
supposed to leading to protocol ossification. For an even more
aggressive stance against protocol ossification, there should be a
means to encrypt the whole UDP options space.

>From the draft:

">> All bytes after EOL MUST be ignored by UDP option processing. As a
result, there can only ever be one EOL option (even if other bytes
were zero, they are ignored)."

Okay, UDP options may not take up all the surplus space. But what are
the requirements for data following and EOL? For instance, can an
application insert its own private data into this area? Please
clarify.

>From the draft:

"UDP data that is validated by a correct UDP checksum MUST be
delivered to the application layer, even if the UDP option checksum
fails,"

This doesn't seem to account for the case when the UDP checksum is
disabled (the UDP checksum is optional in IPv4 and for tunneling in
IPv6). So if the UDP data is not validated by a correct UDP checksum,
because the UDP checksum is not enabled (received as zero), and UDP
option checksum fails, what happens to the packet? Please clarify.

ACS section doesn't provide requirements how it is processed by
receiver. Based on similar standard for integrity checks, I would
assume the requirement would be something like: "If the ACS is present
it MUST be verified to be correct before accepting the packet. If the
ACS is not verified to be correct, the packet MUST be dropped.".
Please clarify.

Tom

---

From: Joe Touch <[email-masked]>
Date: Fri, 7 Sep 2018 20:25:28 -0700

Notes below...

> On Sep 7, 2018, at 5:05 PM, Tom Herbert <[email-masked]> wrote:
> 
> From the draft:
> 
> supposed to leading to protocol ossification.

Agreed, but the entire notion of an intermediate node has become vague. Arguably, many such nodes operate either directly or indirectly on behalf of an endpoint, i.e., distributing endpoint processing. That can be a valid implementation strategy. 

So I’m not sure what wording would be useful here.

> For an even more

See AE as currently defined.

> the requirements for data following and EOL?

I don’t know what such requirements would mean.

> For instance, can an
> application insert its own private data into this area?

An app that directly writes its own UDP packets, yes.

An app using the defined UDP API (per RFC768) augmented with this documents, no.

I.e., this isn’t an application (i.e., layer 7) accessible area.

> Please
> IPv6).

It was intended to, i.e., in that case, “0” is effectively a “correct" UDP checksum for any payload. Yes, the text should be cleaned up to cover the “checksum disabled” case.

> So if the UDP data is not validated by a correct UDP checksum,

It goes to the app (see above). I.e., when OCS fails, the packet is processed as if there were no options.

> ACS is not verified to be correct, the packet MUST be dropped.”.

Gorry discussed this case. Based on his list, as well as the issue of receiver processing effort, the following seems appropriate:

- (default) ACS is ignored (not checked) but the fact that ACS is present is indicated when the packet is passed to the app
- (when the receiver turns on receive-ACS) ACS is required (drop the packet if missing) and checked (drop the packet if incorrect)

Joe

---

From: Derek Fawcus <[email-masked]>
Date: Sat, 8 Sep 2018 17:53:43 +0100

> supposed to leading to protocol ossification.

I've not infrequently seen middle boxes, often routers as opposed to firewalls,
being configured to fiddle with the TCP MSS option.  Usually either
for tunnels, or PPPoE links.  I can likewise see a desire for such boxes to
fiddle with the proposed UDP MSS option.

DF

---

From: Tom Herbert <[email-masked]>
Date: Sat, 8 Sep 2018 10:23:41 -0700

> fiddle with the proposed UDP MSS option.
Derek,

Those are exactly the type of devices that have killed our ability to
use things like TCP header authentication option. It's protocol
ossification!

Either middleboxes are allowed to change UDP options or they are not--
there cannot be any ambiguity and this needs to be explicit in the
protocol definition. If they are allowed to change the options, then
the circumstances and requirements need to be spelled out how to do
that safely. IPv6 Destination and HBH options provide the model of how
to do this. Form RFC 8200:

"The third-highest-order bit of the Option Type specifies whether or
not the Option Data of that option can change en route to the packet's
final destination.  When an Authentication header is present in the
packet, for any option whose data may change en route, its entire
Option Data field must be treated as zero-valued octets when computing
or verifying the packet's authenticating value."

If this is applied to UDP options then the part about dealing with
Authentication Header would need to be adapted for OCS and the
authentication option if it covers the changeable data.

Tom

---

From: Joe Touch <[email-masked]>
Date: Sat, 8 Sep 2018 10:24:11 -0700

> On Sep 8, 2018, at 9:53 AM, Derek Fawcus <[email-masked]> wrote:
> 

That would be uninformed and not useful.

UDP MSS is similar to an EMTU_R (for UDP) than a path MTU (see draft-ietf-intarea-tunnels). I.e., it indicates the largest UDP segment a receiver can accept, which would include *UDP reassembly*. It doesn’t necessarily limit the transmission (that is determined by path MTU discovery *at the IP level*).

This is already noted in Section 5.6 of the draft.

Joe

---

From: Derek Fawcus <[email-masked]>
Date: Sat, 8 Sep 2018 20:00:14 +0100

> UDP MSS is similar to an EMTU_R (for UDP) than a path MTU (see draft-ietf-intarea-tunnels). I.e., it indicates the largest UDP segment a receiver can accept, which would include *UDP reassembly*. I…

Yes.  My memory playing tricks on me.

Yet it mentions that it may be used for pMTUd. I'm not sure how
it would be useful in such a case if it only relates to the
reassembly size.  Maybe best to remove such a reference?

Maybe best to rename is to something other than MSS so as to avoid
any comparision with the TCP option. e.g. MRS (max reassembly sise)?

DF

---

From: Derek Fawcus <[email-masked]>
Date: Sat, 8 Sep 2018 20:09:40 +0100

On Sat, Sep 08, 2018 at 10:23:41AM -0700, Tom Herbert wrote:
> protocol definition.

Except in the real world, if it is technically possible to manipulate
the packet, some middle boxes will do so.

The only way to prevent it is to use something like encryption (or secure
signing in such a way that the receiver can detect manipulation), otherwise
at some point, packets can be manipulated.

I know of middle boxes which reassemble IPv6 fragments, do their
stuff, then re-fragment the packets.  Essentially a router which does
forbidden stuff to run a stateful ACL.

> authentication option if it covers the changeable data.

Possibly, but (other than using public/private keys), given that UDP does
not involve a handshake, I'm not sure how it can be prevented at the protocol
(as opposed to application) level.

DF

---

From: "Gorry (erg)" <[email-masked]>
Date: Sun, 9 Sep 2018 15:52:35 +0100

There is as yet no particular use for a UDP MSS as far as I know, and little incentive for middlebpxes to change this. If an app really cares - it can encrypt other length  fields in the payload ... but saying must not change is no more than a rule that people may or may not heed, as you say.

In the case of tcp, the path over PPOE would likely fail unless you had MSS clamping, so although it may not have been what was intended in tcp design- but it is surely not an impairment ... at least until tcp stacks have better alternative ways to fix pmtu problems.

Gorry

> On 8 Sep 2018, at 18:23, Tom Herbert <[email-masked]> wrote:
>

---

From: Joe Touch <[email-masked]>
Date: Sun, 9 Sep 2018 08:43:46 -0700

> On Sep 9, 2018, at 7:52 AM, Gorry (erg) <[email-masked]> wrote:
> 
> There is as yet no particular use for a UDP MSS as far as I know,

It should be an upper bound on pre-fragmented UDP messages, which is independent of path MTU (which governs the fragment sizes).

Joe

---

From: Joe Touch <[email-masked]>
Date: Sun, 9 Sep 2018 10:07:20 -0700

FWIW, its not strictly independent - the UDP MSS would be related to the upper bound on the useful path MTU, of course.

The TCP MSS serves a similar purpose (indicating receiver upper bound); it’s not a path MTU either

Joe

> On Sep 9, 2018, at 8:43 AM, Joe Touch <[email-masked]> wrote:
> 
> 
>