Re: correction! Re: The math of RFC3822.2.2-spoofing a randomising source port resolver

[Paul Vixie <vixie@isc.org>]

> From: Stefan Schmidt <zaphodb@zaphods.net>
> 
> On Mon, Aug 04, 2008 at 02:22:41PM +0000, Paul Vixie wrote:
> > indeed, noone on earth knew that this could be done in 11 seconds until
> > february 2008.  given the severe trauma caused by udp port randomization
> > for firewalls and NATs and solaris-10 and so on, i think there was a real
> > and correct cost-benefit tradeoff being made when this attack took days
> > or weeks of sustained multimegabit traffic to pull off.
> 
> Tradeoff yes, trauma not really for that is something that requires a shock.
> You knew that this patch needed some ironing out and that the best way of
> achieving that is to just roll it out, no need to be shocked about that now.

let's be clear about this.  neither dnscache nor powerdns was creating as many
simultaneous upstream flows in those years as the kaminsky defense requires,
and the market size for these tools was in those years so small that many of
the firewall / NAT / kernel instabilities BIND is running into as we deploy 
UDP port randomization were simply not encountered until now.

smaller and less popular implementations need have no fear of damaging their
reputations by being seen "legislating from the bench".  in BIND's case we are
not able to adopt simplistic attitudes like "requires a shock" lest our user
community storm our front yard with torches and pitchforks in hand.

that's why the nuanced view of this is as a "real and correct cost-benefit
tradeoff".  now that kaminsky changed the costs and benefits, ISC has adapted.

> When i switched our recursive DNS from BIND9 to PowerDNS recursor in 2006
> i was surprised that the recursor didn't use up more system resources
> than BIND9 even so it did randomize the query port. Apparently this can
> be done right and from what i hear this also works pretty well on Solaris
> installations.

see above.

> For years before my switch i wondered why ISC did not simply use Linux'
> epoll or FreeBSD's kqueue where available, how about you?

because it didn't make any performance difference for the number of
descriptors we had open simultaneously, this was another cost-benefit
tradeoff.  there was insufficient need to justify the complexity.  post
kaminsky, there is sufficient need to justify the complexity.

> "cron loves you too, that's why it sends you so much mail."
> - Paul Vixie, author of Vixie Cron

:-).

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--
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: <http://ops.ietf.org/lists/namedroppers/>