Subject: Re: Comments on draft-ietf-ipv6-unique-local-addr-00.txt

From: Andrew White <[email-masked]>
Date: Tue, 02 Sep 2003 11:25:50 +1000

Dan Lanciani wrote:

> There is a huge difference between requiring a /48 and allowing anything
> greater than /8.  The former ...
> while the latter means that you can bypass the black hole with 2 or 4
> route additions.

Of course you can bypass it.  But remember that your bypass is only useful
if all intermediate routers have ALSO agreed to the bypass, and that the BGP
routers by default ignore updates to local prefixes.

So yes, it's trival to modify your system so that the next router in the
chain discards the packet instead.  More usefully, you can redirect
particular known routes to VPNs or other directly connected networks and
still have the gateway router drop other (unknown) local packets.

BTW - would it be better for the router to send 'reject' packets rather than
just blackhole?  This should allow applications sending 'bad' local packets
to timeout more quickly?

-- 
Andrew White
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Dan Lanciani <[email-masked]>
Date: Tue, 2 Sep 2003 00:42:35 -0400 (EDT)

Andrew White <[email-masked]> wrote:

|Dan Lanciani wrote:
|> 
|> Andrew White <[email-masked]> wrote:
|> 
|> |Dan Lanciani wrote:
|> |
|> |> There is a huge difference between requiring a /48 and allowing anything
|> |> greater than /8.  The former ...
|> |> while the latter means that you can bypass the black hole with 2 or 4
|> |> route additions.
|> |
|> |Of course you can bypass it.
|> 
|> The proposed wording is:
|> 
|> ``Router manufacturers MUST ensure that said black hole cannot be
|> deconfigured, turned off, or otherwise overridden in toto;''
|> 
|> How do you reconcile this with ``Of course you can bypass it.''?
|
|The immediately preceding context was Alan stating that his reading was that
|only /8 routes are to be discarded and that anything more specific would be
|forwarded.

This was the culmination of a thread with more context.  In any case, I
can't see how the text can be read to mean that.  It clearly states that
the black hole cannot be overridden in toto.

So how about we stop dancing around and answer the question:

Can I completely disable the black hole on my own router or not?

N.B., an answer of the form, ``you can disable it in ways that support what
we consider to be appropriate uses of local addresses'' is not an answer.

|You seemed to be saying that having an easy workaround
|invalidated the value of the filter, which Alan and Christian (and I) seem
|to disagree with.

No, I said that having an easy (or any) workaround is contrary to the proposed
wording.  As an aside, I don't think this is a very productive way to come
up with a spec.  We are debating the meaning of proposed text when we should
be debating the actual restrictions.  Once we agree on the restrictions we
can come up with text.  There can be no legitimate reason to argue against
clarifying the text, especially if the claim is that it does not mean what
it plainly says.

|I object to the proposed wording also, if only because routers must be able
|to be configured for 'inside' work at which point local addresses are
|in-scope and should not be filtered.  It should be possible to disable the
|filtering or refine it.

That was my point from the beginning.  The proposed wording forbids this.
But that appears to be its intent.  So object to the intent as well...

|With such a restriction, I don't see much incentive for an ISP (or other
|user) to disable the filters in a general manner.  Since most routers will
|filter anyway, they can only route the local packets to other people who've
|disabled the filters, and anyone disabling the filters (and only those
|people) needs to cope with potential routing table increases for their OWN
|tables.

There need be no routing table growth in an overlay network using dynamic
tunnels.  Only the existence of absurd restrictions on routing to the entire
"local" prefix could create artificial bloat by forcing multiple /48's (or
whatever) where a single default would have worked.

				Dan Lanciani
				ddl@danlan.*com

---

From: Dan Lanciani <[email-masked]>
Date: Thu, 4 Sep 2003 15:16:22 -0400 (EDT)

Brian E Carpenter <[email-masked]>

> ``Router manufacturers MUST ensure that said black hole cannot be deconfigured,
> turned off, or otherwise overridden in toto;''

|It's very simple. No sane router vendor would do this.

I pointed out in my original comments that most router vendors have little
incentive to abide by such a rule.  So far.  But that doesn't mean that they
won't find some reason in the future.  Moreover, entities building appliances
with incidental router functionality may be unfamiliar with the issues and
might follow the rule as written.  The result is that the new addresses become
devalued because you can't count on being able to configure all your network
devices to use them.

Why do we want to make a rule that no sane router vendor should follow?

|The MUST can only apply to default configuration.

But that's not at all what the language actually says.  Why do we need to
play such word games?  It reminds me of politicians who say: ``We really
need a law against common behavior x.  But don't worry.  It doesn't really
mean that we will stop you from doing x.  And besides, such a restriction would
be unenforceable.''  Then after the next election: ``It's really hard to enforce
the law against x.  We really need to ban y and z to make sure people can't do
x.  After all, some previous set of elected politicians decided to make a law
against x, so we have a duty to enforce it.''

				Dan Lanciani
				ddl@danlan.*com

---

From: Pekka Savola <[email-masked]>
Date: Mon, 8 Sep 2003 15:28:06 +0300 (EEST)

Alan,

You raised very good points.  Sorry for delay.  I'll try to respond to a
few old threads I had to drop for a while due to other work..

On Fri, 29 Aug 2003, Alan E. Beard wrote:
> > On Thu, 28 Aug 2003, Geoff Huston wrote:
> > [...]
> > > The likelihood of conflict exceeds 0.5 after only 1.24 million draws. I'd
> > > contend that this is definitely not "small" as described in the draft.
> >
> > I consider this a bug.  Actually, the number of draws should be smaller,
> > e.g. 1000, to avoid having local addresses misused where they should not.
> >
> > That way, prople wouldn't get delusions to e.g. route such addresses in
> > the Internet.  1.24 million draws until a probable conflict could still
> > sound attractive.
> 
> Hmmm.  Was not one of the stated benefits of unique-local the uniqueness
> (or near-uniqueness) of the address allocations generated by proposed
> allocation algorithm?  A suggestion to _deliberately_ increase the
> probability of allocation conflict strikes me as a fundamental conceptual
> change to the proposal.  With a change of this magnitude, it seems to me
> that the resulting draft would be so greatly at variance with the
> conceptual basis of the Hinden original that a new, wholly independent
> proposal would be in order, leaving the unique-local draft to stand or
> fall of its own merit.

Right.  But you have to consider the applicability of these solutions.  Do 
they aim to provide for near-uniqueness (or uniqueness through registry 
registrations) for local addresses, or the features required for local 
addressing (e.g. be able connect to your work network from home using 
VPN, or merge two enterprises)?

As for the first, one might worry that people figure.. "gee, these things
are unique, so why not route them globally now that I have them?"  If they
aren't unique _enough_ for that, they might not get that kind of bad
ideas.

On the other hand, for the second, the near-uniqueness requirement is not
so strong.  There is no need for everyone in the Internet to have unique
local addressing -- just those who have a common local "range" (and even
then, having someone to renumber now and then if there is a clash should
be OK, because that's inevitably going to happen anyway at some point).

> Additionally, such a suggestion, if implemented, would effectively
> prohibit one of the chief *legitimate* uses of GUPI address address
> allocations: routing between private networks on private (or VPN) links
> under bilateral agreements between the end networks.  Private routing
> arrangements are considered highly desirable to enterprise network
> operators (in fact, most enterprise network managers will tell you, with
> quite considerable warmth, that such arrangements are indispensible);
> decreased probability of uniqueness in allocations would, IMHO, leave the
> unique-local proposal fatally flawed.  If we wish to discourage ubiquity
> in deployment of NAT6, perhaps we should look to notions other than this.

Are you inferring that enterprises would route their local address spaces
through a service provider, in the cleartext, and to be reachable by
anyone using that ISP?  That would seem extremely dangerous to me.  On the
other hand, having a VPN between the enterprises, the endpoints of which
use _global_ addresses should be a non-issue.

[snip to the end]

-- 
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: "Michel Py" <[email-masked]>
Date: Wed, 10 Sep 2003 09:27:02 -0700

> Pekka Savola wrote:
> For example, for some services I maintain, I have:
> - TCP wrappers configuration in the host/service itself,
>   using /etc/hosts.allow
> - The local host firewall settings, doing similar
>   restrictions as above
> - Missing default route on the host, only some selected
>   routes used
> - The first hop router/firewall settings
> - A configuration at the site border router

To beat you with your own argument: all of these things can be easily
hacked, therefore there are no reasons to use them. Why are your
security precautions this different than localized addresses? It is as
easy to hack the hosts.allow than it is to create a tunnel outside.

Remember the car lock analogy: your host.allow trick is no better than
the typical car lock: a vaguely clued low-level thief will open it in a
matter of seconds. And still you use it.

Michel.