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.
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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
