Subject: [tsvwg] Regarding DTLS and UDP options

From: Joe Touch <[email-masked]>
Date: Fri, 14 Apr 2017 16:56:41 -0700

Hi, all,

Christian Huitema a question about the interaction between DTLS and UDP
options during my remote presentation at IETF 98.

I took a closer look and consulted with Eric Rescorla (DTLS author). He
and I agreed as follows:
- DTLS would currently not cover UDP options; DTLS protects only the UDP
payload
- the situation is analogous to TCP options, which are not covered by TLS
I.e., both TLS and DTLS are transport *payload* security only, despite
their names.

Christian noted that this may be a reason QUIC prefers UDP (to avoid the
need to protection transport options), however QUIC does not (and
cannot) deprecate UDP payloads that are smaller than the IP payload.
That would require a change to RFC 768.

I'll add a clarification on this point to the next rev of the UDP
options document.

Joe

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 17 Apr 2017 09:59:47 +0100

Thanks Joe,

That seems to be exactly the question the WG asked to explore. I agree 
your next update should add a small susbsection on how DTLS should be 
handled.

Gorry

---

From: Joe Touch <[email-masked]>
Date: Mon, 17 Apr 2017 12:11:51 -0700

FYI - draft 08 has just been uploaded to address this issue in the
security considerations section.

I would like to ask that the chairs to ask the WG to consider adopting
this as a standards track doc.

Joe

A new version of I-D, draft-touch-tsvwg-udp-options-08.txt
has been successfully submitted by Joe Touch and posted to the
IETF repository.

Name:		draft-touch-tsvwg-udp-options
Revision:	08
Title:		Transport Options for UDP
Document date:	2017-04-17
Group:		Individual Submission
Pages:		25
URL:            https://www.ietf.org/internet-drafts/draft-touch-tsvwg-udp-options-08.txt
Status:         https://datatracker.ietf.org/doc/draft-touch-tsvwg-udp-options/
Htmlized:       https://tools.ietf.org/html/draft-touch-tsvwg-udp-options-08
Htmlized:       https://datatracker.ietf.org/doc/html/draft-touch-tsvwg-udp-options-08
Diff:           https://www.ietf.org/rfcdiff?url2=draft-touch-tsvwg-udp-options-08

---

From: Tom Herbert <[email-masked]>
Date: Mon, 17 Apr 2017 13:29:28 -0700

> this as a standards track doc.
Joe,

The draft lists intended status as experimental, but above you're
asking for adoption for standard track? I would be worried about
making this standard if it retroactively defines all cases where IP
length is greater than UDP length as now containing UDP options.

One thing that might be missing from the draft is middle box handling.
I suspect your intent is that options are meant only for end to end
consumption and so middleboxes must pass packets with UDP options,
should not attempt to parse the UDP options, and must not modify
options.

Tom

---

From: Joe Touch <[email-masked]>
Date: Mon, 17 Apr 2017 13:34:18 -0700

On 4/17/2017 1:29 PM, Tom Herbert wrote:
> asking for adoption for standard track? 

That's correct.

> I would be worried about

It does exactly that, but has checksums to validate when that happens.

> One thing that might be missing from the draft is middle box handling.
This is already discussed extensively in the document, including in
response to previous TSVWG discussion. That's why we now default to
using the OCS and a length validation. Do you have specific concerns?

> consumption 

That's frankly true of all transport options, not just these in UDP.

> and so middleboxes must pass packets with UDP options,
We already addressed that in the doc.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Mon, 17 Apr 2017 13:47:59 -0700

> We already addressed that in the doc.

I'm sorry, which section is this info in?

Thanks,
Tom

---

From: Tom Herbert <[email-masked]>
Date: Mon, 17 Apr 2017 14:06:14 -0700

> I'll add a clarification on this point to the next rev of the UDP
Since the UDP options are not covered by DTLS couldn't that allow a
middleman attacker to add arbitrary UDP options to a packet thereby
potentially circumventing the security provided DTLS? Maybe if DTLS is
in use then AE option should be required also? Note that this case
differs from TCP options since the sender in my example my not even
have a clue as to what UDP options are.

Tom

---

From: Joe Touch <[email-masked]>
Date: Mon, 17 Apr 2017 14:07:59 -0700

On 4/17/2017 1:47 PM, Tom Herbert wrote:
> ...
...

> I'm sorry, which section is this info in?
The doc talks about legacy issues throughout.

Sec 5.3 talks about the option checksum and Sec 9 talks about
interactions with legacy devices in general.

Section 7 explicitly indicates that these are for transport endpoint use
only.

I don't think we should be writing rules to indicate who should NOT be
changing them, if we already have rules indicating the only parties that
can. (granted, the requirement in 7 needs to be revised in 2119-speak).

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 17 Apr 2017 14:12:09 -0700

On 4/17/2017 2:06 PM, Tom Herbert wrote:
> potentially circumventing the security provided DTLS?
Everything you just said is already true for TCP and TLS.

The "TL" in TLS and DTLS is a misnomer; neither one provides
transport-layer protection.

> Maybe if DTLS is
> in use then AE option should be required also? 

That's no more appropriate than it would be to require TCP-AO whenever
TLS is in use.

> Note that this case
That's irrelevant. In both cases, a MITM can add an option that the
sender might not know about.

If you want to protect the transport header, you have to use true
transport-layer protection (TCP-AO, UDO AE) or IPsec.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 17 Apr 2017 14:19:28 -0700

> can. (granted, the requirement in 7 needs to be revised in 2119-speak).
FWIW, the doc currently says that the options are intended for use by
the endpoints.

However, just as NATs already change transport headers and options
(e.g., TCP), they could do so here as well.

In both cases, the same caveats apply:
    - if the endpoints don't want to allow changes, they must use (true)
transport or network protections
    - if the middlebox (or any other mechanism, e.g., offloading)
changes them, they need to know what they're doing and do it right

Again, none of this is news.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Mon, 17 Apr 2017 15:00:38 -0700

Joe,

You may want to look at IPv6 EH description for guidance. Even with
all the words about how extension headers can't be examined or
processed with the exception of HBH options, there still has been
considerable discussion on what intermediate devices can or can't do.
Clarifying the exact requirements upfront is beneficial. In the
absence of such clarity, we need to assume that anything in clear text
is subject to inspection and possible modification so that the end
result is often ossification of what might have otherwise been a
useful feature (although even with clear requirements abuse and
ossification is still a possibility). Neither can we expect
middleboxes to always know what they're doing. Fundamentally, if I, as
an application developer, can't trust the network not do mess with my
UDP options, it's likely I simply wouldn't use them (hence
ossification even before deployment).

Tom

---

From: Joe Touch <[email-masked]>
Date: Mon, 17 Apr 2017 15:09:31 -0700

Hi, Tom,

> considerable discussion on what intermediate devices can or can't do.
The situation is completely different.

IP is intended for inspection - and HBH headers for modification - by
network devices other than the endpoints.

Transport headers have no such role. Any device that tampers with
transport headers already needs to be (effectively) an endpoint or
acting on the behalf of an endpoint.

> Clarifying the exact requirements upfront is beneficial. 
Yes, which has already been done. These are declared as owned by and for
the use of the endpoints, just like the transport header.

We don't have documents that declare that TCP headers or options MUST
NOT be modified by middleboxes, even though that's always been
effectively the case. The only way a middlebox gets around that rule is
by assuming the behavior of an endpoint, essentially.

> In the
> is subject to inspection and possible modification 

We already have docs describing (true) transport and network layer
security. If you don't want data inspected or modified, that's the only
solution.

I see no reason to declare anything special about middleboxes here.
Frankly, they can modify these options just like they modify the UDP
header - at their own risk.

> so that the end
Do you use TCP options?

How and why should these be different?

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 17 Apr 2017 15:25:59 -0700

>> considerable discussion on what intermediate devices can or can't do.

For the benefit of others on this list who might not have followed this
issue, FWIW, this discussion happened during the revision of RFC2460 on
the v6ops and main IETF list.

RFC 2460 said the following:

   With one exception, extension headers are not examined or processed
   by any node along a packet's delivery path

The one exception was HBH headers.

Discussion centered around a few issues:
    - 2460 said "not examined or processed" - did that include inserting
or deleting new EHs, which might arguably require neither examining nor
processing?
    - what does "processing" mean? (does it include altering? does it
include making a header longer or shorter?)
    - would not adding new EHs ossify IPv6?

It took a while to converge on the following:
    - that text now explicitly excludes inserting or deleting EHs
    - there are still arguments about what "processing" means, but that
term was accepted, given the clarification of inserting/deleting as
distinct operations
    - it was clarified (at least on the mailing lists) that the HBH
itself is already extensible, so disabling new EHs that change en-route
wasn't ossifying

------
For IPv6, this might have been important because it already did specify
cases where some EHs were modified in transit while others were not.

That's not the case for transport options, which is why I believe it is
unnecessary to provide detail on what devices en-route shouldn't be doing.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Mon, 17 Apr 2017 15:31:38 -0700

> How and why should these be different?
TCP options are pretty much required for operation of the TCP
protocol, this is why they will never be ossified and why it's one of
the few methods of protocol extensibility that is viable on the
Internet. IP options on the other hand were never required for IP to
operate hence they were quickly ossified. In this context, UDP options
are more like IP options since they are not required for use with UDP.
So there is a possibility that some vendors (e.g. a firewall) may just
decide that to start dropping packets or throwing packets that might
have them into a slow path similar to IP options. If something like
this is not consistently supported in the Internet, then applications
are unlikely to use it. I wish this wasn't reality and that the end to
end model was actually adhered to, but when writing Internet
applications we have to stick with what is known to work... ie. plain
TCP/IP or UDP/IP (where support for the latter is still a little shaky
since some network operators refer to think of UDP as nothing more
than a DOS vector).

Tom

---

From: Joe Touch <[email-masked]>
Date: Mon, 17 Apr 2017 15:42:50 -0700

On 4/17/2017 3:31 PM, Tom Herbert wrote:
> protocol, 

You can run TCP with no options just fine - but not efficiently.

> this is why they will never be ossified and why it's one of
> Internet.
They are somewhat ossified in that there are offload devices and
middleboxes that work only with known subsets of options. In some cases,
those features have work-arounds when unknown or unsupported options are
seen - but not always.

>  IP options on the other hand were never required for IP to
> operate hence they were quickly ossified.
I'm not sure you're using the term 'ossified' the way others do.

For IPv4, options were not so much "turned to stone" as they were
deprecated because fast-path processing never supported them.

For IPv6, that's not as true because of the way the options are layered
rather than tacked-on.

>  In this context, UDP options
Just like TCP, option support is determined by which options are
activated and the semantics of the options and user (application)
preferences. Whether they're required or not depends on the endpoint's
decision of how they use the options. An endpoint could require
particular options and backoff to TCP where the options are not
supported, e.g., DNSSEC might require FRAG or backoff to TCP.

> since some network operators refer to think of UDP as nothing more
Certainly, but so far all we have evidence of are over-eager firewalls
that incorrectly think that UDP packets whose transport portion are
smaller than the IP payload are an error. That's just as incorrect as
thinking that it's "safer" to drop all TCP packets that support MPTCP.

So yes, like any extension, it works only where the Internet lets it. It
can be useful where needed or preferred, but like any extension, there's
always the possibility that some ignorant party will try to block it in
the name of security.

Again, not new and just like TCP.

Joe

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 18 Apr 2017 08:30:04 +0100

On 17/04/2017, 23:31, Tom Herbert wrote:

Joe: How and why should these be different?

> since some network operators refer to think of UDP as nothing more
I have opinions on this para, in that I think options in TCP can be 
selected by the TCP stack, they do not explicitly need to be turned on 
or off by applications. A simple example: Timestamp or MSS. If we had 
similar options for UDP, this could also be automated by the stack 
(e.g., MSS to know the maximum receive datagram size). I have ideas of a 
number of such things that could be automatable, and plan to try these 
as soon as we have a stack that supports this.

Sure, options may not be supported by specific paths - although I 
suspect that enough paths already do support to make it worth trying in 
many cases. The UDP (plus options) transport stack can then include 
mechanisms to decide how to handle loss of options, just as TCP stacks 
do this today. Applications do not need to be involved - perhaps other 
than to "enable" the sender stack to do the correct thing.

Gorry

---

From: Tom Herbert <[email-masked]>
Date: Tue, 18 Apr 2017 09:37:21 -0700

On Tue, Apr 18, 2017 at 12:30 AM, Gorry Fairhurst <[email-masked]> wrote:
> I have opinions on this para, in that I think options in TCP can be selected
> by the TCP stack, they do not explicitly need to be turned on or off by
> applications. A simple example: Timestamp or MSS. If we had similar options
> for UDP, this could also be automated by the stack (e.g., MSS to know the
> maximum receive datagram size). I have ideas of a number of such things that
> could be automatable, and plan to try these as soon as we have a stack that
> supports this.
>
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?

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

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

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.

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

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

Thanks,
Tom

> Sure, options may not be supported by specific paths - although I suspect
> that enough paths already do support to make it worth trying in many cases.
> The UDP (plus options) transport stack can then include mechanisms to decide
> how to handle loss of options, just as TCP stacks do this today.
> Applications do not need to be involved - perhaps other than to "enable" the
> sender stack to do the correct thing.
>

---

From: Joe Touch <[email-masked]>
Date: Tue, 18 Apr 2017 10:06:05 -0700

Tom,

> and the packet was dropped because some intermediate device enforces
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.
> 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
> 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
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.

> for both transmit and receive. 
That's already noted in the doc in Section 10.

> If some intermediate device wereto
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.

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

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

> options are allowed with that.

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

Joe

---

From: Tom Herbert <[email-masked]>
Date: Tue, 18 Apr 2017 11:16:53 -0700

> If that's your concern, you need to use true transport-layer or network
1) Yes, that is my concern. UDP is already dicey in terms of security,
the risks introduced with these extensions needs to be thoroughly
vetted before I'd ever deploy in my network
2) It can't be a requirement to turn up security everywhere just to
use UDP options
3) My example is a contrived attack against the new protocol that
might be deployed, the mitigations to defend such an attack should be
part of the protocol not deferred to some other layer

> those that support authentication or encryption.
That's misses the crux of my argument. In my example, an attacker
forged a packet with can be "correctly" interpreted as either fragment
or a non-fragment. Which interpretation depends on the node that
processes it (sort of a Copenhagen Interpretation for network
protocols I suppose :-) ). But a packet cannot simultaneously be a
fragment and a not fragment, that is nonsensical (packets don't have
duality in this instance). This must be considered an error condition.
This ambiguity does not occur in IP or IPv6 and has been introduced by
the protocol specification not incorrect implementation. It's unlikely
in practice that this would cause problems, however, as I mentioned
above, if this can be exploited as a security vulnerability that will
be a concern of mine.

I thought a one point there was the idea that the UDP checksum would
be incorrect so that in the case I describe above a fragment would be
dropped and not misinterpreted by a node that doesn't support
fragments. Is there a reason that wouldn't work?

Tom

---

From: Joe Touch <[email-masked]>
Date: Tue, 18 Apr 2017 11:36:15 -0700

> vetted before I'd ever deploy in my network
Do you feel the same about new TCP options?

> 2) It can't be a requirement to turn up security everywhere just to
It isn't for new TCP options either, though.

> part of the protocol not deferred to some other layer
The protocol extension already includes OCS and AE for that reason,
though there's no way that UDP can protect the entire IP header too
(that's what IPsec is designed for).

> duality in this instance). This must be considered an error condition.
The solution to your  example would be for the protocol to allow only
the hidden FRAG mechanism. Right now that's optional.

However, note that forged packet can add a new extension that has two
effects - one for upgraded endpoints, one for legacy - already. In TCP.

The solution to *that* ambiguity is to confirm new options before using
them and use them only when confirmed - as noted in Section 10.

> the protocol specification not incorrect implementation. 
It occurs the same way you could forge a new IP option that is accepted
or ignored, depending on the endpoint support.

> It's unlikely

I'm not sure - again, I think your concerns about misinterpreting the
data are addressed by allowing only FRAG as LITE.

But I'm not sure I understand the example.

Consider that if I can forge a FRAG, I can forge an entire UDP packet. I
don't need anything new to have this vulnerability.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Tue, 18 Apr 2017 12:33:26 -0700

> But I'm not sure I understand the example.
My example is should be simple packet:

IP|UDP|UDP_payload|FRAG_option

I think if a legacy host receives this they accept it as a regular UDP
packet, if a host with support received it they see a UDP fragment
packet. (This is UDP, not UDP LITE)

My suggestion to use UDP checksum in combination with length to
eliminate this ambiguity:

Sender host:
- Length includes UDP options
- UDP checksum covers everything up to IP length
- Checksum over UDP options is nonzero (add an option if necessary to
force this)
- Protocol agnostics HW checksum offload should just work

Receiver that support options:
- Note IP length != UDP length so options may be present
- Validate checksum that covers everything up to IP length (sum to
zero with pseudo header included)
- Check IP options sum to non-zero
- Requirements for validating UDP checksum have been met, UDP options
are valid and checksummed

Receive that does not support options:
- Since IP options part summed to non-zero, UDP checksum will be bad,
packet is simply dropped
- This is equivalent to packet dropped because options not supported

Now our attacker can either forge fragment or forge a normal packet,
but not both at the same time. UDP checksum will only be valid for one
of two interpretations.

In other words the combination of length and UDP checksum can be used
to identify UDP options with high probability and disallows
misinterpretation scenario above. This also will work with HW checksum
offload and obviates the need to have separate checksum in the UDP
options.

Tom

---

From: Joe Touch <[email-masked]>
Date: Tue, 18 Apr 2017 13:00:26 -0700

Hi Tom,

> packet. (This is UDP, not UDP LITE)
We already discuss this as a bad idea until you confirm FRAG support
with the other end of the socketpair.

Another solution is to only use FRAG with LITE, but that adds overhead
you might not need  - which is why I think the protocol spec should say
"SHOULD use FRAG with LITE" and "MAY use FRAG without LITE but only
where confirmed".

> - Length includes UDP options
I'm guessing you mean IP length (which would have to); UDP length cannot
(we can't find the options and they'd be misinterpreted as user data by
legacy hosts).

> - UDP checksum covers everything up to IP length
But that's not the current definition, which means you'll break any UDP
checksum software/hardware (NATs, offload).

> - Since IP options part summed to non-zero, UDP checksum will be bad,
That means you'll be dropped by NATs too... which is something the
current approach avoids.

> but not both at the same time. UDP checksum will only be valid for one
Attackers can forge anything. Why would they bother with this sort of
stuff? Why wouldn't they just forge real content that all endpoints
would think is valid?

> offload and obviates the need to have separate checksum in the UDP
I'm still missing something here.

A forger can forge anything it wants (again, presuming no UDP AE or
IPsec). It can forge both a fragment and a normal packet and send them
both in - thus interfering with either receiver variant. I don't see
what's magic about a single packet that both endpoints interpret - but
if that's the concern, the FRAG/LITE already avoids that and can be used.

Joe