Moin!

On 5 Aug 2015, at 12:50, Mark Andrews wrote:

In message <44d34c00-2ada-443e-9387-ef79171b4...@fl1ger.de>, "Ralf Weber" writes:
- provide a deterministic function that takes the client IP and a
secret to generate the cookie. That way you can generate the same
cookie on every request.

Read the draft.  It does not say that.  It is IP address + client
cookie + secret (min 64 bits) + whatever else the server adds to
the mix (for named that is time + a 32 bit nonce).   It's also why
the secret needs to be updated periodically for the plain 64 bit
secret.

Thats 32 + 64 + 64 bits of input minimum.  For named it has at least
64 bits of input and possibly 96 more bits on top of that.
It still is a function which outputs, if I read the draft correct, a
static cookie for at least a day. If during that day an off path
attacker can get a hold of the cookie he can use that cookie and the
spoofed address to overload the server.

If NAT leaves the DNS packet untouched. I'm not sure they do this
and most home gateways or firewalls have a DNS proxy anyway.

If you are talking to the CPE as a nameserver.
That still is the most commonly used use case AFAIK.

If you are talking to remote nameservers (e.g. 8.8.8.8) through the
NAT you normally just have port manipulation.
That is true for most home gateways. I'm not sure if this is true
for corporate firewalls, it certainly wasn't for me in my past jobs.

Also I don't want to get back to source and destination port being
53 it was quite a journey get various parties convinced that multiple
ports above `1024 are ok as source ports for DNS.

So you leap from random ports to fixed port 53.
OMG lets hope that this doesn't happen. This would mean that all the
crap that still is out there that still has it has no reason to be
changed...

When I did a test a couple of months ago port 53 still was the most
prominent client port being used for about 1% of the queries.

Even when the client does DNSSEC validation this is useful as the
referral is not signed.
Sure, but we would catch that with checking the DS against the keys.

Much better to not to have to detect and recover from being garbage
nameservers and addresses in the first place.
Then why didn't we do that in the first place. IMHO all the additional
"security" parameters you want to put into cookies make it more valuable
to get a hold of a cookie and use it to do bad stuff.

So long
-Ralf

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to