cooling door

Mailman List Mirror (Read Only)
1

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

:slight_smile:

Brian

2

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.

Gary

3

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.

4

You'd only need a gramme or two of spent nuclear fuel to get 10 milliwatts :slight_smile:

Tony.

5

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 :slight_smile:

Brian

6

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

7

(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

8

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>

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.

9

Alex Pilosov 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

10

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.