Re: [tsvwg] Regarding DTLS and UDP options

[Joe Touch <[e-mail]>]

Tom,


On 4/18/2017 9:37 AM, Tom Herbert wrote:
> ...
> Gorry,
>
> UDP is a connectionless and unreliable protocol, so if the stack were
> to on its own accord add an MSS to a packet how and no response was
> seen how would it know the difference between a one way communication
> and the packet was dropped because some intermediate device enforces
> IP len == UDP len?
IP len is the whole packet; UDP len is the length of the UDP segment,
typically the IPlen - IPhdrsize.

RFC768 permits UDP len to be smaller than IPlen - IPhdrsize, so the
first point is that such an intermediate device isn't "enforcing"
anything other than its own peculiar idea of what it expects, rather
than what the protocol allows. It's no different than a device that
drops  TCP segments with unknown options - both are bugs.

UDP has a large number of ways of silently failing, including this.
Others include sending packets too large for the PMTU with DF=1 (or just
using IPv6) or sending to the wrong port - where ICMPs might not be
received in response. (note that there's no ICMP that justifies the
intermediate device "enforcing" the length match either).

Applications already account for this behavior by trying variations when
communication fails - that includes resending, changing packet sizes,
and (in this case) changing which options are used.
> My concern with retrofitting UDP is that I don't think it can be done
> so that all ambiguities are eliminated and hence it will never be
> completely robust. 
I see that as a thread in your responses.

The logical conclusion is that we all should use IPv4, TCP with no
options, and UDP. Oh, and no new services - ever.

Because *any* new capability, even within the bounds of existing
extensions, can be deemed "incompletely robust" if you accept
intermediate devices that block such valid services as legitimate.

So if that's your conclusion, can we also conclude that you're also
withdrawing your proposal in NVO3 for GUE and releasing port 6080?

> For instance, in TCP any part of the TCP header
> after the first twenty bytes must be TCP options-- there is no other
> possible interpretation of these bits allowed by the protocol. But,
> correct interpretation of UDP options in the surplus space is
> inherently probabilistic. 
That's true for all new uses of any existing values - even GUE's use of
port 6080 is inherently probabilistic because you don't know that
someone isn't now squatting on that port for a different service (or
won't in the future).

> Even if we put in checksums and magic
> numbers and get the probability of misinterpretation very low it will
> not be zero. If some existing device happens to be adding random bits
> beyond the UDP header (as the draft points out it was never a
> requirement that lengths need to match) and this is subsequently
> misinterpreted as UDP options causing insidious effects, even if this
> happens just once, it is a problem with the protocol not the
> implementation.
There are no currently defined uses for that space, even though it is
not prohibited. The issues you have here apply to any use of any
undefined field, e.g., any reserved bits, new options, etc. There's
always the risk of a squatter using the space other than as specified by
a protocol.

For that matter, you have exactly the same risk if a user decides to
issue IP packets with protocol 17 and happens to not use the UDP format.
Ultimately, protocols either follow specs or they do not. The UDP spec
*allows* for use of this space *but does not define that use*. All
current uses are identical to squatting, just like any other code space.

Any new assignment or definition of that space runs the risk of running
into squatters who use that value in other ways.

> I think ambiguity is manageable if it is only the communicating hosts
> that process the options and the use of options is expressly enabled
> for both transmit and receive. 
That's already noted in the doc in Section 10.

> If some intermediate device wereto
> start parsing and possibly modifying options on its own accord this
> would be exceedingly dangerous in my opinion. Such a problem would
> potentially be a nightmare to debug in real networks since we don't
> even have tools that can would analyze trailers. Fortunately, trailers
> are unlikely to be considered by intermediate devices so this problem
> is unlikely today. Nevertheless, I think the draft should say up from
> that intermediate devices MUST NOT process, examine, or modify UDP
> options.
Everything you say about modifying UDP options is true for UDP headers,
TCP headers, and TCP options too, but we already have devices that
process, examine, and modify them.

As long as we understand that these are headers for UDP - not for other
protocols, e.g., IP - we know who should and should not be modifying
them already and the associated risks.

As to the issue of tools - we don't have tools to analyze port 6080
either. Again, your argument there would prevent any new feature from
being deployed.

> A related concern I have is around security and whether ambiguity can
> be exploited. For instance, someone could easily forge a UDP fragment
> using the UDP option. If a device supports UDP options they will
> interpret this as fragment, if they don't they will see this as plain
> UDP packet. This are very different interpretations of the same bits
> however both devices could claim protocol conformance-- that's a
> potential problem. This becomes a real problem if the ambiguity can be
> somehow exploited to bypass security.
UDP packets and TCP packets can already be forged.

If that's your concern, you need to use true transport-layer or network
layer security.

And endpoints can claim conformance all they want; forged packets are
already noncompliant. No protocol is robust to forged packets except
those that support authentication or encryption.

> The draft should probably include some more consideration for use with
> NAT. For instance:
>
> "A host SHOULD indicate FRAG support by transmitting an unfragmented
> datagram using the Fragmentation option"
>
> If the host lives behind a NAT this would effectively indicate support
> for FRAG for all the hosts sitting behind the NAT. I doubt that's the
> intent! FRAG should probably be based on UDP 4-tuple, but even packets
> on that flow might not always be going to the same host (an IP anycast
> destination for example).
Section 10 already addresses this - the assumption is that discovery is
done on a socketpair basis. I can mention socketpair as the assumed
level of soft-state sharing earlier in that section if useful.

> Also, the draft should mention multicast and whether or not UDP
> options are allowed with that.

Yes, that's a good point and I'll add that in the next rev.

Joe