Hi Hosnieh,
On Mon, Jul 20, 2015 at 10:55 AM, Hosnieh Rafiee <i...@rozanak.com> wrote:
>> > This is not highlighted in the draft which makes it confusing for the
>> > reader 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.
>
> 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
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.
> 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
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
> would be helpful.
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.
>> > > > > Having middle boxes modify packets is a *bad* *idea*.
>> > > >
>> > > > Might be, but this is also not applicable.
>> > >
>> > > 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.
>>
>> 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.
>
> But all the document highlighted NAT scenario. If it is applicable to other
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.
> 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.
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.
> 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"
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.
> 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
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).
> 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
Clients already remember everything they can about requests
(particularly queries) to try to recognize legitimate responses and
this has proven to be inadequate.
> 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
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.
> 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.
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.
> This allows an attacker to still submits query to server with spoof source
> 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.
> [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,
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.
> 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
We assume that the attacker cannot eavesdrop so what an attacker can
do if they can observer the DNS messages is irrelevant.
> 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)
I think Mark Andrews has answered most of your errors below so I will stop here.
Thanks,
Donald
=============================
Donald E. Eastlake 3rd +1-508-333-2270 (cell)
155 Beaver Street, Milford, MA 01757 USA
d3e...@gmail.com
> - 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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
