Filtering Best Practices, et al (Was Verio Peering, Gordon's Knot)
Not to beat an already-decaying horse, BUT... I'm currently in the process of setting up a new border router, and the recent debate on the above topic got me wondering what the best practice filtering policy is? Is there one? And what do people put in place in terms of anti-spoofing ACLs and such? There's a wealth of information on these topics, but no real consensus. Or am I just reopening an ugly can of worms here? TIA, -- Grant A. Kirkwood - grant@virtical.net Chief Technology Officer - Virtical Solutions, Inc. http://www.virtical.net/
Recent versions of IOS support a cool feature: "ip verify unicast source reachable-via any" which can be installed on interfaces. This will silently drop (assuming you're using cef) packets sourced from prefixes that you do not have a route for. ie: if you don't have 10/8 in your routing table, and someone sends you a packet sourced from 10.0.0.3 it will get dropped. that will drop all your rfc1918 space (with the obvious caveat of if you route it) at the edge or in the core easily. as for non-packet filters, i defer to the plethora of threads - jared On Tue, Oct 09, 2001 at 07:58:19AM -0700, Grant A. Kirkwood wrote:
Not to beat an already-decaying horse, BUT...
I'm currently in the process of setting up a new border router, and the recent debate on the above topic got me wondering what the best practice filtering policy is? Is there one?
And what do people put in place in terms of anti-spoofing ACLs and such? There's a wealth of information on these topics, but no real consensus.
Or am I just reopening an ugly can of worms here?
TIA,
-- Grant A. Kirkwood - grant@virtical.net Chief Technology Officer - Virtical Solutions, Inc. http://www.virtical.net/
-- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Date: Tue, 09 Oct 2001 07:58:19 -0700 From: Grant A. Kirkwood <grant@virtical.net>
I'm currently in the process of setting up a new border router, and the recent debate on the above topic got me wondering what the best practice filtering policy is? Is there one?
And what do people put in place in terms of anti-spoofing ACLs and such? There's a wealth of information on these topics, but no real consensus.
+ If you're running BGP, filter your as-paths and netblocks to avoid any unwanted redistribution. This is always a bad thing, and long as-paths don't necessarily rule out a path being taken; remember that local-pref overrides as-path length. If it's an edge router, you needn't worry too much about prefix length -- they're already filtered for you. + You want to prevent forged outbound packets. They have no valid[1] use, and forged packets make tracing DoS attacks a pain. [1] I recall hearing that some satellite downlink Web service required the ability to send packets from their netblock. However, you can selectively allow these, as you would you own netblock. + Disallow 10/8, 172.16/12, and 192.168/16 -- no need for them to go anywhere. Eddy --------------------------------------------------------------------------- Brotsman & Dreger, Inc. - EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --------------------------------------------------------------------------- Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist@brics.com>, or you are likely to be blocked.
Howdy, all.
And what do people put in place in terms of anti-spoofing ACLs and such? There's a wealth of information on these topics, but no real consensus.
Perhaps this well help: http://www.cymru.com/~robt/Docs/Articles/secure-bgp-template.html http://www.cymru.com/~robt/Docs/Articles/secure-ios-template.html I am ever on the quest for input, feedback, and suggestions, so please feel free to comment! Please send all feedback directly to me. Thanks, Rob. -- Rob Thomas http://www.cymru.com/~robt cmn_err(CE_PANIC, "Out of coffee...");
Has anybody else received one of these emails? I don't have an issue related to this, but I am concerned that this will drive up the costs of maintaining and improving my infrastructure. -bradly
Going forward, Cisco no longer recommends the use in our networking products of memory products sold by third parties. Cisco has therefore discontinued the "Approved Vendor List" we have maintained in the past. In the event your company contacts Cisco with a support issue, and Cisco determines that the support issue you have reported is one that arises from your company's use of a third party memory product, Cisco may, in its discretion, refuse to provide technical assistance to help resolve the issue you have identified, whether such assistance would be provided under a product warranty or under a support plan such as SmartNet.
Less than a week ago Cisco TAC recommended DRAM from the Approved Vendor List to me. I hope this is not true. -Paul At 06:16 AM 10/12/2001 -0500, you wrote:
Has anybody else received one of these emails? I don't have an issue related to this, but I am concerned that this will drive up the costs of maintaining and improving my infrastructure.
-bradly
Going forward, Cisco no longer recommends the use in our networking products of memory products sold by third parties. Cisco has therefore discontinued the "Approved Vendor List" we have maintained in the past. In the event your company contacts Cisco with a support issue, and Cisco determines that the support issue you have reported is one that arises from your company's use of a third party memory product, Cisco may, in its discretion, refuse to provide technical assistance to help resolve the issue you have identified, whether such assistance would be provided under a product warranty or under a support plan such as SmartNet.
Bradly, Can you forward me a copy of that email and I'll verify it for everyone? Thanks, rodney On Fri, Oct 12, 2001 at 07:27:45AM -0400, Paul Timmins wrote:
Less than a week ago Cisco TAC recommended DRAM from the Approved Vendor List to me. I hope this is not true. -Paul
At 06:16 AM 10/12/2001 -0500, you wrote:
Has anybody else received one of these emails? I don't have an issue related to this, but I am concerned that this will drive up the costs of maintaining and improving my infrastructure.
-bradly
Going forward, Cisco no longer recommends the use in our networking products of memory products sold by third parties. Cisco has therefore discontinued the "Approved Vendor List" we have maintained in the past. In the event your company contacts Cisco with a support issue, and Cisco determines that the support issue you have reported is one that arises from your company's use of a third party memory product, Cisco may, in its discretion, refuse to provide technical assistance to help resolve the issue you have identified, whether such assistance would be provided under a product warranty or under a support plan such as SmartNet.
On Tue, 9 Oct 2001, Grant A. Kirkwood wrote:
I'm currently in the process of setting up a new border router, and the recent debate on the above topic got me wondering what the best practice filtering policy is? Is there one?
I don't think so. If you want to filter to keep your routing table small, filtering out all /24s is the way to go. These are 60% of the routing table. Even in class A and B space 40% of the announcements is individual /24s. Most people that announce a /24 are also reachable over an aggregate so you wouldn't break too much connectivity. If you want to filter against bad aggregation, you should look at class A and B space and 192/8, there is a lot of that going on there, but usually on "valid" prefix lengths such as /20 in A and /16 in B. So if you want to filter those routes you'll have to do it on AS number, and you break connectivity. But you can refuse to peer with ASes that don't aggregate without having a good reason. (And if there is one for what's going on in 24/8, I'd like to know.)
And what do people put in place in terms of anti-spoofing ACLs and such? There's a wealth of information on these topics, but no real consensus.
Depends on your paranoia level. You should always refuse incoming packets with local source addresses. Outgoing packets with non-local source addresses are bad, and incoming ICMP redirects aren't good either. You should probably have filters that implement all of this at your border routers, disable source routing and directed broadcasts (on every interface of every router!) and route 10/8, 127/8, 172.16/12 and 192.168/16 to the null interface. That should be enough for most people. Others like to filter more aggressively, for instance all non-allocated address blocks and things like the official test network 192.0.2.0. Iljitsch van Beijnum
On Tue, Oct 09, 2001 at 07:58:19AM -0700, Grant A. Kirkwood <grant@virtical.net> wrote a message of 18 lines which said:
I'm currently in the process of setting up a new border router, and the recent debate on the above topic got me wondering what the best practice filtering policy is? Is there one?
I'm interested to see if people filter route anouncements on the basis of registered routes in an Internet Routing Registry. In our area (Europe), the RIPE database typically contains less than half of the routes which are actually announced. I assume it is not better in ARINland. On the basis of inetnum objects (network addresses, not routes), it is a bit better in coverage but you cannot use inetnum directly in a comparison, you have to check that a BGP announce *includes* at least one registered inetnum. To summary, I dropped the idea. Does anyone implemented it?
On Wed, Oct 10, 2001 at 10:54:03AM +0200, Stephane Bortzmeyer wrote:
I'm currently in the process of setting up a new border router, and the recent debate on the above topic got me wondering what the best practice filtering policy is? Is there one?
I'm interested to see if people filter route anouncements on the basis of registered routes in an Internet Routing Registry. In our area (Europe), the RIPE database typically contains less than half of the routes which are actually announced. I assume it is not better in ARINland.
When I worked at Tiscali (World Online) Denmark, we did prefix filtering on our peers, the results of that can be seen on http://as8807.net/dixirrstats.txt (Though that is old, january this year) I believe that TeleDanmark also still do IRR filtering, and I know of several providers in Denmark who are ready to follow suit as soon as some of the "worst IRR-offenders" have updated their IRR records (which actually has happened already) If you decide to implement IRR filtering you may want to see how your peers perform in the IRR area by using a small utility, which can be downloaded from http://noc.tele.dk/util.html. This is the utility that was used to produce the stats for Tiscali's router. -- Andreas Plesner Jacobsen
participants (10)
-
Andreas Plesner Jacobsen -
E.B. Dreger -
Grant A. Kirkwood -
Iljitsch van Beijnum -
Jared Mauch -
Paul Timmins -
Rob Thomas -
Rodney Dunn -
Stephane Bortzmeyer -
Walters