This came up in two different conversations in June and January (per mice-discuss archives) I think the concern here is that the route servers aren’t doing IRR filtering of members yet. I agree 100% with the approach below, but with one caveat - we need to be filtering members on the route servers first via IRR. Otherwise, nothing preventing a member from advertising a /32 tagged with a blackhole community of 8.8.8.8, or another member’s IP address. — Andrew Hoyos hoyosa@gmail.com <mailto:hoyosa@gmail.com>
On Apr 6, 2020, at 5:12 PM, Richard Laager <rlaager@WIKTEL.COM> wrote:
On 4/6/20 4:50 PM, Frank Bulk wrote:
One our IPs, 96.31.13.225, was on the receiving end of a volumetric DoS attack for about 20 minutes and some of the incoming traffic was going over our MICE link.
Do the MICE admins have a way to blackhole our IP, if needed?
No.
I'd love to see us implement something like this: https://www.seattleix.net/blackholing
Let's see if we can get this done. Here's what I see as steps:
1) Pick IPs and MACs. Here's a proposal: IPv4: 206.108.255.0 same idea as SIX IPv6: 2001:504:27:0:0:FFFF::666 from 65535:666 used in RFC 7999 MAC: 66:66:de:ad:be:ef same as SIX
2) Jeremy?: Configure MAC ACLs to drop traffic to that MAC on the core switches.
3) Doug?: Configure the route servers to: accept /32 (IPv4) and /128 (IPv6) set next-hop to the blackhole IP (see above) add no-export community when: next-hop == blackhole IP OR 65535:666 is set See also the BIRD example on the SIX page.
4) Me: Document this on our website & notify the members it's ready. Ask, but not require, that remote switches do the same.
-- Richard