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:jnanog@gmail.com] Sent: 03 February 2008 01:02 To: Ben Butler Cc: nanog@merit.edu 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.