Route Server Filtering
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.pd... 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
On Thu, Dec 1, 2016 at 8:32 PM, Richard Laager <rlaager@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 ===============================================
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@iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades
On Dec 1, 2016, at 8:32 PM, Richard Laager <rlaager@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@gmail.com
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@iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades
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
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@arvig.com On Fri, Dec 2, 2016 at 11:11 AM, Richard Laager <rlaager@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
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@sdncommunications.com <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@sdncommunications.com <sdnsupport@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@LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Route Server Filtering On Dec 1, 2016, at 8:32 PM, Richard Laager <rlaager@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@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.***
participants (7)
-
Andrew Hoyos -
Ben Wiechman -
David Farmer -
Doug McIntyre -
Gary Glissendorf -
Richard Laager -
Steve Howard