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