Subject: scope

From: Rob Austein <[email-masked]>
Date: Fri, 08 Aug 2003 15:36:56 -0400

Messieurs Ohta and Vixie got me thinking about scoping and fault
isolation in the approaches we've been discussing.  No, this is not
about IPv6 site-local and I will thank y'all not to bring that up :).

Ohta-san is correct that every single one of the approaches we've
discussed has some kind of scoping constraint which, ultimately, is
decided by some human action or inaction.  Router configuration of
routes to well-known addresses, router configuration of RA, router
configuration of multicast, DHCP relay configuration, doesn't matter.
All of these mechanisms have some kind of scoping control with a
default that may need to be changed by a human.

One place where these approaches differ in interesting ways, however,
is in the default behavior.  This is particularly interesting when
trying to understand the failure modes of each of these approaches
if they're implemented or administered badly.

- RA/ND-based: if RA/ND isn't configured, discovery doesn't happen.

- Multicast-query based (DHCP, DHCP-lite, LLMNR-like, whatever): if
  router multicast (or DHCP relay) isn't configured, may work anyway
  on the local link, but otherwise discovery doesn't happen.

- Well-known address based: discovery propagates upstream following
  the default route until it finds something or hits the edge of the
  default free routing zone.  Discovery does not work if neither
  well-known address nor default route is configured.

Assuming that one buys this analysis, this says that the well-known
address approach is significantly different, in ways that are both
good and bad.  Good, because it means that dumb edge networks may just
inherit the necessary data from the larger networks to which they're
attached (although one might have security issues, eg, trust
boundaries for use of the AD bit).  Bad, because this has the
potential to turn into a bug amplifier.  Think, for example, about a
hypothetical firewall product that blocks inbound recursive responses:
this doesn't hurt the outside world so long as the well-known address
points to something inside the firewall, but what happens if the
well-known address route gets hosed?  Oops.

One hopes that no ISP would ever be silly enough to advertise or
accept routes for these well-known addresess in the default free zone.

Bottom line is that thinking about fault isolation gives me another
reason for discomfort with the well-known address approach.  YMMV.
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 8 Aug 2003 21:07:29 -0000

Rob Austein writes:
> Think, for example, about a hypothetical firewall product that blocks
> inbound recursive responses: this doesn't hurt the outside world so
> long as the well-known address points to something inside the firewall,
> but what happens if the well-known address route gets hosed?  Oops.

The administrator who sets up that firewall, but neglects to set up DNS
service inside it, will find that his clients can't browse the web. This
is exactly the behavior I'd expect.

Why do you say ``Oops''? What's the big deal?

Do you also worry when people set up DNS caches that are firewalled away
from the root servers? Do you realize that the DNS root server addresses
are ``well-known addresses''?

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: "Eric A. Hall" <[email-masked]>
Date: Fri, 08 Aug 2003 17:01:19 -0500

> discussed has some kind of scoping constraint which, ultimately, is

This is what I was trying to point out as well.

>   well-known address nor default route is configured.

That's pretty mcuh right, except for a clarification to the well-known
address problem, which is that in the default (unmanaged) scenario,
locally-generated queries will follow the default routes, and will get
passed to whoever actually owns the address space in question.

There are actually two impositions here: First is that the use of an
address-based mechanism needs to have non-delegated, non-used address
space explicitly reserved for it by ICANN or whoever. Organizations don't
necessarily have to use that address space, but something needs to be
reserved for use in the default model, and it must not be part of RFC1918
space or any actual space. Second is that the use of locally-preferred
addresses actually cranks up the administrative costs greatly, since
admins not only have to configure the routing service to accomodate the
local addresses, but also needs to configure the nodes to use that address
space. None of the other requirements have any need for the admins to
manage the leaf-nodes whatsoever, and this is not a trivial artifact.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: Rob Austein <[email-masked]>
Date: Fri, 08 Aug 2003 18:18:05 -0400

> is exactly the behavior I'd expect.

Yes, if they screw this up for all of the well-known addresses.   What
if they only screw up one of them?

> are ``well-known addresses''?

In reverse order, yes, I do realize that the root server addresses are
well-known, and that's part of what worries me.  Studies of traffic
observed at those servers suggest that a significant fraction of the
total root server query load is the result of bad packet filtering
that lets queries get out but blocks some or all responses.

Discovery based on well-known addresses is a bit different because the
packets (probably) stop at the edge of the default free zone, but the
potential for bug amplification is similar.
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: "Matt Larson" <[email-masked]>
Date: Fri, 8 Aug 2003 20:39:12 -0400

> that lets queries get out but blocks some or all responses.

You can say that again.  IWFs (Idiots With Firewalls) account for a
tremendous volume of repeat queries to the roots.  It's more common than you
might think.  Those same boxes are probably the ones that inform their
administrators that the blocked responses are in fact attacks, many of which
get dutifully reported.

Matt

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 9 Aug 2003 09:38:27 +0859 ()

Rob Austin;

> is in the default behavior.

> address approach is significantly different,

Other hop-by-hop-relaying (multicast does not qualify) approaches
may also be modified to let routers, by default, relay information
from all interfaces to all the other interfaces, if they are
protected from loops and have some preference metric to
multiple sources of the information.

But, the simplest way is to just rely on routing protocols.

> Good, because it means that dumb edge networks may just
> boundaries for use of the AD bit).

Considering that the requirement is, perhaps, maybe, hopefully, to
reduce configuration effort of host and site adminisgtrators
as much as possible, it is good.

> Bad, because this has the

> reason for discomfort with the well-known address approach.  YMMV.

You are merely claiming that implementations of relaying entities
may be buggy, applicable to all the approaches (including multicast
one, this time).

In addition, it should also be claimed that manual configuration of
relaying entities may be wrong that the number of configured
entities should be small.

							Masataka Ohta

---

From: Pekka Savola <[email-masked]>
Date: Sat, 9 Aug 2003 20:47:12 +0300 (EEST)

On Fri, 8 Aug 2003, Rob Austein wrote:
[...]
> potential for bug amplification is similar.

Note that couldn't a similar argument be applied to 6to4 relays using the
anycast address?  That all the parties should provide some support for it?  
Of course, the service is of a more fundamental type, but still..

We might be much better off if we recommended that such anycast addresses
should not be propagated at peering links (for example).  That way, the
fallback would be quicker (to using no DNS servers at all, most probably).  
Instead of going around the world like 6to4, this could be an incentive
for the ISP's to deploy such a service.  However, the time it might take
to ensure global availability of such a service could also be rather long.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: "D. J. Bernstein" <[email-masked]>
Date: 10 Aug 2003 06:04:56 -0000

Rob Austein writes:
> a significant fraction of the total root server query load
> is the result of bad packet filtering

Think about the numbers for a moment.

The screwups you're talking about, added up over the _entire Internet_,
are on the scale of thousands of packets per second. Split the same
screwup level across all of the Internet's ISPs and the load becomes
unnoticeable.

Furthermore, even the most extreme DNS loads are miniscule compared to
HTTP load. Root-server load is special, because it has a serious (and
unnecessary) centralization problem; ISP-cache load isn't, and doesn't.
Do you think ISPs say to themselves ``Wow, our expenses are totally out
of control; it must be because of all those customers dropping responses
from our DNS caches''?

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 10 Aug 2003 20:57:26 +0859 ()

djb;

> Think about the numbers for a moment.

Before that, I think we should think about a DHCP configured name
server located beyond a firewall, which is no different from
an anycast name server located beyond a firewall.

> screwup level across all of the Internet's ISPs and the load becomes

And, that's why anycast is the way to go both for root servers
and autoconfigured recursive servers.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 10 Aug 2003 20:59:32 +0859 ()

Eric A. Hall;

> locally-generated queries will follow the default routes,

That is an inappropriate assumption.

For scalable multihoming, there should be no default routes even
within sites.

							Masataka Ohta