Re: Outstanding queries vs. source port randomization entropy
> > On 2008-08-31 23:26, Mark Andrews wrote:[color=darkred]
> > > 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,[/color][/color]
> > >> 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.[/color]
> > 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.[/color]
> > I don't see why you need SO_REUSEADDR. Why not simply leave the UDP port
> > unconnected and use sendto in the first place?[/color]
> 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
Additionally with sendto() you will tend to get locked onto
a open set of ports as you need to wait for the next response
whenever you re-use a port. With connect() each transaction
becomes almost completely independent of other transaction.
Note all the probability analysis being done assume
independent transactions. If you have depenancies between
transactions (i.e. re-use of a socket) then all the analyses
needs to be redone to factor in that socket re-use.
Even without doing such a analysis I can tell you that
re-use makes the system weaker not stronger.
> > --
> > Jefferson Ogata : Internetworker, Antibozo
> > --
> > to unsubscribe send a message to [email]email@example.com[/email] with
> > the word 'unsubscribe' in a single line as the message text body.
> > archive: <http://ops.ietf.org/lists/namedroppers/>[/color]
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: [email]Mark_Andrews@isc.org[/email][/color]
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [email]Mark_Andrews@isc.org[/email]
to unsubscribe send a message to [email]firstname.lastname@example.org[/email] with
the word 'unsubscribe' in a single line as the message text body.