Print

Print


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



To unsubscribe from the MICE-DISCUSS list, click the following link:
http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1