Subject: [DNSOP] Review of draft: draft-ietf-dnsop-cookies

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sat, 18 Jul 2015 19:30:18 +0200

Hello,

I have reviewed this draft. My comments are as followings:

- Section 3.2 <snip> TKEY can solve the problem ..</snip> 
IMO TKEY also needs some manual preconfiguration on the server side. So, it
does not completely solve the TKEY distribution problem. 
furthermore This is only applicable to recursive resolvers and authoritavie
servers.Therefore, for client communications, it has the same barriers as
DNSSEC has for clients (trusted anchors,etc.)

If the victim node is behind NAT (servers are not behind NAT), and attacker
is not in the same network, IMO, it cannot perform any amplification or DoS
attack on the victim node. unless otherwise, the attacker is aware of the
communication and ports used for the clients behind the NAT. Therefore, the
use of this mechanism is not applicable in such situation. Therefore, I do
not see any use case for nodes behind NAT. 
If the client has a global IP address, for example if it uses IPv6 that
usually the IP address is global, then the attacker has a possibility to
perform the DoS attack even though the client uses this method. because:

- As far as I understood from the method, It is similar to enclosed figures
(the algorithm is only arbitrary algorithm but this really does not matter).
The problem is that still amplification and spoofing or any attacks
explained in the draft is possible The reasons are as follows:

1- client doesn't know the random number used by the server to calculate the
servers' cookie response. if it needs to know then it returns to the barrier
of sharing this value between clients and servers
2- The server has no way to authenticate the client. so, it also accepts any
arbitrary request from the attacker with forged IP address. Using cookie
also doesn't help otherwise 
* the client uses the global IP address
* the attacker could not sniff the first communication when the client sends
its cookie
* the server stores the cookie and its mapping to the IP address of the
client (this doesn't make sense for NAT as there are more than one node
behind a single Ip address)
Furthermore:
3- the server doesn't know the random number used by client to calculate
client_cookie therefore if the server doesn't store this mapping (that in
public resolvers it does not make sense) the resolver cannot authenticate
the client and it also accepts cookies from the attacker
* training data only temporary solve the problem, only in case the attacker
doesn't sniff the trained data, but for longer period, both node (client and
server) needs to store state information which is similar to problem of
other security approaches such as DNS data security that needs to keep state
information. 

The algorithm used by client and server to generate cookies doesn't change
the attack circumstances. Because there are no way for the server to
authenticate client. Furthermore, attacker is free to choose any IP address
and generate its cookie. this will be result in higher chance for DoS attack
since the server needs to calculate the cookie for each request, even
though, the time is small but it is bigger than when the server does not use
cookie
Unless otherwise, server store every single mapping of clients to their
cookies (as explained earlier) which is not practical in public DNS
resolvers specially for IPv6 address that the address space is large. what
is the database to keep such mapping?? what is the search method?? this is
also useless because the client IP might be temporary or random and changes
or the clinet no longer use an IP address.

So IMO, as a result it cannot provide the protection it explains in the
draft.

Furthermore, It appears that the assumption of this draft is that the
attacker cannot sniff the client's and server's messages therefore, it
cannot forge this message. IMO, this assumption is not true.
If the attacker cannot sniff the messages between clients and servers, it
doesn't know also to forge which IP address to have an efficient attack.
IMO, it is not a true assumption. Attacker starts any attacks by having a
pre-defined phase to know its victims...

In general, based on my understanding from the mechanism, it does not
protect what it supposed to protect and It only adds a new data to the DNS
messages and includes processing times without providing the mentioned
value.
If I mis-understood the mechanism please explain.
thanks,
Best,
Hosnieh

---

From: Mark Andrews <[email-masked]>
Date: Sun, 19 Jul 2015 12:58:52 +1000

> not see any use case for nodes behind NAT. 

It can DoS the path to the NAT.  All the attacker needs is the
public address of the NAT.  For the DoS stream to go through the
NAT assuming it is a stateful NAT then yes the attacker needs more
knowledge.

> of sharing this value between clients and servers

The client sends queries only with client cookies initially.  These
are treated like any other unauthenticated query.  They are subject
to rate limiting of responses and sending back minimal responses
(rcode=BADCOOKIE or TC=1).

> behind a single Ip address)

Well the server does not store any state.  All state is stored by
the client. The server uses a the IP address and the client cookie
and the server secret to compute a server cookie.  This it adds to
the response then discards.

> the client and it also accepts cookies from the attacker

Yes it can.  It has all the inputs required to re-compute the server
cookie when there is another query.

> other security approaches such as DNS data security that needs to keep state

When the client discards the server cookie it has to re-establish
it.  It is up to the client to determine the resources it needs.

> though, the time is small but it is bigger than when the server does not use

Yes, it uses some computing resources on the server.  You have to compare
them against looking up the cost of looking up the requested data.

> or the clinet no longer use an IP address.

Which is why there is no storage on the server.

> So IMO, as a result it cannot provide the protection it explains in the

It is designed to allow large responses to be returned to the client
when they are legitimate queries and not have large responses
returned to the client when they are forged.  This happens in
conjuction with other filtering techniques like response rate
limiting and help by leaving the traffic on UDP instead of moving
it to TCP.

> pre-defined phase to know its victims...

The attacker starts out by knowing the IP address of the victim.
It then uses DNS servers as amplifiers.  In many cases knowing the
IP address of the victim also gives you their recursive server as
that is well known.  When this happens you not only have garbage
responses being sent to victim of the amplification attack but you
also have there queries being dropped.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sun, 19 Jul 2015 08:29:52 +0200

Mark,

Thanks for your explanation. My comments are inline...

> -----Original Message-----
> From: DNSOP [mailto:[email-masked]] On Behalf Of Mark Andrews

> > If the victim node is behind NAT (servers are not behind NAT), and
> > attacker is not in the same network, IMO, it cannot perform any
> > amplification or DoS attack on the victim node. unless otherwise, the
> > attacker is aware of the communication and ports used for the clients
> > behind the NAT. Therefore, the use of this mechanism is not applicable
> > in such situation. Therefore, I do not see any use case for nodes behind
> NAT.
> 
> It can DoS the path to the NAT.  All the attacker needs is the public
address of
> the NAT.  For the DoS stream to go through the NAT assuming it is a
stateful
> NAT then yes the attacker needs more knowledge.

So, you want such mechanism is implemented in NAT devices to protect all
clients in that network, right? If not, the implementation of that in a
single client behind the NAT, doesn't help all the clients inside that NAT
network because the target is a public address of this device and other
devices are not seen. This is , of course, according to your argument. 

Because if the attacker is using the public address of the NAT device then
it is the NAT device who is the target of DoS.

Then, if the mechanism wants to be applicable, then NAT device is the device
which needs to implement this mechanism and not each client and add this
option to any packet passes it that targets a recursive DNS server or store
the state of server cookie.

> > If the client has a global IP address, for example if it uses IPv6
> > that usually the IP address is global, then the attacker has a
> > possibility to perform the DoS attack even though the client uses this
> method. because:
> >
> > - As far as I understood from the method, It is similar to enclosed
> > figures (the algorithm is only arbitrary algorithm but this really does
not
> matter).
> > 1- client doesn't know the random number used by the server to
> > calculate the servers' cookie response. if it needs to know then it
> > returns to the barrier of sharing this value between clients and
> > servers
> 
> The client sends queries only with client cookies initially.  These are
treated
> like any other unauthenticated query.  They are subject to rate limiting
of
> responses and sending back minimal responses (rcode=BADCOOKIE or TC=1).

If the server doesn't keep the state, then based on the algorithms explained
in the draft, the server cannot differentiate between different clients and
each time it might generate a new server_cookie for each requests (I had it
in my previous message on the  figure attached to the message) because:
[1] Server_cookie=Pseudo_function(client_cookie + server_secret) 

Therefore, even though, the client stores state about the server_cookie,
each time for each query request, server will give it back a new cookie that
clients cannot compare and calculate it and it is like a completely new
query.

Furthermore, if we assume that the algorithm is like the following, so that
the server produces, everytime, the same cookie for the client and if the
assumption is that the client knows the IP address of the server, then the
attacker still has the possibility to spoof the source IP of DNS server
because there is no actual server authentication and no one can proof that
the message comes from the legitimate DNS server.
[2] Server_cookie=Pseudo_function(client_cookie) 

So, in [2] the attacker once ask for a query from this DNS server, it can
get to know how DNS server calculates the cookie and since it is not
changeable over the time, the attacker can spoof the DNS server.

In other word, training phase in not useful in both scenario and keeping
state on client doesn't also help to mitigate the attack. 

> > 2- The server has no way to authenticate the client. so, it also
> > accepts any arbitrary request from the attacker with forged IP
> > address. Using cookie also doesn't help otherwise
> > * the attacker could not sniff the first communication when the client
> > sends its cookie
> > * the server stores the cookie and its mapping to the IP address of
> > the client (this doesn't make sense for NAT as there are more than one
> > node behind a single Ip address)
> 
> Well the server does not store any state.  All state is stored by the
client. The
> server uses a the IP address and the client cookie and the server secret
to
> compute a server cookie.  This it adds to the response then discards.
> 
> > Furthermore:
> > 3- the server doesn't know the random number used by client to
> > calculate client_cookie therefore if the server doesn't store this
> > mapping (that in public resolvers it does not make sense) the resolver
> > cannot authenticate the client and it also accepts cookies from the
> > attacker
> 
cookie
> when there is another query.

Unfortunately it cannot. According to my previous paragraph. I would like to
think really optimistic but sorry I cannot as I put myself in the shoes of
an attacker...

> > * training data only temporary solve the problem, only in case the
> > attacker doesn't sniff the trained data, but for longer period, both
> > node (client and
> > server) needs to store state information which is similar to problem
> > of other security approaches such as DNS data security that needs to
> > keep state information.
> 
> When the client discards the server cookie it has to re-establish it.  It
is up to
> the client to determine the resources it needs.

But this resources doesn't really help when the server uses a server_secret
as an input to its function. The server cookie is different each time.
Although, both uses Diffie-Hellman Key exchange algorithm (and of course
need a phase for key cipher agreement and so on) to be on a same page, but
it only works for one query and for each query there will be a new value and
need a new exchange of the cookies. 

It also make sense to have an experiment and compare the case where the
client uses this approach and not using it. Because I think the time to
calculate the cookie for server is the same, if it is not more, as the
client try to process the query response from the DNS server and notice that
it didn't ask it and it was only a DoS attack. 

This is because you are adding another processing time which IMO, not
necessary as I do not see it can protect the clients according to the
arguments. 

> > The algorithm used by client and server to generate cookies doesn't
> > change the attack circumstances. Because there are no way for the
> > server to authenticate client. Furthermore, attacker is free to choose
> > any IP address and generate its cookie. this will be result in higher
> > chance for DoS attack since the server needs to calculate the cookie
> > for each request, even though, the time is small but it is bigger than
> > when the server does not use cookie
> 
> > Unless otherwise, server store every single mapping of clients to
> > their cookies (as explained earlier) which is not practical in public
> > DNS resolvers specially for IPv6 address that the address space is
> > large. what is the database to keep such mapping?? what is the search
> > method?? this is also useless because the client IP might be temporary
> > or random and changes or the clinet no longer use an IP address.
> 
> > So IMO, as a result it cannot provide the protection it explains in
> > the draft.
> 
> It is designed to allow large responses to be returned to the client when
they
> are legitimate queries and not have large responses returned to the client
> when they are forged.  This happens in conjuction with other filtering
> techniques like response rate limiting and help by leaving the traffic on
UDP
> instead of moving it to TCP.

> > If the attacker cannot sniff the messages between clients and servers,
> > it doesn't know also to forge which IP address to have an efficient
attack.
> > IMO, it is not a true assumption. Attacker starts any attacks by
> > having a pre-defined phase to know its victims...
> 
> It then uses DNS servers as amplifiers.  In many cases knowing the IP
address
> of the victim also gives you their recursive server as that is well known.
When
> this happens you not only have garbage responses being sent to victim of
the
> amplification attack but you also have there queries being dropped.

If the victim is behind the NAT, the attacker only sees the NAT IP address. 
If the recursive DNS server of the victim has a public address, the attacker
can apply its attacks on NAT IP and not the single client IP (unless it also
knows what ports map to xxx client)  So, IMO, the NAT device is target and
therefore, implementation of this mechanism in client doesn't help as the
bottleneck is on NAT device. 

Best,
Hosnieh

---

From: Mark Andrews <[email-masked]>
Date: Sun, 19 Jul 2015 22:29:04 +1000

> devices are not seen. This is , of course, according to your argument. 

It helps those clients behind the NAT that implement cookies.
 
> the state of server cookie.

Having middle boxes modify packets is a *bad* *idea*.
 
> clients cannot compare and calculate it and it is like a completely new

The client doesn't check the server cookie returned.  It just stores
it.  The client checks the client cookie.  The server checks the
server cookie.

> [2] Server_cookie=Pseudo_function(client_cookie) 

Server_cookie=Pseudo_function(client cookie+client address+server secret)

The client checks the client cookie *before* accepting the server cookie.

> changeable over the time, the attacker can spoof the DNS server.

No.  The attacker doesn't see the reply traffic from the server.

> think really optimistic but sorry I cannot as I put myself in the shoes of

Yet, we have code that does this.
 
> need a new exchange of the cookies.

No.
 
> it didn't ask it and it was only a DoS attack. 

The server is free to use different algorithms to generate it's key.
DNS COOKIE doesn't specify the exact algorithm to use.

> bottleneck is on NAT device. 

It helps the clients that use it.

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sun, 19 Jul 2015 15:19:30 +0200

> > So, you want such mechanism is implemented in NAT devices to protect
> > all clients in that network, right? If not, the implementation of that
> > in a single client behind the NAT, doesn't help all the clients inside
> > that NAT network because the target is a public address of this device
> > and other devices are not seen. This is , of course, according to your
> argument.
> 

When the clients are not seen, I just wonder how the attacker can target
them??
NAT device doesn't know what to do with packets that coming from a xx
machine that the source address is its own address without seeing any more
information regarding ports, etc. so that it can redirect the requests to
the target client.  Either our definition from NAT device is different that
is we are talking about two different device with two different
functionality or there is a new generation of NAT devices that are so
intelligent and know what to do when they receive undefined packets.

> > Because if the attacker is using the public address of the NAT device
> > then it is the NAT device who is the target of DoS.
> >
> > Then, if the mechanism wants to be applicable, then NAT device is the
> > device which needs to implement this mechanism and not each client and
> > add this option to any packet passes it that targets a recursive DNS
> > server or store the state of server cookie.
> 

Might be, but this is also not applicable.

> The client doesn't check the server cookie returned.  It just stores it.
The
> client checks the client cookie.  The server checks the server cookie.

If the client does not check the server cookie in a initial step, then why
don't you send anything to server so that the server needs also to do some
processes which, of course, need processing time and this is vital for the
server. Take it easy and Only keep the state in your client similar to the
following simple example and do not bother server as based on the arguments
and the explanation in the draft, the involvement of the server doesn't help
neither in authenticating the server nor doing any prevention of attacks. In
other word, the server only do some steps that is not necessarily help the

> DNS COOKIE doesn't specify the exact algorithm to use.

Simple Example that has the same impact as dnsop-cookies mechanism:
Client A sends a query to DNS server A. Client A stores the state (e.g.
query for www.example.com  status: sent    response: false)
The DNS server responds this client with the query response. Client checks
its state storage and found that the "response" value was false. So it
accepts the value from the server since it was waiting for a response. Then
remove this state from its state storage as it no longer needs to ask any
query.
Now, the bad guy wasn't aware of those communication but, with a miracle,
found that what IP address is used by Client A so that he can target this
client who is behind the NAT. So the bad guy sends a lot of query requests
to the server with spoofed client IP address as a source address. DNS server
sends query responds to the victim client (Client A). Victim client only
check its state storage and found that it never request for any query. So,
it silently discard all queries.

Now about miracle part, I do not know how the attacker can obtain the IP
address of the client without sniffing the communication or has a
possibility to eavesdrop. If he can eavesdrop, then he also can know all the
information exchanged between client and the server.

Therefore, I am still confused that how this scenario, even the simplest one
in my example, works behind the NAT. It works without NAT. 

I am also considering all possibilities such as the case the attacker is
also behind the same NAT. In that case, there is a higher chance for the
attacker to sniff the whole communication and even sends the query request
immediately to the DNS server the same time as the client sends a request to
the DNS server. Therefore, the client would be overwhelmed with many query
response from the DNS server to its request. In that case, the simple
example might not work too. 

> > Furthermore, if we assume that the algorithm is like the following, so
> > that the server produces, everytime, the same cookie for the client
> > and if the assumption is that the client knows the IP address of the
> > server, then the attacker still has the possibility to spoof the
> > source IP of DNS server because there is no actual server
> > authentication and no one can proof that the message comes from the
> legitimate DNS server.

Doesn't really different. As a mistake I forgot to include the IP address of
client. but in my first figure it exists.

> > So, in [2] the attacker once ask for a query from this DNS server, it
> > can get to know how DNS server calculates the cookie and since it is
> > not changeable over the time, the attacker can spoof the DNS server.
> 
> > Unfortunately it cannot. According to my previous paragraph. I would
> > like to think really optimistic but sorry I cannot as I put myself in
> > the shoes of an attacker...
> 

So please share the results. I am so curious.

Best,
Hosnieh

---

From: Mark Andrews <[email-masked]>
Date: Sun, 19 Jul 2015 23:56:29 +1000

> When the clients are not seen, I just wonder how the attacker can target

Clients talks to things other than DNS servers.  The attacker gets
the address of the address of the client from those transactions.

> intelligent and know what to do when they receive undefined packets.

There are two ends to the communication between the client and the
DNS server it is querying.  DNS COOKIES helps servers pick legitimate
client queries out of spoofed traffic. 

> Might be, but this is also not applicable.

But you just suggested that the NAT box do that.
 
> client. (this conclusion is according to your own explanation such as :

The server does the steps so that it can identify the client when
it talks to the server again.  This both helps the client and server.

> information exchanged between client and the server.

99.999% of DNS recursive amplifiying attacks result from non DNS
transactions which give away the address of the client.  No sniffing
required.

> So please share the results. I am so curious.

All versions of BIND 9.10 support a variant of DNS COOKIE called SIT.
This is a experimental compile option and is enabled by default in the
Windows binaries we ship.  https://source.isc.org for the git repository.

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Mon, 20 Jul 2015 03:05:38 +0200

> > When the clients are not seen, I just wonder how the attacker can
> > target them??
> 
> Clients talks to things other than DNS servers.  The attacker gets the
address of
> the address of the client from those transactions.

This is not highlighted in the draft which makes it confusing for the reader
which causes to raise such question regarding NAT.

> But you just suggested that the NAT box do that.

Because I did not know how the attacker would target a single node behind
the NAT without knowing the IP address (please refer to my last sentence).
Therefore, I saw the target as a whole network or the NAT device.

> > > The client doesn't check the server cookie returned.  It just stores
it.
> > If the client does not check the server cookie in a initial step, then
> > why don't you send anything to server so that the server needs also to
> > do some processes which, of course, need processing time and this is
> > vital for the server. Take it easy and Only keep the state in your
> > client similar to the following simple example and do not bother
> > server as based on the arguments and the explanation in the draft, the
> > involvement of the server doesn't help neither in authenticating the
> > server nor doing any prevention of attacks. In other word, the server
> > only do some steps that is not necessarily help the client. (this
conclusion is
> according to your own explanation such as :
> 
> The server does the steps so that it can identify the client when it talks
to the
> server again.  This both helps the client and server.

The server does not keep the state. So, how it can identify the client next
time when it starts to communicate to the server? This is not clear to me. I
think I highlighted this fact in all my previous messages.

If server thinks it communicated with this client before, only based on the
fact that the client also included server cookie, then since the server does
not store any state and each time the server might generate a new cookie,
then the attacker can create a fake cookie using the similar way as the
server generates its own cookie. That is :
fake_server_cookie=(fake_client_cookie + IP client (victim) +
attacker_secret) . It also generates a fake_client_cookie and in this way it
pretends that it had a previous communication with server. Since server is
not aware of the fact (no state in the storage), the server assumes that it
had a communication with this client before. Therefore, it answers the
attacker requests. The attacker does this with different values by
requesting large queries from the server but with spoofed source IP address
that is the source IP address of the client and still can perform the
amplification attack. 

Now about the client, it will be overwhelmed with a lot of query responds
from the server.  since the client stored the previous server_cookie but the
server_cookie might be different for each query. Therefore, the client might
be puzzled and it starts processing server messages. So, the attacker seems
to be successful. 

Therefore, the existence of server cookie did not help the client. So, I
would back to the previous simple example that is client only mechanism (the
following .. with considering the fact that the attacker no need to have a
miracle to know the IP of the client). 

> > The DNS server responds this client with the query response. Client
> > checks its state storage and found that the "response" value was
> > false. So it accepts the value from the server since it was waiting
> > for a response. Then remove this state from its state storage as it no
> > longer needs to ask any query.
> > Now, the bad guy wasn't aware of those communication but
found that what IP address is used by Client A so that he can
> > target this client who is behind the NAT. So the bad guy sends a lot
> > of query requests to the server with spoofed client IP address as a
> > source address. DNS server sends query responds to the victim client
> > (Client A). Victim client only check its state storage and found that
> > it never request for any query. So, it silently discard all queries.
> >

.
> Windows binaries we ship.  https://source.isc.org for the git repository.

Thanks

Some editorial comments:
Others might have different opinion, but while I was reading the draft,
after reviewing introduction, suddenly the attacks starts which still there
is nothing about the mechanism. So, I had to skip that section, review the
mechanism and back to attack sections. So, maybe it would be good to move it
to after the explanation of the mechanism?!

Best,
Hosnieh

---

From: Mark Andrews <[email-masked]>
Date: Mon, 20 Jul 2015 12:39:11 +1000

> which causes to raise such question regarding NAT.

Because it is irrelevent has to how the attacker chooses the address to
attack.  What is relevent is the impact the attack is happening and
how a server can sort some/all legitimate traffic from the client out
of the which is being spoofed.

> Therefore, I saw the target as a whole network or the NAT device.

Whether it is the client or the NAT it doesn't matter.  They are one and
the same as far as the world is concerned.
 
> think I highlighted this fact in all my previous messages.

The client keeps state: the client cookie it sent and the server
cookie returned.

* If it is a recursive server this state is keep with things like the
DNS PMTU of the server or if it supports EDNS.

* If it is a stub resolver it could be kept in a shared memory segment
that all of the stub resolvers instances can access or a well known
file or there could be a lightweight daemon than just remembers
cookies.  In all cases appropriate r/w locking needs to be done.  How
it is kept is not important.  Alternatively the stub could establish
its own cookie pair by sending a QCOUNT=0 query with only a client
cookie then send the query it want the answer to.

> had a communication with this client before.

No. The server takes the fake_client_cookie + IP client (victim) +
server secret + maybe parts of server cookie itself.  Computes a
server cookie and compares that with what was received.  If and
only if that matches (1 in 2^64) does the fake query get treated
legitimate.

> Therefore, it answers the

It can attempt a amplification attack.  As I stated earlier and in
the document this is used in conjuction with other things like
resource rate limiting.

A client with a good server cookie avoids being rate limited.

A cookie client with a bad/no server cookie gets a non/minimally
amplified (add server cookie size) badcookie response rather then
a TC=1 response after going through the rate limiter.

A server can choose to always send badcookie if there is no server
cookie in the cookie opt or there was a server cookie mis-match
rather than adding the answer along with a good server cookie for
queries received over UDP.  This is possible whereas setting TC=1
on all UDP responses isn't.

> be puzzled and it starts processing server messages. So, the attacker seems

The client only checks its client cookie.  It stores the new server
cookie if it got a good response.  Given the client knows from this
document that the server cookie may be different in every response
it will not be confused.

> miracle to know the IP of the client). 

See the logic above for how it helped the client.  It got a answer
rather than having the query dropped.

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 20 Jul 2015 04:20:09 -0400

Hi,

I think Mark has done a good job in responding, so I don't really have
much to add.

If you can conveniently do configuration at the client and server,
then you can get strong authentication with TSIG. If you can't, the
weak authentication provided by Cookies is about the best you can do.

See below

> of the which is being spoofed.

Even though it is not a good idea, I believe there are many small
recursive DNS servers behind a NAT that are queryable from the
Internet and findable through NS RRs. An attacker can try to poison
the cache at such a server and even if bandwidth to such a server is
limited there are many of them and they can be used in amplification
attacks. In any case, whether it is a common or a rare case, since you
can extend the weak protection to such cases fairly easily be
including the client cookie in the computation of the server cookie,
why not?

>> > > > The client doesn't check the server cookie returned.  It just stores it. The
>> > > only do some steps that is not necessarily help the client. (this conclusion is
>> > The server does the steps so that it can identify the client when it talks to the

The "attacker_secret" has only a 1 in 2**64 chance of being the same
as the server's secret so the server cookie will be wrong so the
server will not treat the request as authenticated. It is up to the
server what to do in this case which is pretty much the same case as a
request with no server cookie. Presumably the server will not send
back a big answer (to avoid amplification) and will not do a lot of
work (for example, will not send recursive queries or the like) to
avoid being saturated with processing fake queries.

That the attacker has to generate a fake client cookie to stick into
the 64-bit client cookie field is not very relevant since the client
cookie is opaque to the server and just gets reflected back in the
response, if the server chooses to send a response.

> only if that matches (1 in 2^64) does the fake query get treated

Right.

> cookie if it got a good response.  Given the client knows from this

Where good response includes having a correct client cookie.

>> > > it never request for any query. So, it silently discard all queries.

As per the Kaminsky attack, it is relatively easy to cause a recursive
resolver to issue queries for known DNS names so the response check in
your example is much weaker than you think, much weaker than DNS
Cookies.

>> to after the explanation of the mechanism?!

It seems to me that presenting the defenses before the attacks means
that while you are reading the defenses they are un-motivated. I think
the current organization is better for a general technical audience.
Problem then solution, as in the current draft, just seems most
logical to me.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: "Ralf Weber" <[email-masked]>
Date: Mon, 20 Jul 2015 13:19:27 +0200

Moin!

> only if that matches (1 in 2^64) does the fake query get treated
So does that mean that the server has to do the computation every
time it receives a query? Couldn't that be a vector for a DOS 
attack of an off path attacker, as the processing for this probably
is heavier than for normal rate limiting. 

> the document this is used in conjuction with other things like
Can you explain how this is better than normal RRL for an attack
on an authoritative server? If you give out an truncate answer
a legitimate client will retry over TCP, while other clients
just get the tiny fraction the attacker send making the attack
not worthwhile.

> A client with a good server cookie avoids being rate limited.
So that doesn't help or even makes these random attacks against
resolvers worse as the rate limit will be higher or?

> document that the server cookie may be different in every response
Hm my understanding of the draft was that a server cookie would be
valid for a day. Having a different cookie for every query doesn't
make sense for me. Can you please elaborate?

Maybe we should continue to look a but closer on how attackers can 
abuse this protocol before we continue.

So long
-Ralf

---

From: Mark Andrews <[email-masked]>
Date: Mon, 20 Jul 2015 22:01:06 +1000

In message <[email-masked]>, "Ralf Weber" write
> is heavier than for normal rate limiting.

Yes.  Potentially it depends on the algorithm used to create the
hash and what paths are executed on success / failure.  It also
depend on the interface speed / cpu speed etc.

> just get the tiny fraction the attacker send making the attack

Please go re-read what I have already sent out.

> resolvers worse as the rate limit will be higher or?

Unparseable.
 
> make sense for me. Can you please elaborate?

Validity time of a server cookie is independent of when a new cookie
is generated.  Named hands out a new server cookie on every response.
Each of those cookies is valid for a given time.

> Maybe we should continue to look a but closer on how attackers can abuse
> this protocol before we continue.
> 
> So long
> -Ralf

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Mon, 20 Jul 2015 16:55:51 +0200

> > This is not highlighted in the draft which makes it confusing for the
> > reader which causes to raise such question regarding NAT.
> 
attack.
> What is relevent is the impact the attack is happening and how a server
can
> sort some/all legitimate traffic from the client out of the which is being
> spoofed.

But this is confusing. Because the document somehow highlighted the fact
that the attacker has no possibility to sniff the communication between the
DNS server and client and then the document starts talking about attack and
assume that the attacker knows the IP address of the node that is behind
NAT. So this raises the questions. Even one sentence explaining that the
attacker knows this IP address from previous traffic between these nodes
would be helpful. 

> > Because I did not know how the attacker would target a single node
> > behind the NAT without knowing the IP address (please refer to my last
> sentence).
the
> same as far as the world is concerned.

But all the document highlighted NAT scenario. If it is applicable to other
scenarios, then it needs to be mentioned in the document. By reviewing the
document, I had this impression that this mechanism is only for the case
where a client is behind the NAT and all what this mechanism is do is to
somehow protect this client.
Which was the result of so many discussion over the NAT and client Ip
address that is not seen behind the NAT. 

> 
> The client keeps state: the client cookie it sent and the server cookie
> returned.
> 
> * If it is a recursive server this state is keep with things like the DNS
PMTU of
> the server or if it supports EDNS.

I skimmed RFC 6891 which is the base of this work. IMO what you say here
seems to be in contradiction with that RFC. See section 6-2 of that RFC.
Since cookies are a kind of OPT RR, "they MUST NOT be cached"

And now you're talking about combining this mechanism with DNS EDNS (which
is OPT RR) which help server to recognize the client?! Sorry  I am not
convinced with the mechanism in the draft. I have tried to explain my
reasons. I am convinced about having some client side only mechanism and not
as complicated as producing cookies but it can be anything to keep the state
of queries sent to the DNS server. But not convinced of server side
mechanisms to the extend it is explained in the draft. Just to summarize
what seems to add value and what seems not add necessarily any additional
value to the existing systems, I explain everything under two subtitle:
advantages and disadvantages:

Advantages:
- Good to have a client side mechanism which keep state of its own query and
discard anyone that it doesn't have any state about. So client_cookie to
some extend address this requirement but the problem could be address much
easier.
In other word,  this doesn't need necessarily that the client do any special
process to produce cookies. It can be simply by keeping even a sequence
number regarding the query it submitted to DNS server or a bit regarding to
the query. For example if it sends a query to DNS server and waiting for the
response, then the bit is set to false and if it received the response, the
bit is 1. In that case if it receives any DoS attacks (a large number of
queries), the client only checks the bit. When it doesn't expect any
response, without processing the large queries, discard them all.
And ok, for your case that is different and you go through the process of
producing cookie. That is also ok but needs more processing time than simply
assign a bit for each real query and only dependent on the client without
thinking whether or not the server support this approach.

Disadvantages:
- Not good to have server side part of this mechanism 
- If one look at the client cookie and server cookie, there are only some
numbers (ok ok.. they are produced by xx algorithm but actually they are
unrelated numbers.) in other word, the server might not produce the SAME
cookie for the same client because the "server_secret" is different
everytime. So, the server cannot identify the same client by only
calculating the cookie based on the client IP, client cookie and its own
secret.

This allows an attacker to still submits query to server with spoof source
IP address of the victim client. So, for server

[1] What needs the server to keep to make the proposal valuable is that the
server keeps the mapping of server_secret for each client. Therefore, 

Even with the solution [1], once the attacker submits a query to the server
with spoofed source IP address and has the possibility to eavesdrop the
query response (that he himself originated it with the spoof IP), then he
get to learn server_cookie for this specific client and include it to every
single request it submits to server. So at the end, maybe once it worked ,
with considering the fact to keep the mapping on the server (which is not in
the draft and the base of this draft is different)

- RRLs seems to already work to some extend for servers. So, I am not sure
what additional value it adds (my comment is only the server_cookie or
server side mechanism of this draft)

[2] server might want to use different server_secret even for the same
client to address the problem of [1]. But unfortunately, the server cannot
calculate the same server_cookie for the same client. therefore, this gives
an attacker a big chance to apply its attack as for the result of [4] [5] is
different for the server. So if the server uses RRL, then either the server
uses this mechanism or not, it doesn't help the server nor the client to
authenticate eachother. 

[4] Query 1: server_cookie =Pseudo_function (client_cookie + 192.168.1.1 +
789999) where server_secret = 789999   ---> server_cookie=a74t54545
[5] Query 2:    server_cookie =Pseudo_function (client_cookie + 192.168.1.1
+ 877766) where server_secret = 877766 ----> server_cookie = b9977005

So both [4] and [5] was for the same client but server result cookie is
different.  

[6] By considering all the above fact, the solution now is keeping the
mapping of client_cookie as well as server_secret in the server so that the
server can differentiate this client from other clients and also the
attacker.

[6] would work as long as the attacker doesn't get to learn the
client_cookie, if it learns it then it only copy it to each of its request
and for server it is similar to the client. So it is like the server doesn't
know how Alice is look like and alice supposed to receive an important
letter, the attacker can also go to server and say I am Alice. Server asks
for Alice's cookie, but attacker also copy Alice cookie and has it.
therefore, from the server, the attacker is identified as Alice and could
forge the identity of Alice. Alice used cookie but didn't help it. 

Last but not least, since in the draft server_secret is not kept in the
server and there is no client actual authentication as explained in [6],
then the server side mechanism does not help the client.

So, again back to the problem of such database that needs to keep this
mapping and search over each records for the server. This depends on also
the number of clients that query this server. So if you consider a public
DNS... ...

> * If it is a stub resolver it could be kept in a shared memory segment
that all of
> the stub resolvers instances can access or a well known file or there
could be
> a lightweight daemon than just remembers cookies.  In all cases
appropriate
> r/w locking needs to be done.  How it is kept is not important.
Alternatively
> the stub could establish its own cookie pair by sending a QCOUNT=0 query
> with only a client cookie then send the query it want the answer to.

I think there is misunderstanding. My concern is not why we keep the state
in client. my concern is that the server side part of this mechanism doesn't
work and not helpful.

> 
> It can attempt a amplification attack.  As I stated earlier and in the
document
> this is used in conjuction with other things like resource rate limiting.

I don't see any additional value that this draft can bring to the existing
mechanism by including the server side part of the mechanism.  Client only
is good and can work with RRLs and other mechanism.

> See the logic above for how it helped the client.  It got a answer rather
than
> having the query dropped.

With RRL as you discussed about, it can also receive an answer. If the
client doesn't try to send a lot of messages to server in a short period of
time. It is of course the bad luck of client if the same time as the
attacker starts attack, it also starts requesting any query from the DNS
server. In that case, it doesn't matter whether we have this mechanism,
based on the rate, the server, might also drop the client's request.

Best,
Hosnieh

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Mon, 20 Jul 2015 17:19:02 +0200

Hi Donald,

I think all the things you mentioned already addressed in other messages.
So, I would only go to the part that is not already answered

> 
> It seems to me that presenting the defenses before the attacks means that
> while you are reading the defenses they are un-motivated. I think the
current
> organization is better for a general technical audience.
> Problem then solution, as in the current draft, just seems most logical to
me.

When one doesn't know still the mechanism and suddenly you start with
attacks, it cannot judge to know whether the attack you're explaining is
really applicable. Therefore, the person need to go to mechanism section. Of
course, you can decide how to organize your draft. I am just saying that it
was how it happened. Maybe good to mention in one paragraph what attacks it
can prevent and move the detail about attacks after the explanation of the
mechanism. Because with the current organization, one need to go to
mechanism overview before reviewing attacks and only skim the attack to know
how it wants to do this step...

This was only a suggestion. Just do what you think it is relevant. 

Thanks,
Best,
Hosnieh

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 20 Jul 2015 12:36:08 -0400

Hi Ralf,

> is heavier than for normal rate limiting.

I do not think that is a significant problem if you use a lightweight
hash algorithm like FNV or even a strong cryptographic algorithm if
you have hardware support for the algorithm. It is up to the server
what algorithm to use and if you have an especially feeble server
(although why you would have a DNS server on such a device is not
clear to me), you could go for some really stupid hash function like
just XORing or adding 32-bit chunks or the like, which would still be
conformant.

While the protocol is designed so that no state needs to be maintained
at the server, I don't think that sort of approach isn't explicitly
prohibited. But I think it would be more work for the server to
remembers lots of server cookies it has sent than to do simple
calculation. Still, it is an implementation choice.

> just get the tiny fraction the attacker send making the attack

There is overhead in more messages and in state to do TCP and you get
less authentication, in my opinion, than you can get with 64-bit
cookies.

> resolvers worse as the rate limit will be higher or?

? Only legitimate clients that should not be rate limited will have a
good server cookie they can use. I don't understand what you are
saying about random attacks?

> make sense for me. Can you please elaborate?

See Mark's answer.

The only mandatory secret rollover provision in the draft is that the
local secret MUST be changed once a month (plus a few days to allow
for weekends / holidays, etc.). If you have a fancier server cookie
format like that shown in Appendix B.2, the server cookie includes an
authenticated time stamp so the server could choose any time bound
shorter than the server secret rollover time and could even
dynamically adjust that time bound if it wanted to. Or a server can
just rollover its secret more often if it wants.

Thanks,
Donald

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Mon, 20 Jul 2015 20:32:48 +0200

> From: DNSOP [mailto:[email-masked]] On Behalf Of Donald Eastlake
> 
> Hi Ralf,
> 
> While the protocol is designed so that no state needs to be maintained at
the
> server, I don't think that sort of approach isn't explicitly prohibited.
But I think
> it would be more work for the server to remembers lots of server cookies
it
> has sent than to do simple calculation. Still, it is an implementation
choice.

I would refer you back to my example in my last message... "no state' is a
big word. I would be careful to use this word with such mechanism

Best,
Hosnieh

---

From: Mark Andrews <[email-masked]>
Date: Tue, 21 Jul 2015 08:06:00 +1000

In message <[email-masked]>, "Hosnieh Rafiee" writ
> attacker knows this IP address from previous traffic between these nodes

To attack _you_ I would attack 188.174.236.194 based on the received
headers in the email I am relying to.  You most probably have a
NAT.  With a little more investigation I could probably get the
recursive servers you are using.  Nowhere I seen a packet from
you but I know where to direct the attack.

There are 1000's of potential ways to find out the address to attack.

> address that is not seen behind the NAT. 

No the document demonstrated it worked equallt well with client
behind a nat the same as it works with clients not behind a nat.

> Since cookies are a kind of OPT RR, "they MUST NOT be cached"

It doesn't cache the OPT record.  Cookies are a EDNS option.  They are not
the opt record.
 
> calculating the cookie based on the client IP, client cookie and its own

You are just wrong.

Given a client cookie of 5601890afd80709 and a client IP address of 1.1.1.1
and a secret of da39a3ee5e6b

[rock:~/git/bind9] marka% openssl sha1
5601890afd80709+1.1.1.1+da39a3ee5e6b
(stdin)= b293dad995a863793565d5ed88de830269fa4218
[rock:~/git/bind9] marka% 

now the server sends back 5601890afd80709b293dad995a863793565d5ed88de830269fa4218

the next time the client talks to the server it sends 5601890afd80709b293dad995a863793565d5ed88de830269fa4218

>From which the server extracts 5601890afd80709 and add the IP address which it
combines with the secret to compute b293dad995a863793565d5ed88de830269fa4218.

Now unless the attacker gets both 5601890afd80709 and the matching IP address right the resulting server hash wont be b293dad995a863793565d5ed88de830269fa4218

No.
 
> the draft and the base of this draft is different)

If the attacker can see the reply traffic all bets are off.  This
is not designed to protect in that senario.  The document says it
doesn't work in that senario so I fail to see why you are raising
it.  On path attackers are a completely different kettle of fish.

> So both [4] and [5] was for the same client but server result cookie is

multiple secrets are supported you send back a index to the secret
+ the computed value in the cookie field

server_cookie=01a74t54545
server_cookie=02b9977005

The server know that 01 and 02 are index values to server secrets.
 
> in client. my concern is that the server side part of this mechanism doesn't

It does work.  These are basic cryptographic techniques that are
known to work.  Go work though some actual examples exactly as they
are described.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 21 Jul 2015 15:19:28 +1000

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

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 22 Jul 2015 13:42:23 -0400

Hi Hosnieh,

On Mon, Jul 20, 2015 at 10:55 AM, Hosnieh Rafiee <[email-masked]> wrote:
>> Because it is irrelevent has to how the attacker chooses the address to attack.
>> What is relevent is the impact the attack is happening and how a server can

Right. It is assumed that the attacker cannot snoop on DNS messages.
If they can snoop on DNS messages then they can forge replies to
clients based on copying the client cookie from a legitimate reply to
that client, possibly poisoning the client's cache, etc. And they can
similarly forge requests to a server for a client if they happen to
see a legitimate request from that client to that server. If the
attacker sniffs a message behind the NAT, then it will have to inject
its forged message behind the NAT, and if it is going to inject a
message outside the NAT, it needs to sniff the message outside the
NAT.

> NAT. So this raises the questions. Even one sentence explaining that the

I don't know the exact scenario you are thinking about but the
attacker would not normally know the behind-the-NAT addresses of a DNS
client/server that is behind a NAT unless the attacker is also behind
the same NAT. If, for example, you have multiple clients behind a NAT
using a server that is on the Internet elsewhere outside the NAT, you
want some way to stop one of these clients from forging request as if
they were from a different client behind the same NAT. The attacker
might have learned that the other clients behind-NAT IP address by
just doing an IP address scan inside this network behind the NAT, or
something like that.

> attacker knows this IP address from previous traffic between these nodes

I'm OK with adding something about ways that an attacker behind the
NAT might learn the specific IP address of what they want to attack
that is behind that NAT and ways that an attacker outside of the NAT
might learn an external IP address of the NAT to attack.

>> Whether it is the client or the NAT it doesn't matter.  They are one and the

No. There is not a single mention of NAT anywhere in Section 2 (the
problem), Section 3 (existing DNS security), Section 4 (the DNS cookie
option), or Section 5 (the DNS coookie protocol). There is nothing
technical about NAT until you get to Section 6, which is only two
pages long. You are highlighting NAT. The document does not highlight
NAT. Your statement that "all the document highlighted NAT scenario"
is incorrect.

> somehow protect this client.

As above, I have no idea how you came up with the incorrect impression
"that this mechanism is only for the case where a client is behind the
NAT". The mechanism is motivated by and fixes the problems described
in Section 2 that never mentions NAT. The mechanism does have a tweak
so that it works better to protect DNS devices behind a NAT from
attackers behind the same NAT.

> Since cookies are a kind of OPT RR, "they MUST NOT be cached"

No. Cookies are not an OPT RR. They are one or two fields inside a new
OPT option which in turn is inside an OPT RR. And in any case, what
you quote from RFC 6871 is talking about caching things in the RR
cache, where they might be accidentally retrieved and included in some
answer when they should not.

It is a general characteristic of all meta-RRs, including the OPT RR,
TSIG RR, and TKEY RR, that they should not be cached as RRs. For
example, if you negotiate keys by exchanging TKEY RRs, you should not
cache the TKEY RRs; but you would certainly want to remember ("cache")
the negotiated key(s). Just so, you should not cache an OPT RR,
regardless of whether it has a COOKIE option in it or not, but you
certainly do want to remember ("cache") the client/server cookies you
receive inside a COOKIE option inside an OPT RR when appropriate.

> is OPT RR) which help server to recognize the client?! Sorry  I am not

I would not say "recognize". What DNS cookies do is let the server
weakly authenticate that the client is actually at the source IP
address in a request (and in the case of a client behind a NAT it
might also weakly authenticate which client is being mapped to the
source IP address, depending on what the NAT is doing).

> of queries sent to the DNS server. But not convinced of server side

Clients already remember everything they can about requests
(particularly queries) to try to recognize legitimate responses and
this has proven to be inadequate.

> queries), the client only checks the bit. When it doesn't expect any

So, you think current DNS clients just accept any response they
receive anytime? And that just adding a single bit of state per server
to say that the client has an outstanding request so that the client
would accept a response and clear the bit if the bit was set and would
drop a response if the bit wasn't set would solve cache poisoning??

Clients are much more paranoid than that today. For queries, they
typically remember a lot of information including the query section
and sequence number and discard responses that don't match that but
this has proven to be inadequate. Which is why most people feel you
need cookies or TCP for added protection.

> calculating the cookie based on the client IP, client cookie and its own

No, the server secret does not change every time. And if the server
uses the style of server cookie described in Appendix B.1, the server
cookie for a particular client does not change every time. If the
server uses a more complex server cookie with a time stamp in it that
is included in the hash, like the example in Appendix B.2, then the
server cookie will probably change every time but the server
understands its own cookies and knows that part of it is a time stamp
and knows how to authenticate it even though it might be different
every time. The simpler style of server cookie (B.1) is based on the
client IP, client cookie, and server secret you list. The more complex
style of server cookie (B.2) also includes the time in the hash.

> IP address of the victim client. So, for server

No. As long as the server can verify the server cookies that it
produces and the attacker cannot sniff the messages, the server is
weakly protected as stated in the draft.

> server keeps the mapping of server_secret for each client. Therefore,

As I say, the server needs to be able to verify its server cookies.
But as long as it can recalculate them, it does not need to keep them.
It only needs to keep its server secret.

> get to learn server_cookie for this specific client and include it to every

We assume that the attacker cannot eavesdrop so what an attacker can
do if they can observer the DNS messages is irrelevant.

> the draft and the base of this draft is different)

I think Mark Andrews has answered most of your errors below so I will stop here.

Thanks,
Donald

>> * If it is a stub resolver it could be kept in a shared memory segment that all of
>> the stub resolvers instances can access or a well known file or there could be
>> a lightweight daemon than just remembers cookies.  In all cases appropriate
>> r/w locking needs to be done.  How it is kept is not important. Alternatively
>> It can attempt a amplification attack.  As I stated earlier and in the document
>> See the logic above for how it helped the client.  It got a answer rather than

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Wed, 29 Jul 2015 21:45:07 +0200

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

> Sent: Tuesday, July 21, 2015 7:19 AM
> Cc: [email-masked]; Hosnieh Rafiee
> Subject: Re: [DNSOP] Review of draft: draft-ietf-dnsop-cookies
> 
> 
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:
> ;; ->>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:
> ;; 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:
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:
> ; <<>> 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:
> 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.
> 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:
> ; COOKIE: 9310320f2fa1e6e9694856ae55add44dfa9fce2ea17b916a (good) ;;
> QUESTION SECTION:
> ;isc.org.			IN	A
> 
> ;; Query time: 0 msec
> ; <<>> 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:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45311 ;; flags: rd ad;
> QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45311 ;; flags: qr rd
ra
> ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Mark Andrews <[email-masked]>
Date: Thu, 30 Jul 2015 06:34:46 +1000

> 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