> On 2008-08-31 23:26, Mark Andrews wrote:
> > Jefferson Ogata wrote [attribution restored]:
> >> The
> >> attack could be partly mitigated on nameservers that allow ~2^16
> >> outstanding requests if the victim nameserver can reuse randomly chosen,
> >> already open sockets for multiple successive requests once ~2^16 ports
> >> are bound.
> >>

> > You still need to randomly select ports and randomly select
> > txid. When you have a collision you just need to repick
> > one and/or the other. A port collision alone lets you use
> > a existing socket.

>
> I believe I considered that possibility in the above part of my comment.
> The question in that case remains: does any existing resolver that
> supports source port randomization actually do this?
>
> > For queries to another server you just set SO_REUSEADDR
> > when you have a port collision with a port you already have
> > open as the existing one is in a connected state. If it
> > is a port that is not already in use you don't set SO_REUSEADDR
> > so you detect collisions with other applications.

>
> I don't see why you need SO_REUSEADDR. Why not simply leave the UDP port
> unconnected and use sendto in the first place?


Because you really want to have the kernel do the initial
filtering of responses. You don't want your recursive
server seeing every stray UDP packet being sent to you.
With the amount of malware out there that is trying to get
in over UDP your recursive server will be getting lots of
noise if you randomly choose such a port. Connected sockets
don't interfere with other uses of UDP (e.g. traceroute).
You can't probe to see what ports are in use by the recursive
server without making the server actually make queries to
you.

Mark

> --
> Jefferson Ogata : Internetworker, Antibozo
>
> --
> to unsubscribe send a message to namedroppers-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive:

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: