nanog mailing list archives

Re: Why ULA: low collision chance (Was: IPv6 fc00::/7 — Unique local addresses)


From: Owen DeLong <owen () delong com>
Date: Sat, 23 Oct 2010 00:07:41 -0700


On Oct 22, 2010, at 6:10 PM, William Herrin wrote:

On Fri, Oct 22, 2010 at 11:40 AM, Owen DeLong <owen () delong com> wrote:
On Oct 22, 2010, at 5:25 AM, William Herrin wrote:
On Fri, Oct 22, 2010 at 1:20 AM, Joel Jaeggli <joelja () bogus com> wrote:
On 10/21/10 6:38 PM, Owen DeLong wrote:
On Oct 21, 2010, at 3:42 PM, Jack Bates wrote:
On 10/21/2010 5:27 PM, Joel Jaeggli wrote:

Announce your gua and then blackhole it and monitor your prefix.
you can tell if you're leaking. it's generally pretty hard to
tell if you're leaking rfc 1918 since your advertisement may well
work depending on the filters of your peers but not very far.

This is always the argument I hear from corporate customers
concerning wanting NAT. If  mistake is made, the RFC 1918 space
isn't routable. They often desire the same out of v6 for that
reason alone.

the rfc 1918 space is being routed inside almost all your adjacent
networks, so if their ingress filtering is working as expected, great,
but you're only a filter away from leaking.

A filter away from leaking to -one- of the millions of entities on the
internet. Two filters away from leaking to two.

This underestimates the transitive property of leakage.

Owen,

Just for grins, let's put some rough math to that assertion. The
average percentage of the Internet reached by a ULA or RFC1918 leak
will be close to:

(1-A)^C

A = the probability of any given organization filtering private
address announcements and/or private address packets at their borders
B = the average width of the Internet in organizations (which should
be slightly higher than the width in ASes)

I'll note that you don't have a B in your equation and didn't define C, so,
I'll presume that C= the average width...

So filling in example numbers for the equation, if 50% filter
announcements or packets and the Internet is an average of 10
organizations wide then the scope of an address leak is:

(1-0.5)^10 = 0.5 ^ 10 = 0.1% of the Internet reached by the leak.

I think your estimation of 50% is highly optimistic. I also think
you underestimate the diameter of the internet, being much
closer to 25 than 10 from what I can see. Filling in more
realistic (based on my observations) numbers of 5% and 25,
my numbers come out as:

(1-0.05)^25 = 0.95 ^ 25 = 0.27 = a little more than 1/4 of the internet.

In that scenario, the leak is in a very real sense one thousandth as
serious as if the leak had been from GUA space which all of the
organizations make an effort to carry. And that's assuming that fully
half the organizations on the Internet just don't bother trying to
filter RFC1918 or ULA use from their public networks.

With more realistic numbers, it's closer to 1/4 of the impact of a leak
from GUA where you both leaked the route and failed your IP
filter and didn't null-route the prefix at your border. (Gee, that seems
like three mistakes you need to make for the GUA problem to take
effect instead of just the "two" you claimed for ULA).

If 75% filter then a whopping 0.0001% of the Internet is reached by the leak.

ROFLMAO... Yeah, and if Ostriches had 15 times the wing surface area they
could probably fly.

Now, if only 10% filter then your leak reaches a largish 6% of the
Internet. That's a worry for someone hoping for some security benefits
to not using GUA space but it's far too little to support this bizarre
concern that ULA space would somehow supplant GUA space on the public
Internet and explode the routers.

ULA won't supplant GUA, it will be much more insidious than that. Most
people will still use GUA for GUA purposes.

However, deliberate routing of ULA will start small and slowly spread
over time like a slow-growing cancer. You won't even really detect it
until it has metastasized to such an extent that nothing can be done
about it.

You can't talk about the impact of an accidental leak and compare that
to the impact of a deliberate choice to do something. They are two
entirely different effects.


Of course, I make no claim to know what the correct two constants are
in that equation. Perhaps the Internet is thinner. Perhaps nobody
filters egress packets despite years of proselytizing. Perhaps the ISP
peering interconnectedness corrupts the combinatorics I used to derive
the equation in a more substantial fashion than is obvious.

I think that the internet is actually much wider and that the actual filtration
rate is much closer to 5%. I also think that the peering combinatorics do
probably corrupt your equation, but, I'm not sure in which direction or
to what extent. It would be pretty hard to estimate, so, I'm willing to
go with it for now.

Or perhaps your worry about route leakage from non-GUA space really is
as overblown as the math suggests.

I'm not worried about leakage. You're claiming that a low probability of
leakage provides a security benefit, I'm claiming that your security benefit
is actually a false sense of security. (i.e. The benefit claimed for ULA
is somewhere between small and non-existent).

In a separate topic, I believe that DELIBERATE routing of ULA will
be a very likely outcome of current policies eventually resulting in
ULA being ubiquitously routed just as GUA is intended to be. This
unfortunate end result of the combination of human nature to do
the expedient rather than the correct will eventually remove any
perceive benefits to ULA and cause additional problems as ULA
becomes a globally routable resource not subject to RIR policy.

The two issues are related, but, very different problems. (Actually,
the first issue isn't really a problem unless you are depending on
ULA to provide some form of security benefit).

In my opinion, the far more secure thing to do is to use GUA.
Put the hosts you want to be reachable from the outside in
specific ranges of your GUA.

For example:

        2620:0db8:532a::/48     Total assignment for end site
        2620:0db8:532a::/56     Space reserved for externally reachable

Configure the following on your border routers:

Routes:
        2620:0db8:532a::/56     dynamic or static routes to correct destinations.
        2620:0db8:532a:100::/55 -> null
        2620:0db8:532a:200::/54 -> null
        2620:0db8:532a:400::/53 -> null
        2620:0db8:532a:800::/52 -> null
        2620:0db8:532a:1000::/51 -> null
        2620:0db8:532a:2000::/50 -> null
        2620:0db8:532a:4000::/49 -> null
        2620:0db8:532a:8000::/48 -> null

Route filters:
        From internal interfaces:
                Accept 2620:0db8:532a::/56 or longer
                Deny 2620:0db8:532a:: ge /48 le /55

Packet filters:
        Stateful (outbound to internet):
                Permit <source match 2620:0db8:532a::/56> any
                Default Deny any any

        Stateful (inbound from internet):
                Permit <specifically intended inbound flows to 2620:0db8:532a::/56>
                Permit <matching outbound state table entry>
                Deny any 2620:0db8:532a::/48
                Default deny inbound

        Static (outbound to internal interfaces)
                permit any 2620:0db8:532a::/56
                deny any any

        Static (inbound from internal interfaces)
                permit <source match 2620:0db8:532a::/56> any
                deny any any

(Assuming a router capable of stateful and static filters
where a packet must be permitted by both in order to be
forwarded. This is the case for JunOS. I'm not sure about
Cisco or others. If you can only do stateless on your router,
then, you lose one layer of defense, but, not all).

Presumably you have stateful firewall(s) inside your border
with appropriate full stateful policies.

Now, in order to reach one of the hosts in the GUA
space being used for the internal-only communications,
one needs to make the following unauthorized or errant
changes:

        1.      Override the null route. (either a static route or
                        an unauthorized change to the dynamic
                        filter + a dynamic route generated by
                        or through the firewall).

        2.      Override the stateful Packet filter.

        3.      Override the Static packet filter.

        4.      Permit the flow on the firewall.

Or, the easier approach:

        1.      Configure the host with an externally reachable address
                in the public accessible host range.

        2.      Plug the host into one of the publicly reachable networks
                rather than an internal network.

        3.      Add inbound permits to the stateful packet filter.

        4.      Add inbound permits to the firewall.

Eiher way, it takes at least four acts of fat-fingered or malicious
activity on hosts that have a security border role in order to
achieve a meaningful leak, not the single error you claimed.

Owen


Current thread: