Subject: Re: DoS and anycast

From: Masataka Ohta <[email-masked]>
Date: Wed, 30 Oct 2002 22:54:52 +0859 ()

Ted Hardie;

> > > 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.

Huh?

Around?

Where is the cost introduced by anycast?

REMEMBER, you said:

	but at the cost of risking the integrity of the data provided
	by the service.

Where is the cost of risking by deploying anycast, when we already
incurs the cost with unicast?

> 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?

Let's admit the fact that everyone in the world is
allowed to grab a copy of a part of the root zone from 13 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 part of the zone to those listening to the route?

With anycast root servers, people are free to use public key cryptography
to download the root zone content with https from some canonical places
provided by ICANN, IANA, ALTERNIC, Verisign or whatever, though it merely
moves the risk around to root CAs, such as Verisign.

							Masataka Ohta
#----------------------------------------------------------------------
# To unsubscripbe, send a message to <[email-masked]>.

---

From: Bruce Campbell <[email-masked]>
Date: Wed, 30 Oct 2002 19:21:57 +0100 (CET)

> allowed to grab a copy of a part of the root zone from 13 canonical place.

Yes.

> the part of the zone to those listening to the route?

Assuming that Operators aren't applying route prefix filters to their
(BGP) peering links, absolutely nothing.

The hypothetical attacker _will_ be able to introduce an apparent shorter
path to one, or more, of the roots, with the expected result that traffic
from people who use that new path as 'best' will send traffic to that
particular root.

Unfortunately, although various people have been trying to convince
Operators to apply such basic protections to their BGP peering/transit/etc
links for several years, it will take a few demonstrations of the
effectiveness of this type of attack before Operators will 'Do the Right
Thing' and apply filters on their BGP sessions to prevent this type of
attack.

> moves the risk around to root CAs, such as Verisign.

This secures the backchannel.  This does not stop the individual anycast
roots from being the subject of DoS attacks.  Given that we do not see a
definitive way to stop _all_ DoS attacks[1], we should focus on making
sure that the data retrieved is authoritative.  Hence, we're back to the
previous thread on this list, being a proposal to sign the root zone.

-- 
                             Bruce Campbell                            RIPE
                   Systems/Network Engineer                             NCC
                 www.ripe.net - PGP562C8B1B             Operations/Security

[1] Misconfigurations in widely-deployed client resolvers can be more
    detrimental to the root servers over time than intentional attacks, eg
    querying for the 'A' record of an IP address.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 31 Oct 2002 16:15:07 +0859 ()

Bruce;

> sure that the data retrieved is authoritative.

Hugh?

Protection against DoS attacks and proteciton against forgery are
conceptually orthogonal.

Note that an ISP may run anycast root servers on all the 13 root
server addresses that DoS on some does not redirect query to a
root server operated by someone else.

> Hence, we're back to the

Even if you believe in public key cryptography, what's wrong with
https?

							Masataka Ohta

---

From: Bruce Campbell <[email-masked]>
Date: Thu, 31 Oct 2002 17:18:12 +0100 (CET)

> Protection against DoS attacks and proteciton against forgery are

For one class of DoS attack, yes.  For DoS attacks which are purely
focused on the Denial aspect, the (anycast) victim root can have every
protection against forgery that you can name, and it still would have its
service unavailable to legitimate clients.

Hence anycast is a good idea, in that there are more targets, thus the
possibility of _all_ roots being taken out diminishes.

> root server operated by someone else.

Certainly, and theres nothing technical from stopping ISPs from doing that
today.

> Even if you believe in public key cryptography, what's wrong with

You mentioned using https for (anycast) roots to _retrieve_ the root zone
from an authoritative source.  Wonderful, it'd definitely be a workable
solution for this backchannel, hence theres nothing wrong with https in
that context.

However, signing the root zone helps the clients, who, due to the design
of DNS, do not have the option of using https to query the roots.

-- 
                           Bruce Campbell                  RIPE NCC

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 1 Nov 2002 10:30:13 +0859 ()

Bruce;

> Certainly, and theres nothing technical from stopping ISPs from doing that

And, we should recommend so.

> solution for this backchannel, hence theres nothing wrong with https in

Isn't it what you requested for?

> of DNS, do not have the option of using https to query the roots.

Anycast servers protects the clients from external forged routes
that there is no need for insisting on signing.

						Masataka Ohta