April 2020 - mice-discuss - lists.micemn.net

Re: Blackhole IP if needed?

by Richard Laager

On 4/6/20 6:38 PM, Andrew Hoyos wrote: > > On Apr 6, 2020, at 5:25 PM, Richard Laager <rlaager(a)WIKTEL.COM > <mailto:rlaager@WIKTEL.COM>> wrote: >> >> On 4/6/20 5:17 PM, Andrew Hoyos wrote: >>> 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. >> >> Nothing is stopping me from announcing 8.8.8.0/24 right now, right? > > I agree, that’s true in the current scenario. Nothing preventing you > from doing that towards the route servers. > > As it stands right now, though, we wouldn’t necessarily have to accept > that route, and we’d have local control to reject/block or filter your > ASN, drop RPKI invalid prefixes, etc, and to react as we please (ie: > operational processes to fix the issue without reliance on MICE > intervention, and without completely dropping our route server sessions). > > Or perhaps folks are already doing self-generated prefix lists and > actions towards route server prefixes already (we, for example, > passively keep an eye on ASNs/IRR data vs routes learned from MICE > route servers). > > In short, we’ve got tools to deal, if you do. ... > In the case we enable a RTBH community without strict filtering, we’ve > taken the control out of the members hands, and put a powerful tool in > any members hands with no regard to security. I'm still not understanding the difference between someone originating 8.8.8.0/24 and 8.8.8.8/32+65535:666. In either case (with blackholing support added), the route server will accept and propagate that to route server users. Whether they choose to accept that announcement is up to them the same either way. Note that announcements to the route server do /not/ directly result in blackholing traffic across the fabric. It simply sets a special next-hop.* If a participant chooses to accept that BGP route and route traffic to that next-hop*, only then will the traffic will be eaten. To put a finer point on this: if someone does not use the route servers, this change does not affect them in any way no matter what anyone announces as a blackhole route to the route servers. * I forgot to mention that we'll need something on the route servers that will respond to ARP/ND requests for the blackhole IPs and return the blackhole MAC. -- Richard

April 6, 2020

Re: Blackhole IP if needed?

by Andrew Hoyos

On Apr 6, 2020, at 5:25 PM, Richard Laager <rlaager(a)WIKTEL.COM> wrote: > > On 4/6/20 5:17 PM, Andrew Hoyos wrote: >> 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. > > Nothing is stopping me from announcing 8.8.8.0/24 right now, right? I agree, that’s true in the current scenario. Nothing preventing you from doing that towards the route servers. As it stands right now, though, we wouldn’t necessarily have to accept that route, and we’d have local control to reject/block or filter your ASN, drop RPKI invalid prefixes, etc, and to react as we please (ie: operational processes to fix the issue without reliance on MICE intervention, and without completely dropping our route server sessions). Or perhaps folks are already doing self-generated prefix lists and actions towards route server prefixes already (we, for example, passively keep an eye on ASNs/IRR data vs routes learned from MICE route servers). In short, we’ve got tools to deal, if you do. > I agree that the IRR filtering is important, but is that absolutely > necessary here? In the case we enable a RTBH community without strict filtering, we’ve taken the control out of the members hands, and put a powerful tool in any members hands with no regard to security. Say someone does do something nefarious, or inadvertent that breaks something important? How quickly can it be fixed, who can fix it, etc, etc? Operational processes become a lot more important. The fix on a members side is a lot more intrusive (ie: turn down port), and the impact is much greater (blackholed across entire IX fabric - and potentially also affecting bilateral peering traffic). I think it’d be extremely irresponsible of MICE, and I’m vehemently opposed to enabling RTBH on the route servers or fabric, without first having the proper tools in place to ensure it can be used sanely and securely (IRR based filtering + route server looking glass). My $0.02… — Andrew Hoyos hoyosa(a)gmail.com <mailto:hoyosa@gmail.com>

April 6, 2020

Re: Blackhole IP if needed?

by Richard Laager

On 4/6/20 5:17 PM, Andrew Hoyos wrote: > 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. Nothing is stopping me from announcing 8.8.8.0/24 right now, right? I agree that the IRR filtering is important, but is that absolutely necessary here? -- Richard

April 6, 2020

Re: Blackhole IP if needed?

by Andrew Hoyos

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(a)gmail.com <mailto:hoyosa@gmail.com> > On Apr 6, 2020, at 5:12 PM, Richard Laager <rlaager(a)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

April 6, 2020

Re: Blackhole IP if needed?

by Richard Laager

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

April 6, 2020

Blackhole IP if needed?

by Frank Bulk

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? Frank Premier Communications (AS53347) FiberNet Communications (AS18883)

April 6, 2020

Re: ADV: [MICE-DISCUSS] Zayo outage in the metro?

by Jeff Dahna

We have a A-Link to Plymouth down since 10:14pm yesterday. No maintenance notice either. I put in a ticket with IQ last night. IQ response was Zayo maintenance, no notification and were added to the master ticket. Zayo went past maintenance window and was hands off 9ish. 10:30am - Called IQ to escalate and got the usual response. Still not fixed.... Jeff Dahna General Manager | City of Windom Telecom Dept-Windomnet On Apr 4, 2020 13:58, Dean Bahls <dean.bahls(a)COOPERATIVE-NETWORKS.COM> wrote: Anyone know of an outage that Zayo has been experiencing in the Metro area since about 10:30pm last night? We’ve found that it was a planned maintenance that nobody had been notified about. I don’t know if it affects other systems (like Ethernet or dark fiber), but toll services using Intelliquent (Onvoy) have been down since that time and nobody has gotten any updates about this thing. Thanks for any info you can share! Dean Dean Bahls Network Services Manager | Cooperative Network Services, LLC 14 Main St SW | PO Box J | Menahga, MN 56464 218.346.3635 (Direct) | 218.564.3000 (Main Office) dean.bahls(a)cooperative-networks.com<mailto:dean.bahls@cooperative-networks.com> [cid:image003.jpg@01D60A89.0CBE6550] ________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

April 4, 2020

Zayo outage in the metro?

by Dean Bahls

Anyone know of an outage that Zayo has been experiencing in the Metro area since about 10:30pm last night? We've found that it was a planned maintenance that nobody had been notified about. I don't know if it affects other systems (like Ethernet or dark fiber), but toll services using Intelliquent (Onvoy) have been down since that time and nobody has gotten any updates about this thing. Thanks for any info you can share! Dean Dean Bahls Network Services Manager | Cooperative Network Services, LLC 14 Main St SW | PO Box J | Menahga, MN 56464 218.346.3635 (Direct) | 218.564.3000 (Main Office) dean.bahls(a)cooperative-networks.com <mailto:dean.bahls@cooperative-networks.com>

April 4, 2020

Re: [ADV] [MICE-DISCUSS] Wiscnet Remote Switch

by Richard Laager

On 4/3/20 11:05 AM, Doug McIntyre wrote: > I have allocated Port-Channel 37 for Wiscnet. That's what I was assuming it was going to be. So I just pushed the changes I made. The website should be updated, including the equipment diagram and the Order Form. -- Richard

April 3, 2020

Re: [ADV] [MICE-DISCUSS] Wiscnet Remote Switch

by Doug McIntyre

On Fri, Apr 03, 2020 at 08:03:08AM -0500, Jay Hanke wrote: >Please allocate port Ethernet 3/22/1 on the Main Switch for the new Wiscnet >Remote switch. > >Please configure the port as a single member LAG group and the port >security settings for a remote switch. > All set, I have allocated Port-Channel 37 for Wiscnet. -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

April 3, 2020