- mice-discuss - lists.micemn.net

Re: Route Server Filtering

by Andrew Hoyos

On Dec 1, 2016, at 8:32 PM, Richard Laager <rlaager(a)WIKTEL.COM> wrote: > > I'm looking for feedback on a filtering proposal. I propose that, on the > route server, by default, we filter incoming routes to block anything > matching: > _(174|209|286|701|1239|1299|2828|2914|3257|3320|3356|3549|5511|6453|6461|6762|6939|7018|12956)_ I fully support this. Also would suggest blocking bogon ASNs on the route servers too (good list/examples in Job’s presentation as well) For those doing bilateral peering, I’d also highly suggest applying sane import filters on peers to catch folks that aren’t behaving properly. We do something like: - reject 0/0 - reject RFC1918 - reject bogon ASNs - reject /25 - /32’s -- Andrew Hoyos hoyosa(a)gmail.com

Dec. 2, 2016

Re: Route Server Filtering

by Steve Howard

Dec. 2, 2016

Re: Participants leaking BGP routes for the MICE IXP Block

by David Farmer

I didn't think of that variant, but that's why we discuss these kind of things. I'm willing to give that a try. Heck, I might even give people two or three strikes, especially if the actually respond to my email rather than ignore me. :) However, I thought of one advantage of #4 after sending the email. In the case on non-nuisance incidents, like an actual hijack event, everyone is notified immediately. Otherwise, it has to wait for me to forward the email in the case of an actual event. BGPmon pages me, because the University has the paid service, but I'm only human and therefore fallible. Any other comments? On Thu, Dec 1, 2016 at 8:02 PM, Russell Berg <berg(a)wins.net> wrote: > I agree... first strike private, second strike public. Automatic if you > don't want to be the transgressor tracker. > > Russ > > -----Original Message----- > From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of > Richard Laager > Sent: Thursday, December 01, 2016 8:00 PM > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET > Subject: Re: [MICE-DISCUSS] Participants leaking BGP routes for the MICE > IXP Block > > On 12/01/2016 06:56 PM, David Farmer wrote: > > 2. Notify transgressors PRIVATELY > > 3. Manually, Name and Shame transgressors 4. Automated, Name and Shame > > of transgressors (setup a BGPmon account to mail to MICE-DISCUSS) > > If you are willing to do the work, I like 2, followed by 3. If you don't > want to do the work, then 4. > > -- > Richard > > -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 ===============================================

Dec. 2, 2016

Re: Route Server Filtering

by David Farmer

On Thu, Dec 1, 2016 at 8:32 PM, Richard Laager <rlaager(a)wiktel.com> wrote: > I'm looking for feedback on a filtering proposal. I propose that, on the > route server, by default, we filter incoming routes to block anything > matching: > _(174|209|286|701|1239|1299|2828|2914|3257|3320|3356|3549| > 5511|6453|6461|6762|6939|7018|12956)_ > > We can, of course, create exceptions if necessary. One obvious one is > that HE's connection would need their own AS (6939) removed from the > block list. > > This particular list is from here, with 6939 added by me: > https://www.nanog.org/sites/default/files/Snijders_ > Everyday_Practical_Bgp.pdf I'm fine with this. If we do this, I request that 11537 and 11164 be added to the list as well, these are the Internet2 R&E backbone and commercial peering service respectively, a doubt we, UW-Sysnet, or Wiscnet would leak these, but never say never. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 ===============================================

Dec. 2, 2016

Re: MICE Fees Proposal/UG Agenda Item/Request for Comment

by Richard Laager

On 12/01/2016 10:19 AM, Steve Howard wrote: > I'd like to see every member get the first year (or fraction of year > depending upon when they start service) free. This gives everybody a > chance to try it and see if it makes sense for them. Does this matter in practice? If they're committing to $200/month for 36 months with Cologix for the cross-connect, a few months of free 10G port fee is a drop in the bucket. And in Jay's proposal, they could simply start at 1G. If that fills, the exchange has obvious value and they can immediately upgrade to 10G. In your proposal, the 1G is similarly practically free, even though it isn't literally free. > For example: > $35/Gbps/year for everybody. First year (or fraction thereof free). > > 1Gbps=$35/Year > 10Gbps=$350/Year > 100Gbps=$3,500/Year >From my experience, very few costs in the telecom world scale linearly with bandwidth. That is, a 10x increase in bandwidth is usually not 10x the cost. -- Richard

Dec. 2, 2016

Re: MICE Fees Proposal/UG Agenda Item/Request for Comment

by Richard Laager

On 12/01/2016 11:07 AM, Mike Horwath wrote: > 1Gbe ports - $250 annual per port, LAG allowed, max 2 > 10Gbe ports - $500 annual per port, LAG allowed, max 4 > 40Gbe ports - $2000 annual per port, cause why not just do 100Gbe!?!, > LAG max 2, and above no 40Gbe ports were listed so really, do > 100Gbe and let's move on, okay? > 100Gbe ports - $3000 annual per port, LAG allowed, max 4 40 Gb was not listed because a 40 Gb request uses the same switch port as a 100 Gb request. Accordingly, I would treat anything that consumes a 100G port the same. Also, as a nice side effect, this avoids "penalizing" someone who needs more than 10G because they have 100G gear and not 40G gear. -- Richard

Dec. 2, 2016

Re: MICE Fees Proposal/UG Agenda Item/Request for Comment

by Richard Laager

I think everyone remembers I agree about PayPal being dangerous on arbitrary account freezes. :) On 12/01/2016 08:36 PM, Reid Fishler wrote: > I don't love PayPal, but with it, you can have the FUNDER pay the fee. > The last thing I want is MICE having to swallow the CC fees. We don't need platform support to make the member pay the fee. Let's say we used Stripe, as Nevin proposes. When the member says they want to pay via credit card, we simply send them a Stripe bill for $1,031 instead of $1,000. -- Richard

Dec. 2, 2016

Re: MICE Fees Proposal/UG Agenda Item/Request for Comment

by Reid Fishler

I don't love PayPal, but with it, you can have the FUNDER pay the fee. The last thing I want is MICE having to swallow the CC fees. Reid On Thu, Dec 1, 2016 at 9:34 PM, Nevin Lyne <nevin(a)enginehosting.com> wrote: > > > >> We can use Paypal to process credit cards the fee > >> is about 3%. > > Just an FYI, I would highly recommend staying away from Paypal for this, > and use something like Stripe.com. I have seen too many businesses > including established conferences use Paypal that end up having frozen > accounts or other issues with them for random reasons. > https://stripe.com/us/pricing/ is the same pricing, 2 day fund deposits > and we run 100,000+ trasactions/yr through them without issue. > > -Nevin > > > -- Nevin Lyne > -- Founder & Director of Technology > -- Arcustech, LLC. - arcustech.com > -- Gippy's Internet Solutions, LLC. - enginehosting.com > > > -- Reid Fishler Director Hurricane Electric +1-510-580-4178

Dec. 2, 2016

Re: MICE Fees Proposal/UG Agenda Item/Request for Comment

by Nevin Lyne

>> We can use Paypal to process credit cards the fee >> is about 3%. Just an FYI, I would highly recommend staying away from Paypal for this, and use something like Stripe.com. I have seen too many businesses including established conferences use Paypal that end up having frozen accounts or other issues with them for random reasons. https://stripe.com/us/pricing/ is the same pricing, 2 day fund deposits and we run 100,000+ trasactions/yr through them without issue. -Nevin -- Nevin Lyne -- Founder & Director of Technology -- Arcustech, LLC. - arcustech.com -- Gippy's Internet Solutions, LLC. - enginehosting.com

Dec. 2, 2016

Route Server Filtering

by Richard Laager

I'm looking for feedback on a filtering proposal. I propose that, on the route server, by default, we filter incoming routes to block anything matching: _(174|209|286|701|1239|1299|2828|2914|3257|3320|3356|3549|5511|6453|6461|6762|6939|7018|12956)_ We can, of course, create exceptions if necessary. One obvious one is that HE's connection would need their own AS (6939) removed from the block list. This particular list is from here, with 6939 added by me: https://www.nanog.org/sites/default/files/Snijders_Everyday_Practical_Bgp.p… I've been using something similar in my own network for years because of a badly-behaved peer who I have been unable to set straight. They don't connect to MICE, though. This problem can and does occur at MICE. In fact, it's occurring right now. I've just emailed the relevant network. I suspect this happens because some networks filter their outgoing announcements using fixed prefix lists, not communities based on where they heard the route from. As a result, if their link to a customer goes down (temporarily or permanently), they start leaking transit routes for their customer AS. -- Richard

Dec. 2, 2016