December 2016 - mice-discuss - lists.micemn.net

Re: Participants leaking BGP routes for the MICE IXP Block

by DeLong, Owen

Couldn't we automate private notification followed by public if not resolved within 24 hours? Wouldn't that be the best of both worlds? Owen On Dec 1, 2016, at 23:11, David Farmer <farmer(a)UMN.EDU<mailto:farmer@UMN.EDU>> wrote: 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<mailto:berg@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<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<mailto:MICE-DISCUSS@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<mailto:Email%3Afarmer@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 =============================================== ________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.iphouse.net_cgi-2…>

Dec. 6, 2016

Re: Participants leaking BGP routes for the MICE IXP Block

by Gary Glissendorf

Everyone should not be sending that range but if they are can the import filters for each bgp neighbor to ignore drop for that routes if one is received. Just like the private IP list and AS list. gary.glissendorf(a)sdncommunications.com<mailto:gary.glissendorf@sdncommunications.com> <gary.glissendorf(a)sdncommunications.com<mailto:gary.glissendorf@sdncommunications.com>> 2900 W. 10th St. | Sioux Falls, SD 57104 (w) 605.978.3558 | (c) 605.359-3737 | (tf) 800.247.1442 SDN NOC 877.287.8023 NOC Support email: sdnsupport(a)sdncommunications.com<mailto:sdnsupport@sdncommunications.com> <sdnsupport(a)sdncommunications.com<mailto:sdnsupport@sdncommunications.com>> “Be Excellent to Each Other” From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of David Farmer Sent: Thursday, December 1, 2016 10:12 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Participants leaking BGP routes for the MICE IXP Block 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<mailto:berg@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<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<mailto:MICE-DISCUSS@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<mailto:Email%3Afarmer@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 =============================================== ________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 ________________________________ ***This message and any attachments are solely for the intended recipient. If you are not the intended recipient, disclosure, copying, use or distribution of the information included in this message is prohibited -- Please immediately and permanently delete.***

Dec. 5, 2016

Re: Route Server Filtering

by Gary Glissendorf

SDN Supports the filtering. The AS and the - reject 0/0 - reject RFC1918 - reject bogon ASNs - reject /25 - /32's Keep it as clean as possible. We only want member routes nothing else. gary.glissendorf(a)sdncommunications.com <gary.glissendorf(a)sdncommunications.com> 2900 W. 10th St. | Sioux Falls, SD 57104 (w) 605.978.3558 | (c) 605.359-3737 | (tf) 800.247.1442 SDN NOC 877.287.8023 NOC Support email: sdnsupport(a)sdncommunications.com <sdnsupport(a)sdncommunications.com> "Be Excellent to Each Other" -----Original Message----- From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Andrew Hoyos Sent: Friday, December 2, 2016 9:08 AM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Route Server Filtering 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|64 > 61|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 ________________________________ ***This message and any attachments are solely for the intended recipient. If you are not the intended recipient, disclosure, copying, use or distribution of the information included in this message is prohibited -- Please immediately and permanently delete.***

Dec. 5, 2016

Re: Route Server Filtering

by Ben Wiechman

Arvig would also support this. Ben Wiechman Network Engineer IV | Arvig Direct: 320.256.0184 Cell: 320.247.3224 Office: 320.256.7471 ben.wiechman(a)arvig.com On Fri, Dec 2, 2016 at 11:11 AM, Richard Laager <rlaager(a)wiktel.com> wrote: > On 12/02/2016 09:07 AM, Andrew Hoyos wrote: > > - reject 0/0 > > - reject RFC1918 > > - reject bogon ASNs > > Is this what you had in mind? Any changes? > > Specifically, is blocking AS_TRANS 23456 good or bad? I did not block > it in the list below. > > > Block (original, plus additions from David Farmer): > _(174|209|286|701|1239|1299|2828|2914|3257|3320|3356|3549| > 5511|6453|6461|6762|6939|7018|11164|11537|12956)_ > > exception: remove 6939 from this list on HE's connection > > Block private AS using this or something with the same effect: > _(6449[6-9])_|_(6450[0-9])_|_(6451[0-1])_|_(6553[6-9])_|_( > 6554[0-9])_|_(6555[0-1])_ > _6(4(5(1[2-9]|[2-9][0-9])|[6-9][0-9][0-9])|5([0-4][0-9][0- > 9]|5([0-2][0-9]|3[0-5])))_ > _6555[2-9]_|_655[6-9][0-9]_|_65[6-9][0-9][0-9]_|_6[6-9][0-9][0-9][0-9]_ > _[7-9][0-9][0-9][0-9][0-9]_|_1[0-2][0-9][0-9][0-9][0-9]_|_ > 130[0-9][0-9][0-9]_ > _1310[0-6][0-9]_|_13107[0-1]_ > _42[0-8][0-9][0-9][0-9][0-9][0-9][0-9][0-9]_ > _(429[0-3][0-9][0-9][0-9][0-9][0-9][0-9])_|_(4294[0-8][0-9][ > 0-9][0-9][0-9][0-9])_ > _(42949[0-5][0-9][0-9][0-9][0-9])_|_(429496[0-6][0-9][0-9][0-9])_ > _(4294967[0-1][0-9][0-9])_|_(42949672[0-8][0-9])_|_(429496729[0-5])_ > > AS0 is a bogon AS we could block: > _0_ > > Block default and RFC 1918, etc. > ip prefix-list upstream-in seq 900 deny 0.0.0.0/8 le 32 > ip prefix-list upstream-in seq 905 deny 10.0.0.0/8 le 32 > ip prefix-list upstream-in seq 910 deny 127.0.0.0/8 le 32 > ip prefix-list upstream-in seq 915 deny 169.254.0.0/16 le 32 > ip prefix-list upstream-in seq 920 deny 172.16.0.0/12 le 32 > ip prefix-list upstream-in seq 925 deny 192.0.0.0/24 le 32 > ip prefix-list upstream-in seq 930 deny 192.0.2.0/24 le 32 > ip prefix-list upstream-in seq 935 deny 192.168.0.0/16 le 32 > ip prefix-list upstream-in seq 945 deny 198.51.100.0/24 le 32 > ip prefix-list upstream-in seq 950 deny 203.0.113.0/24 le 32 > ip prefix-list upstream-in seq 955 deny 224.0.0.0/3 le 32 > ip prefix-list upstream-in seq 990 deny 0.0.0.0/0 le 7 > > Similar for IPv6: > ipv6 prefix-list upstream-in seq 900 deny 3ffe::/16 le 128 > ipv6 prefix-list upstream-in seq 901 deny 2001:db8::/32 le 128 > ipv6 prefix-list upstream-in seq 910 permit 2001::/32 > ipv6 prefix-list upstream-in seq 911 deny 2001::/32 le 128 > ipv6 prefix-list upstream-in seq 920 permit 2002::/16 > ipv6 prefix-list upstream-in seq 921 deny 2002::/16 le 128 > ipv6 prefix-list upstream-in seq 930 deny ::/8 le 128 > ipv6 prefix-list upstream-in seq 940 deny fe00::/9 le 128 > ipv6 prefix-list upstream-in seq 941 deny ff00::/8 le 128 > > -- > Richard >

Dec. 2, 2016

Re: Route Server Filtering

by Richard Laager

On 12/02/2016 09:07 AM, Andrew Hoyos wrote: > - reject 0/0 > - reject RFC1918 > - reject bogon ASNs Is this what you had in mind? Any changes? Specifically, is blocking AS_TRANS 23456 good or bad? I did not block it in the list below. Block (original, plus additions from David Farmer): _(174|209|286|701|1239|1299|2828|2914|3257|3320|3356|3549|5511|6453|6461|6762|6939|7018|11164|11537|12956)_ exception: remove 6939 from this list on HE's connection Block private AS using this or something with the same effect: _(6449[6-9])_|_(6450[0-9])_|_(6451[0-1])_|_(6553[6-9])_|_(6554[0-9])_|_(6555[0-1])_ _6(4(5(1[2-9]|[2-9][0-9])|[6-9][0-9][0-9])|5([0-4][0-9][0-9]|5([0-2][0-9]|3[0-5])))_ _6555[2-9]_|_655[6-9][0-9]_|_65[6-9][0-9][0-9]_|_6[6-9][0-9][0-9][0-9]_ _[7-9][0-9][0-9][0-9][0-9]_|_1[0-2][0-9][0-9][0-9][0-9]_|_130[0-9][0-9][0-9]_ _1310[0-6][0-9]_|_13107[0-1]_ _42[0-8][0-9][0-9][0-9][0-9][0-9][0-9][0-9]_ _(429[0-3][0-9][0-9][0-9][0-9][0-9][0-9])_|_(4294[0-8][0-9][0-9][0-9][0-9][0-9])_ _(42949[0-5][0-9][0-9][0-9][0-9])_|_(429496[0-6][0-9][0-9][0-9])_ _(4294967[0-1][0-9][0-9])_|_(42949672[0-8][0-9])_|_(429496729[0-5])_ AS0 is a bogon AS we could block: _0_ Block default and RFC 1918, etc. ip prefix-list upstream-in seq 900 deny 0.0.0.0/8 le 32 ip prefix-list upstream-in seq 905 deny 10.0.0.0/8 le 32 ip prefix-list upstream-in seq 910 deny 127.0.0.0/8 le 32 ip prefix-list upstream-in seq 915 deny 169.254.0.0/16 le 32 ip prefix-list upstream-in seq 920 deny 172.16.0.0/12 le 32 ip prefix-list upstream-in seq 925 deny 192.0.0.0/24 le 32 ip prefix-list upstream-in seq 930 deny 192.0.2.0/24 le 32 ip prefix-list upstream-in seq 935 deny 192.168.0.0/16 le 32 ip prefix-list upstream-in seq 945 deny 198.51.100.0/24 le 32 ip prefix-list upstream-in seq 950 deny 203.0.113.0/24 le 32 ip prefix-list upstream-in seq 955 deny 224.0.0.0/3 le 32 ip prefix-list upstream-in seq 990 deny 0.0.0.0/0 le 7 Similar for IPv6: ipv6 prefix-list upstream-in seq 900 deny 3ffe::/16 le 128 ipv6 prefix-list upstream-in seq 901 deny 2001:db8::/32 le 128 ipv6 prefix-list upstream-in seq 910 permit 2001::/32 ipv6 prefix-list upstream-in seq 911 deny 2001::/32 le 128 ipv6 prefix-list upstream-in seq 920 permit 2002::/16 ipv6 prefix-list upstream-in seq 921 deny 2002::/16 le 128 ipv6 prefix-list upstream-in seq 930 deny ::/8 le 128 ipv6 prefix-list upstream-in seq 940 deny fe00::/9 le 128 ipv6 prefix-list upstream-in seq 941 deny ff00::/8 le 128 -- Richard

Dec. 2, 2016

Re: Route Server Filtering

by Steve Howard

Dec. 2, 2016

Re: Route Server Filtering

by Doug McIntyre

On Fri, Dec 02, 2016 at 09:07:50AM -0600, Andrew Hoyos wrote: > - reject /25 - /32’s OOTH, filtering small prefixes would block dDoS blackholing. I know I've received dDoS traffic directed at me across the Exchange. (via HE, not really their fault). -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

Dec. 2, 2016

Re: Route Server Filtering

by Doug McIntyre

On Fri, Dec 02, 2016 at 08:59:05AM -0600, Steve Howard wrote: > I am curious what routes would be blocked if we ran that regex > against the existing route table in the servers? 31 route prefixes from one connection. They've already been contacted. Zero private ASNs. -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

Dec. 2, 2016

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