- Previous message: Roland Dobbins: "Re: Blackholes and IXs and Completing the Attack."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
|
|
|
From: Ben Butler (no email)
Date: Sat Feb 02 2008 - 21:12:06 EST
Hi,
Agreed, but when you have >100 peers that is still a fair bit of work.
I know technically how to do it and am doing this with transits but then
there are only seven of those. It is not a question of how or can, but
should / is it valuable / constructive?
The starting point in the thought process having just done it for
transits was right ok, now how do we sensibly scale this to apply it at
IXes without everyone having to run round contacting everyone else and
to see if there was an easier way of doing things, hence the suggestion.
Plus it keeps things nice and separated, your IX peering sessions
announce just the main prefixes, the session to the "blackhole
reflector" can be in a separate peer-group and you only send the /32s to
the reflector. You don't have to worry about who uses which communities
as each member that chooses to peer with the reflector is able to apply
an inbound routemap of their own choosing to any prefixes they receive
from this reflector at each individual IX.
Given that an ISP has elected to Complete the attack on a host that is
being DoSed, for whatever reason, and they have chosen to send blackhole
announcements to transit the logical extension seems to be to automate
the sending of them to IXs to try to further cut down on traffic. I
guess the alernative is that if your IX interconnect is getting hammered
the only other option is to admin down all the sesions over the IX and
let all the traffic flow into transit and let them blackhole it. But
this also seems like there might be a better way that was less
disruptive.
And this seems like a easy way, internally you just community tag on the
trigger box for where you want the announcement to go, transit,
internal, customers, IX all,1 2 not 3 - whatever - and BGP sends it out.
Easy, and a single system to send out all updates when you choose to and
easy to remove when you want to take it out again.
If you subscribe to completing the attack as a strategy, then the
suggestion seemed like an easy way of rolling it out to the next logical
point after transit.
Kind Regards
Ben
________________________________
From: Rick Astley [mailto:]
Sent: 03 February 2008 01:02
To: Ben Butler
Cc:
Subject: Re: Blackholes and IXs and Completing the Attack.
While I am not sure I fully understand your suggestion, I don't think it
would be that hard to set up manually.
Sure it would require asking the individual peers for their black hole
communities, but of they don't have one they are unlikely to honor the
infrastructure you describe anyway.
Assume your network is set up to discard packets marked with community
13005:666
Get a list of your peers blackhole communities, when you announce the
route from a location on your network, tag it with community 13005:666
but also 1111:777, 2222:888 etc. for the individual peers from the
source. This prevents you from having to update multiple policies in
multiple locations for each attack.
As long as they accept the /32 announced to them with their black hole
community, they should discard the traffic without sending it to you.
Not all peers will have a blackhole community, but you need some way to
know when the attack is over to know when to withdraw the route, and
they are useful for this.
If you are real lazy, on the router you announce the black hole from,
add an export policy that says from community 13005:666, then community
add 1111:777, 2222:888 etc.
This way you only need to:
1. Update one policy in one place when peers change
2. Announce the route from one location adding one community to it.
|
|
|