In message <00f801d0ca37$12d7d0d0$38877270$@rozanak.com>, "Hosnieh Rafiee"
writes:
> Hi Mark,
> Sorry for my late response and thanks for sharing your experiment. I have
> been busy so far...
>
> In your real world scenario, the place of attacker is missing. Your
> experiment shows that how client and server uses this mechanism and how they
> add the client and server cookie. But what it doesn't show is that how the
> server reacts when the attacker is also doing its attack either at the same
> time as the client request or at completely different time.
>
> And the question that I have asked and not answered is that how this
> approach can additional protection to Response Rate Limit for the server
> side to mitigate DNS amplification attack on client.
>
> As I understood from the previous discussions and the content of the draft,
> there are some strong assumptions in the draft:
> 1- Server stores client cookie for a short period of time (say some
> seconds) before it returns the cookie error message to client if the client
> cannot sends its query immediately after sending initial cookie message.
> 2- The attacker is not aware of any previous communication between the
> client and server
> 3- server and client's cookie might be different for different request.
>
> Now, to show you why I am not convinced with the server_cookie, I give you a
> simple example. Unfortunately, I didn't have time to change your
> implementation to play the role of attacker so that in a same way show you
> how I can attack your code.
>
> Scenario 1: according to [2]; Eve, my attacker, doesn't know what is going
> on between Alice and server. But Eve knows the IP address of Alice. Eve
> sends a DNS request with Alice's source address and includes a cookie
> (client_cookie1) that she generated it herself.
> Server neither knows Alice nor Eve and cannot identify them. Because this
> approach cannot prevent IP spoofing. When server receives a DNS query
> request with client_cookie1 from Eve, it generates a server_cookie1 and
> submits it to Alice.
> Eve repeats this process with new client_cookie_i where i={2,..., n}, and
> submits these messages with Alice's source IP address to the server. If the
> server still has the client_cookie1 in its memory and waiting for original
> Alice to send it message, then since client_cookie_i <> client_cooki1,
> server considers Eve's new messages with new cookies as new requests and
> starts answering them with server cookie and Alice receives unrelated
> message from the server. So, this means DNS amplification is still possible
> because there is no way to authenticate Alice. DNS server only knows the
> cookie. So, instead of improving the situation, only the draft changed the
> attack to different type that is server_cookie amplification attack. ( of
> course, since the attack is cookie amplification and cookies are edible... I
> think everyone wants to be in place of Alice :-) ... )
> So, Eve is successful in attacking Alice as server_side cookie didn't help.
>
> Now, this is the same situation if at the same time Alice starts a query
> request and Eve also starts its attack. S
>
> Now, if RRL is implemented in the server, then server_cookie doesn't have
> any additional help to the server and only increase the message size and
> processing time (although so small) for generating cookies.
The server can respond to with a BADCOOKIE response which adds only
a server cookie to the size of the request. These too can be rate
limited. This is minimal amplification which is about the equivalent
of adding a single unsigned A record (12 bytes vs 16 bytes of the
seerver cookie) to a response.
Sending queries with fake cookies doesn't result in enough amplification
to be worth the effort even without rate limiting. It is effectively
a reflection attack, not a amplifying reflection attack and it keeps
the followup transactions for Alice on UDP rather than switching
them to TCP (which happens without cookies).
Once Alice has a server cookie then the the server skips all the
rate limiting on future transactions from Alice (but not the attacker)
until the server cookie times out / is forgotten.
Mark
> Best,
> Hosnieh
>
> > -----Original Message-----
> > From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Mark Andrews
> > Sent: Tuesday, July 21, 2015 7:19 AM
> > Cc: DNSOP@ietf.org; Hosnieh Rafiee
> > Subject: Re: [DNSOP] Review of draft: draft-ietf-dnsop-cookies
> >
> >
> > Hosnieh, below is a real life use of cookies showing how they are used.
> >
> > Establish a cookie pair. Dig chooses a random value for the client
> cookie. The
> > server returns the client cookie along with the server cookie. The client
> > cookie is checked and as it matched "good" is displayed.
> >
> > ; <<>> DiG 9.11.0pre-alpha <<>> +qr +header-only +cookie ;; global
> options:
> > +cmd ;; Sending:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55152 ;; flags: rd ad;
> > QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
> >
> > ;; OPT PSEUDOSECTION:
> > ; EDNS: version: 0, flags:; udp: 4096
> > ; COOKIE: 9310320f2fa1e6e9
> > ;; QUESTION SECTION:
> >
> > ;; QUERY SIZE: 35
> >
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55152 ;; flags: qr rd;
> > QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion
> > requested but not available
> >
> > ;; OPT PSEUDOSECTION:
> > ; EDNS: version: 0, flags:; udp: 4096
> > ; COOKIE: 9310320f2fa1e6e9e0be33ca55adca652422864a7cc8b23b (good)
> > ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Jul
> 21
> > 14:28:21 EST 2015 ;; MSG SIZE rcvd: 51
> >
> > Ask for isc.org using the cookie pair established above. You will not the
> that
> > client cookie is returned but there is a new server cookie. The client
> cookie is
> > checked to confirm that it the expected value and "good"
> > is printed.
> >
> > ; <<>> DiG 9.11.0pre-alpha <<>>
> > +cookie=9310320f2fa1e6e9e0be33ca55adca652422864a7cc8b23b isc.org
> > +nobadcookie ;; global options: +cmd ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39845 ;; flags: qr rd
> ra
> > ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> >
> > ;; OPT PSEUDOSECTION:
> > ; EDNS: version: 0, flags:; udp: 4096
> > ; COOKIE: 9310320f2fa1e6e90eebb3b455adcabf6153631b35e9055f (good)
> > ;; QUESTION SECTION:
> > ;isc.org. IN A
> >
> > ;; ANSWER SECTION:
> > isc.org. 59 IN A 149.20.64.69
> >
> > ;; Query time: 109 msec
> > ;; SERVER: 127.0.0.1#53(127.0.0.1)
> > ;; WHEN: Tue Jul 21 14:29:51 EST 2015
> > ;; MSG SIZE rcvd: 80
> >
> > Ask for ietf.org using the initial cookie pair established above. Again
> we get a
> > new server cookie but the client cookie remains unchanged.
> >
> > ; <<>> DiG 9.11.0pre-alpha <<>>
> > +cookie=9310320f2fa1e6e9e0be33ca55adca652422864a7cc8b23b ietf.org
> > +nobadcookie ;; global options: +cmd ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10176 ;; flags: qr rd
> ra
> > ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> >
> > ;; OPT PSEUDOSECTION:
> > ; EDNS: version: 0, flags:; udp: 4096
> > ; COOKIE: 9310320f2fa1e6e9d3a8b98e55adcb18873b8a4389876d3e (good)
> > ;; QUESTION SECTION:
> > ;ietf.org. IN A
> >
> > ;; ANSWER SECTION:
> > ietf.org. 1562 IN A 4.31.198.44
> >
> > ;; Query time: 243 msec
> > ;; SERVER: 127.0.0.1#53(127.0.0.1)
> > ;; WHEN: Tue Jul 21 14:31:20 EST 2015
> > ;; MSG SIZE rcvd: 81
> >
> > Ask for isc.org using the cookie from the ietf.org transaction.
> >
> > ; <<>> DiG 9.11.0pre-alpha <<>>
> > +cookie=9310320f2fa1e6e9e0be33ca55adca652422864a7cc8b23b isc.org
> > +nobadcookie ;; global options: +cmd ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25652 ;; flags: qr rd
> ra
> > ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> >
> > ;; OPT PSEUDOSECTION:
> > ; EDNS: version: 0, flags:; udp: 4096
> > ; COOKIE: 9310320f2fa1e6e9c721e37455adcb65ddaab534d313d697 (good)
> > ;; QUESTION SECTION:
> > ;isc.org. IN A
> >
> > ;; ANSWER SECTION:
> > isc.org. 46 IN A 149.20.64.69
> >
> > ;; Query time: 98 msec
> > ;; SERVER: 127.0.0.1#53(127.0.0.1)
> > ;; WHEN: Tue Jul 21 14:32:37 EST 2015
> > ;; MSG SIZE rcvd: 80
> >
> > Now if I was to wait long enough before retrying the server would return
> > BADCOOKIE as the server cookie will have expired. dig could then just
> resend
> > the query with the server cookie.
> >
> > Now there server can rate limit the BADCOOKIE responses or accept that it
> > can be used as a reflector. Note you are no longer a amplifier.
> >
> > Now while the client has a valid server cookie it is not subject to rate
> limiting
> > or response size limiting unless the server has otherwise been configured
> to
> > do so.
> >
> > Now if I send a deliberately bad server cookie (7 changed to 8 at
> > end) I will get BADCOOKIE returned (currently #ifdef out until we get a
> > badcookie code point in the git repository).
> >
> > ; <<>> DiG 9.11.0pre-alpha <<>>
> > +cookie=9310320f2fa1e6e9c721e37455adcb65ddaab534d313d698
> > +nobadcookie isc.org ;; global options: +cmd ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: BADCOOKIE, id: 59408 ;; flags: qr
> aa
> > rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
> >
> > ;; OPT PSEUDOSECTION:
> > ; EDNS: version: 0, flags:; udp: 4096
> > ; COOKIE: 9310320f2fa1e6e9694856ae55add44dfa9fce2ea17b916a (good) ;;
> > QUESTION SECTION:
> > ;isc.org. IN A
> >
> > ;; Query time: 0 msec
> > ;; SERVER: 127.0.0.1#53(127.0.0.1)
> > ;; WHEN: Tue Jul 21 15:10:37 EST 2015
> > ;; MSG SIZE rcvd: 64
> >
> > And if I let dig retry on BADCOOKIE showing the queries.
> >
> > ; <<>> DiG 9.11.0pre-alpha <<>>
> > +cookie=9310320f2fa1e6e9c721e37455adcb65ddaab534d313d698 isc.org
> > +qr ;; global options: +cmd ;; Sending:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14321 ;; flags: rd ad;
> > QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
> >
> > ;; OPT PSEUDOSECTION:
> > ; EDNS: version: 0, flags:; udp: 4096
> > ; COOKIE: 9310320f2fa1e6e9c721e37455adcb65ddaab534d313d698
> > ;; QUESTION SECTION:
> > ;isc.org. IN A
> >
> > ;; QUERY SIZE: 64
> >
> > ;; BADCOOKIE, retrying.
> > ;; Sending:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45311 ;; flags: rd ad;
> > QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
> >
> > ;; OPT PSEUDOSECTION:
> > ; EDNS: version: 0, flags:; udp: 4096
> > ; COOKIE: 9310320f2fa1e6e9d2dbffae55add4d6e80616c008c6ab6a
> > ;; QUESTION SECTION:
> > ;isc.org. IN A
> >
> > ;; QUERY SIZE: 64
> >
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45311 ;; flags: qr rd
> ra
> > ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> >
> > ;; OPT PSEUDOSECTION:
> > ; EDNS: version: 0, flags:; udp: 4096
> > ; COOKIE: 9310320f2fa1e6e975a21e9055add4d67e2fec58601d0df4 (good)
> > ;; QUESTION SECTION:
> > ;isc.org. IN A
> >
> > ;; ANSWER SECTION:
> > isc.org. 59 IN A 149.20.64.69
> >
> > ;; Query time: 108 msec
> > ;; SERVER: 127.0.0.1#53(127.0.0.1)
> > ;; WHEN: Tue Jul 21 15:12:54 EST 2015
> > ;; MSG SIZE rcvd: 80
> >
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
> >
> > _______________________________________________
> > DNSOP mailing list
> > DNSOP@ietf.org
> > https://www.ietf.org/mailman/listinfo/dnsop
>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
