Paul Vixie wrote:
if you find me 300Ksqft along the caltrain fiber corridor in the peninsula where i can get 10mW of power and have enough land around it for 10mW worth of genset, and the price per sqft is low enough that i can charge by the watt and floor space be damned and still come out even or ahead, then please do send me the address.
Well, there are alternatives to the 10mW power and 10mW genset... 10-20mW (or more) of nuclear power/gensets. Get off the grid, sell back some power to the grid, reduce your costs for power, especially peak rate power, and be able to brag about having your own nuke plant. This may give you more flexibility in finding the space along the fibre corridor... BTW, I did some quick googling and found a few interesting links related to smaller nuclear generator systems: http://peswiki.com/index.php/Directory:Toshiba's_Micro_Nuclear_Reactor http://www.eia.doe.gov/cneaf/nuclear/page/analysis/nucenviss2.html http://www.eoearth.org/article/Small_nuclear_power_reactors http://www.uic.com.au/nip60.htm And if you have access to a deep harbor: http://atomic.msco.ru/cgi-bin/common.cgi?lang=eng&skin=menu1&fn=projects :-) Brian
On Sun, Mar 30, 2008 at 8:16 PM, Buhrmaster, Gary <gtb@slac.stanford.edu> wrote:
10-20mW (or more) of nuclear power/gensets.
While I would be much amused to see the response in the area when Paul requested approval to site a nuclear reactor on the Peninsula, I do not think even Paul is quite up to that challenge
Not so long up-thread, people were opposing water cooling on the grounds it was too dangerous...what if something leaked? Now we're talking sticking a nuclear reactor in your data centre.
On Sun, 30 Mar 2008, Brian Dickson wrote:
10-20mW (or more) of nuclear power/gensets.
You'd only need a gramme or two of spent nuclear fuel to get 10 milliwatts :-) Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ VIKING NORTH UTSIRE SOUTH UTSIRE FORTIES CROMARTY: SOUTHERLY 5 TO 7, PERHAPS GALE 8 LATER. MODERATE, INCREASING ROUGH OR VERY ROUGH LATER. RAIN OR SHOWERS. MODERATE OR GOOD.
What would the ip-blocking BGP feed accomplish? Spoofed source addresses are a staple of the DNS cache poisoning attack. Worst case scenario, you've opened yourself up to a new avenue of attack where you're nameservers are receiving spoofed packets intended to trigger a blackhole filter, blocking communication between your network and the legitimate owner of the forged ip address.
Yes, but what about blocking the addresses of recursive resolvers that are not yet patched? That would certainly stop them from being poisoned, and incent their owners to patch... 1/2 :-) Brian
Michael Smith wrote:
Still off topic, but perhaps a BGP feed from Cymru or similar to block IP addresses on the list?
Regards,
Mike
Alex P wrote:
*) There is no currently deployable solution to this problem yet.
*) Filtering your customers using IRR is a requirement, however, it is not a solution - in fact, in the demonstration, we registered the /24 prefix we hijacked in IRR. RIRs need to integrate the allocation data with their IRR data.
-alex [your former moderator]
Kind of true. When doing *prefix* filtering, this kind of hijack is not preventable. However, if *AS-path* filtering is done based on IRR data, specifically on the as-sets of customers and customers' customers etc., then the attack *can* be prevented. The as-path prepending depends on upstreams and their peers accepting the prefix with a path which differs from the expected path (if the upstreams register their as-sets in the IRR). If the as-path filter only allows generally-feasible as-paths from customers, where the permitted variations are just "N copies of ASfoo" (where "foo" is a member of an as-set), then adding a fake "ASbar" in the as-path will cause the prefix to be rejected. If you follow the diagram from the presentation, information about the *real* path to the victim, from the perspective of the hijacker, requires that the AS's on that path not see the hijacked prefix as announced by the hijackers. This means that if the AS's traversed are: as-hijacker, as-bar, as-victim, then as-bar must *not* see the hijacked victim, for the attack to work. By adding "as-bar" into the as-path of the hijacked prefix, the loop-prevention logic of BGP makes sure as-bar can't see the hijacked prefix. So, if the upstreams of as-hijacker reject all prefixes with an as-path which includes as-bar (because as-bar is not a member of any customer's as-set expansion), the attack fails. I hope I haven't managed to confuse folks too much. But, the short answer is: If you use the IRR, the full value is best realized by adding *as-path* filters to the things you build from the IRR data, and applying them to your customers (and peers !!). Oh, and if you already do IRR stuff, it's really quite easy to do. Brian Dickson
However, if *AS-path* filtering is done based on IRR data, specifically on the as-sets of customers and customers' customers etc., then the attack *can* be prevented.
The as-path prepending depends on upstreams and their peers accepting the prefix with a path which differs from the expected path (if the upstreams register their as-sets in the IRR). You are thinking about this specific exploit - which may in fact be stopped by as-path-filtering. However, that's not the problem you are solving. Problem is the hijacking. There are many other ways to reinject
On Thu, 28 Aug 2008, Brian Dickson wrote: traffic closer to victim - will require attacker to work a little harder, but not really fix the problem. (Think, GRE tunnels, no-export, no-export-to-specific-peer, etc). <snipped>
So, if the upstreams of as-hijacker reject all prefixes with an as-path which includes as-bar (because as-bar is not a member of any customer's as-set expansion), the attack fails. What's to stop me from adding as-bar into my as-set? To do what you are describing, you will have to enforce "export AS-LEFT" and "import AS-RIGHT" rules on every pair of AS-PATH adjacencies. And I'm not sure if existing tools can do that - or how many existing adjacencies fail that test.
Alex Pilosov wrote:
On Thu, 28 Aug 2008, Brian Dickson wrote:
However, if *AS-path* filtering is done based on IRR data, specifically on the as-sets of customers and customers' customers etc., then the attack *can* be prevented.
The as-path prepending depends on upstreams and their peers accepting the prefix with a path which differs from the expected path (if the upstreams register their as-sets in the IRR).
You are thinking about this specific exploit - which may in fact be stopped by as-path-filtering. However, that's not the problem you are solving. Problem is the hijacking. There are many other ways to reinject traffic closer to victim - will require attacker to work a little harder, but not really fix the problem. (Think, GRE tunnels, no-export, no-export-to-specific-peer, etc).
<snipped>
Very true. Tying allocations and assignments to ASN-of-origin and providing a suitable place to validate such, for building prefix and as-path filters, would do a lot towards further limiting the ability to hijack prefixes - but only to the degree to which providers filter their customers. And that's only on routes - to say nothing of packet filtering (BCP 38)...
So, if the upstreams of as-hijacker reject all prefixes with an as-path which includes as-bar (because as-bar is not a member of any customer's as-set expansion), the attack fails.
What's to stop me from adding as-bar into my as-set? To do what you are describing, you will have to enforce "export AS-LEFT" and "import AS-RIGHT" rules on every pair of AS-PATH adjacencies. And I'm not sure if existing tools can do that - or how many existing adjacencies fail that test.
True, there is nothing actually stopping you from doing this. However, (and this is both the key, and a big presumption) changes to as-sets are the kind of thing that automatic provisioning tools should alert on, and require confirmation of, before updating prefix-lists and as-path lists based on the new members of the as-set. While prefixes are routinely added, new transit relationships at a BGP level don't happen all *that* often. The idea isn't just to stop the prefix announcement, it is to trap activity that would otherwise permit the prefix hijack, at the time it occurs and before it takes effect. The closer this occurs to the hijacker, the more likely it is that appropriate responses can be directed at the bad guy, and with a greater likelihood of success (e.g. prosecution). The threat alone of such response may act as a suitable deterrent... As for the filter building and enforcement mechanisms: The inbound as-path filters need to permit the permutations of paths that result from expanding as-sets, but that can be accomplished unilaterally on ingress, without enforcement beyond the immediate peering session. The expansion is for each as-set behind an ASN, there should be a corresponding as-set, and so on... each gets expanded and added to the expansion of the permitted paths via that ASN. Lather, rinse, repeat. All filtering is local, although the more places filtering happens, the better. Brian
On Thu, 28 Aug 2008, Brian Dickson wrote:
However, if *AS-path* filtering is done based on IRR data, specifically on the as-sets of customers and customers' customers etc., then the attack *can* be prevented.
Yes, but I can't do this for everybody else. Doing AS-path and prefix filtering (matching that a certain prefix can only be announced by a certain AS) doesn't scale in IOS for instance. We do prefix filtering for OUR customers, but there is no feasable way for me to do this for everybody else. I think this needs to be fixed, but it involves something new that isn't present today, and I think it needs to involve vendors because they need to produce new code to handle it. -- Mikael Abrahamsson email: swmike@swm.pp.se
(Sorry - repost with fixed Subject line. My bad. -briand) Alex P wrote:
*) There is no currently deployable solution to this problem yet.
*) Filtering your customers using IRR is a requirement, however, it is not a solution - in fact, in the demonstration, we registered the /24 prefix we hijacked in IRR. RIRs need to integrate the allocation data with their IRR data.
-alex [your former moderator]
Kind of true. When doing *prefix* filtering, this kind of hijack is not preventable. However, if *AS-path* filtering is done based on IRR data, specifically on the as-sets of customers and customers' customers etc., then the attack *can* be prevented. The as-path prepending depends on upstreams and their peers accepting the prefix with a path which differs from the expected path (if the upstreams register their as-sets in the IRR). If the as-path filter only allows generally-feasible as-paths from customers, where the permitted variations are just "N copies of ASfoo" (where "foo" is a member of an as-set), then adding a fake "ASbar" in the as-path will cause the prefix to be rejected. If you follow the diagram from the presentation, information about the *real* path to the victim, from the perspective of the hijacker, requires that the AS's on that path not see the hijacked prefix as announced by the hijackers. This means that if the AS's traversed are: as-hijacker, as-bar, as-victim, then as-bar must *not* see the hijacked victim, for the attack to work. By adding "as-bar" into the as-path of the hijacked prefix, the loop-prevention logic of BGP makes sure as-bar can't see the hijacked prefix. So, if the upstreams of as-hijacker reject all prefixes with an as-path which includes as-bar (because as-bar is not a member of any customer's as-set expansion), the attack fails. I hope I haven't managed to confuse folks too much. But, the short answer is: If you use the IRR, the full value is best realized by adding *as-path* filters to the things you build from the IRR data, and applying them to your customers (and peers !!). Oh, and if you already do IRR stuff, it's really quite easy to do. Brian Dickson
participants (6)
-
Alex Pilosov -
Alexander Harrowell -
Brian Dickson -
Buhrmaster, Gary -
Mikael Abrahamsson -
Tony Finch