[tsvwg] Possible UDP-Option: Cookie

[Derek Fawcus <[e-mail]>]

On Wed, Mar 20, 2019 at 12:13:09AM +0100, Derek Fawcus wrote:
> We have the DNS request use case, we want to be able to send a packet
> containing options expressing that we can receive Segmented UDP data.
> 
> A legacy stack, or legacy server on a new stack will not see those
> options, but will reply to the basic UDP packet - possibly generating
> an IP fragmented response.  A new server on a new stack will be able
> to send a UDP segmented response.
> 
> There could well be other examples falling in to that scenario.

The above got me wondering about current UDP reflected expansion attacks
using a spoofed source address, of which DNS is a case that has been
exploited.  What we're proposing with the Segmented UDP data mechanism
could be similarly exploited in the future.

So do we need some text in the security considerations section to discuss
this, or maybe even a new cookie option to allow for a form of soft state
acknowledged handshake?

Assume we have an option like:

                   +--------+-------------+-----+------+---------+--
                   | Kind=X | Len=2/4/4+n |  lifetime  |  cookie |
                   +--------+-------------+-----+------+---------+--

                             UDP Cookie option format

Where we have 3 possible lengths, one with no payload, one for sending
lifetime alone, one for sending lifetime and cookie.  The cookie when
present is of variable length.  The no payload form would simply be
used to indicate that the option is supported.

Then for users who might benefit, we could have an exchange like:

1. A -> B : UDP data | Options: Cookie(lifetime-q1)
2. B -> A : UDP data | Options: Cookie(lifetime-r1,cookie-1)
3. A -> B : UDP data | Options: Cookie(lifetime-q2,cookie-1)
4. B -> A : UDP data | Options: Cookie(lifetime-r2,cookie-2)
...
5. B -> A : UDP data | Options: Cookie(lifetime-q3,cookie-2)

at 1 A sends a message, including a desire for a cookie with lifetime q1.
at 2 B responds, including a cookie of arbitrary length and lifetime r1.
at 3 A sends a message, where the cookie inherently validates its source address.
at 4 B responds, including fresh cookie data, but now knowing it can now send
       larger reponses.

i.e. this adds an optional generic 'soft state' connection acknowledge
mechanism to UDP, which could then be used by various applications.

The above could then be combined with sending the Segmentation/FRAG options
to perform parallel negotiation of that capability,  I'd imagine that for
the DNS query case we could end up with something like:

1. A -> B | Q=A, N=example.com, EDNS-sz=Y | Options: Cookie(life); MSS(); FRAG()
2. B -> A | Q=A, N=example.com, EDNS-sz=Y, trunc | Options: Cookie(life,value1); MSS(); FRAG()
3. A -> B | Q=A, N=example.com, EDNS-sz=Y | Options: Cookie(life,value1); MSS(); FRAG()
4. B -> A | | Options: Cookie(life,value2); MSS(); FRAG(Q=A, N=example.com, A=1.2.3.4, EDNS-sz=Z)
...
n. B -> A | | Options: Cookie(life,value2); MSS(); FRAG(Q=A, N=example.com, A=1.2.3.4, EDNS-sz=Z)

For the case of a legacy server, this would probably fall back to one of
IP fragmented UDP response packet at 2 (EDNS support, no truncated response),
or opening a TCP connection at stage 3 (because stage 2 would have been a
truncated response).

i.e. rather than force the client to switch to TCP, or sending an IP fragmented
UDP response, we would be able to acknowledge that it is safe to send a large
amount of DNS response in many segmented UDP packets, that the source of the
query was not spoofed, and then the subsequent second query would trigger that.

I suspect there may be cases where we do not need to segment the response,
but since it would be significantly larger than the request,  such an
acknowledgement pattern may prove useful.

DF