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
[log in to unmask]
> On Apr 6, 2020, at 5:12 PM, Richard Laager <[log in to unmask]> 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
