Re: [tsvwg] Possible UDP-Option: Cookie

[Tom Herbert <[e-mail]>]

On Wed, Mar 20, 2019 at 11:07 AM Derek Fawcus
<[e-mail]> wrote:
>
> 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.
>
Derek,

You might want to look at something similar to QUIC identifiers as the
cookie. That is a much more accuate way to identify and validate a
sender of UDP than by source address which can be unreliable or
inconsistent. For instance, QUIC identifiers handle the common case of
UDP state eviction in NAT where the apparent peer source address
changes mid-flow without any indication to the endpoints that
something happened.

Tom

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