Re: [tsvwg] Possible UDP-Option: Cookie

[tjw ietf <[e-mail]>]

https://datatracker.ietf.org/doc/rfc7873/

You know of the DNS cookies standard right?

Tim

From my high tech gadget

> On Mar 20, 2019, at 03:07, 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.
> 
> 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
>