Subject: [tsvwg] UDP options draft

From: Roland Bless <[email-masked]>
Date: Fri, 22 Jul 2016 13:03:10 +0200

Hi,

I just checked https://tools.ietf.org/html/draft-touch-tsvwg-udp-options-03
and in section 5 it says:
   >> 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.

so the draft is saying "do not modify in transit".

Regards
 Roland

---

From: Joe Touch <[email-masked]>
Date: Wed, 27 Jul 2016 11:47:21 -0700

Hi, Roland,

> so the draft is saying "do not modify in transit".
Yes - that's true for all transport headers. In general, they are never
designed nor intended for in-transit modification.

Did this come up in discussion at the IETF or elsewhere? I didn't see a
thread...

(NATs are interpreted as correct only if you assume they are acting as
part of the endsystem).

Joe

---

From: Roland Bless <[email-masked]>
Date: Thu, 28 Jul 2016 23:36:04 +0200

Hi Joe,

> Did this come up in discussion at the IETF or elsewhere? I didn't see a

Yes, there was a discussion about this during presentation of the draft.
Maybe the audio archives or minutes will contain more information about
the concerns that came up. IIRC several people had concerns about a new
side channel and were in favour of discarding packets with mismatching
IP and UDP lengths.

Regards,
 Roland

---

From: Joe Touch <[email-masked]>
Date: Thu, 28 Jul 2016 14:51:29 -0700

> side channel and were in favour of discarding packets with mismatching

UDP doesn't protect against side-channels at all. I'm not aware of any
transport protocol that does. The only protection would be IP-level
encryption or authentication.

Mismatching IP and UDP lengths are currently permitted by the spec and
work in all implementations we have tested (where IP is larger than UDP;
the converse can be considered malformed and dropped). Information in
the trailer (where such a mismatch occurs) is potentially accessible by
UDP, but never to the user in the implementations we've tested. It
should never be accessed by IP (IP should use the payload protocol type
as a transparent tag; it has no business poking around in its own
payload, so it should never know that there's extra space there).

However, there is no "spec" that endorses having something in the
network (where "network = L3") change any part of a packet except in the
network layer header, and only in certain places (hopcount, HBH headers,
some flag bits).

All other mods are valid only when they are effectively "on behalf of
the endpoint" (e.g., that's the only way in which NATs can operate
without violating specs).