[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: mohta@necom830.hpcl.titech.ac.jp (Masataka Ohta)
Cc: Ted.Hardie@nominum.com, dnsop@cafax.se
From: Ted Hardie <Ted.Hardie@nominum.com>
Date: Tue, 29 Oct 2002 23:00:35 -0800 (PST)
In-Reply-To: <200210300057.JAA22695@necom830.hpcl.titech.ac.jp> from "Masataka Ohta" at Oct 30, 2002 09:57:21 AM
Reply-to: Ted.Hardie@nominum.com
Sender: owner-dnsop@cafax.se
Subject: Re: DoS and anycast

> > Deploying anycast services (outside the RFC-1930 compliant methods
> > currently in use) lessens the effect of a DoS attack, but at the cost
> > of risking the integrity of the data provided by the service.
> 
> As I pointed it out several times already, anycast root servers
> is the protection from forged route that the risk of getting
> forged data is reduced.

It moves the risk around.  Let's assume that everyone in the world is
allowed to grab a copy of the root zone from one canonical place.
What is to prevent someone injecting a false route to a server
pretending to be the canonical server, thus provisioning a bad copy of
the zone to those listening to the route?

If the scale is "everyone in the world can grab a copy", the answer is
the same protection which currently prevents false routes to the root
servers now: not much.  Basically, ISP clue prevents it (or at least
lessens the impact by correctly diagnosing if/when it happens).  This
isn't enough, as that clue is not always present.  

You *can* get other checks to ameliorate the risks at radically
smaller scales.  But who gets to decide who gets to play, and how do
we set up the initial trust relationships?  And why spend that effort
when the same effort spent on other choices gets us so much more?


> 
> What is the current protection against the forged data?

As above: not much, and not enough.  This is an argument for providing
good data integrity mechanisms, independent of what the distribution
mechanism might be(unicast, anycast, sneakercast).

				regards,
					Ted Hardie





#----------------------------------------------------------------------
# To unsubscribe, send a message to <dnsop-request@cafax.se>.

Home | Date list | Subject list