Subject: Re: randomid(3)
To: Daniel Carosone <dan@geek.com.au>
From: Bill Studenmund <wrstuden@netbsd.org>
List: tech-userlevel
Date: 09/10/2003 20:30:55
On Wed, 10 Sep 2003, Daniel Carosone wrote:

> On Wed, Sep 10, 2003 at 08:53:40PM +0900, itojun@iijlab.net wrote:
> > 	i would suggest you to see what dnsspoof(8) in dsniff package is
> > 	capable of.  the attacks are real, and unpredictable ID is an important
> > 	protection.  the real world is much scarier place than you think.
>
> an important protection in the real world where you can't rely on
> someone else's server infrastructure supporting stronger protections
> (like TSIG), unfortunately.

Uhm, how?

The only threat I can see that randomizing the ID will close is
specifically where: 1) you know the next request(*), and 2) you have to
send the response before you've received the request to get your response
there before the real DNS server's response. You still have to get your
response there after the request was sent of course.

So how common is that threat? i.e. how common is a spoofing attack that
specifically can't wait until the request has been seen? Because once the
request has been seen, you can always just use the correct ID, no?

(*) I am assuming that if you send request # X for DNS name Y and actually
get an answer for Z, that you will drop that response as invalid.
Otherwise there's a much bigger error out there.

Also, if you are going to do this, please make it something that either
can be turned off, or has to be turned on. I'm thinking about the
performance impact this may have on our slower machines, especially if an
admin has done something else to close dns spoof vulnerabilities.

Take care,

Bill