RE: Is it time to abandon bogon prefix filters?
On Sun, 24 Aug 2008, Tomas L. Byrnes wrote: You're missing one of the basic issues with bogon sources: they are often advertised bogons, IE the bad guy DOES care about getting the packets back, and has, in fact, created a way to do so. This is usually VERY BAD traffic, and EVEN WORSE if a user goes TO a site hosted in such IP space. So, Bogon filtering has value beyond mere spoofed source rejection. Unmanaged (or semi-managed) routers probably should not be running BGP or other exterior routing protocols. Unmanaged routers with BGP provide more opportunities to create havoc and mischief.
RE: Is it time to abandon bogon prefix filters?
You're missing one of the basic issues with bogon sources: they are often advertised bogons, IE the bad guy DOES care about getting the packets back, and has, in fact, created a way to do so. This is usually VERY BAD traffic, and EVEN WORSE if a user goes TO a site hosted in such IP space. So, Bogon filtering has value beyond mere spoofed source rejection. -Original Message- From: Sean Donelan [mailto:[EMAIL PROTECTED] Sent: Thursday, August 21, 2008 5:19 PM To: NANOG list Subject: Re: Is it time to abandon bogon prefix filters? On Mon, 18 Aug 2008, Danny McPherson wrote: All the interesting attacks today that employ spoofing (and the majority of the less-interesting ones that employ spoofing) are usually relying on existence of the source as part of the attack vector (e.g., DNS cache poisoning, BGP TCP RST attacks, DNS reflective amplification attacks, etc..), and as a result, loose mode gives folks a false sense of protection/action. Yep. Same thing with bogon filters. Any attacker which can source packets with bogon addresses, can by definition, source packets with any valid IP address too. Great as an academic exercise, but the bad guys are going to send evil packets without the evil bit nor using bogon addresses. If the bad guys are using spoofed addresses, they don't care about the reply packets to either valid or unallocated addresses. However, seeing packets with unallocated IP addresses on the Internet is evidence of a broken network. Just like when a network trips max prefix on a BGP session, shouldn't a broken network be shutdown until the problem is fixed. If you don't want to risk your network peers turning off the connections, make sure your network doesn't source spoofed packets.
Re: Is it time to abandon bogon prefix filters?
On Sun, 24 Aug 2008 23:21:23 PDT, Tomas L. Byrnes said: You're missing one of the basic issues with bogon sources: they are often advertised bogons, IE the bad guy DOES care about getting the packets back, and has, in fact, created a way to do so. But if you've seen a BGP announcement with a prefix that covers the source, is it really a bogon anymore? At that point, you're not worrying about bogon filtering, you're worrying about sanity-checking what BGP advertisements you accept. Also a worthy thing to do, but different from bogon filtering. pgpmV7FPm2FYR.pgp Description: PGP signature
Re: Is it time to abandon bogon prefix filters?
[EMAIL PROTECTED] wrote: On Sun, 24 Aug 2008 23:21:23 PDT, Tomas L. Byrnes said: You're missing one of the basic issues with bogon sources: they are often advertised bogons, IE the bad guy DOES care about getting the packets back, and has, in fact, created a way to do so. But if you've seen a BGP announcement with a prefix that covers the source, is it really a bogon anymore? IIRC bogon is specific to unallocated space. Whether it be advertised or not should not matter. Regards, Chris
Re: Is it time to abandon bogon prefix filters?
On Thu, Aug 21, 2008 at 08:03:19PM -0400, Sean Donelan wrote: On Tue, 19 Aug 2008, Kevin Loch wrote: While you're at it, you also placed the reachable-via rx on all your customer interfaces. If you're paranoid, start with the 'any' rpf and then move to the strict rpf. The strict rpf also helps with routing loops. Be careful not to enable strict rpf on multihomed customers. This includes any bgp customer unless you know for sure they are single homed to you and that will not change. Isn't it time to change the assumption that sending arbitrary source IP addresses without checking is Ok? Unless the customer has specifically told their ISP about all the IP addresses they intend to use as source IP addresses, shouldn't the default be to drop those packets. If those multi-homed customers have not told their upstream ISPs about additional source IP addresses (hopefully also registered/authorized for use by the same customer) why can they still send packets with those source addresses? Instead shouldn't you say Be careful if you are a using source IP addresses without informing your upstream. In practice, how many multi-homed customers send packets with unannounced source IP addresses? And for those customers which do, why is the ISP unable to implement any of the alternative source IP checking options, such as using a ACL with uRPF or on the interface? I certainly believe that this is the trap people fall into. I can't manage it, nor do I want to spend the effort telling my provider, peer, etc.. that I stole their customer from them, so I'm better off making the global network less secure. With all the concern about DNS cache integrity, network abuse, etc.. networks that are not taking afirmative action to implement better policies, systems are going to continue to lower their overall value. If you think I'm wrong, I do suggest you sit back and ignore your network and customers further. When they are unable to trust your network to deliver the correct response to a dns query, they will ask for credits and will leave. If I were any sort of a bank, I would insist that my provider take actions to prevent my customers from being redirected to a phishing site. The interesting thing is the effort put into dns patching, dnssec, etc.. could all be helped by the networks doing u-rpf. Not 100% mitigated against, but the difference would be huge. this is no longer a ddos issue of people spoofing packets. That's gone, it's easier to take over a million desktops with malware than one on a fe/ge. But the ability to use those machines to brute-force or reconfigure the resolver settings to someplace bad, that risk is truly tangible and possibly severely disruptive to the industry. If I can't trust that I am reaching my bank, email, etc.. what impact will that have? If you've not factored these things into your business process, hardware acquisition, I think you will end up with a bad situation. - Jared -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: Is it time to abandon bogon prefix filters?
On Aug 25, 2008, at 10:22 AM, Jared Mauch wrote: On Thu, Aug 21, 2008 at 08:03:19PM -0400, Sean Donelan wrote: On Tue, 19 Aug 2008, Kevin Loch wrote: While you're at it, you also placed the reachable-via rx on all your customer interfaces. If you're paranoid, start with the 'any' rpf and then move to the strict rpf. The strict rpf also helps with routing loops. Be careful not to enable strict rpf on multihomed customers. This includes any bgp customer unless you know for sure they are single homed to you and that will not change. Isn't it time to change the assumption that sending arbitrary source IP addresses without checking is Ok? Unless the customer has specifically told their ISP about all the IP addresses they intend to use as source IP addresses, shouldn't the default be to drop those packets. If those multi-homed customers have not told their upstream ISPs about additional source IP addresses (hopefully also registered/ authorized for use by the same customer) why can they still send packets with those source addresses? Instead shouldn't you say Be careful if you are a using source IP addresses without informing your upstream. In practice, how many multi-homed customers send packets with unannounced source IP addresses? And for those customers which do, why is the ISP unable to implement any of the alternative source IP checking options, such as using a ACL with uRPF or on the interface? I certainly believe that this is the trap people fall into. I can't manage it, nor do I want to spend the effort telling my provider, peer, etc.. that I stole their customer from them, so I'm better off making the global network less secure. With all the concern about DNS cache integrity, network abuse, etc.. networks that are not taking afirmative action to implement better policies, systems are going to continue to lower their overall value. If you think I'm wrong, I do suggest you sit back and ignore your network and customers further. When they are unable to trust your network to deliver the correct response to a dns query, they will ask for credits and will leave. If I were any sort of a bank, I would insist that my provider take actions to prevent my customers from being redirected to a phishing site. The interesting thing is the effort put into dns patching, dnssec, etc.. could all be helped by the networks doing u-rpf. Not 100% mitigated against, but the difference would be huge. this is no longer a ddos issue of people spoofing packets. That's gone, it's easier to take over a million desktops with malware than one on a fe/ge. But the ability to use those machines to brute-force or reconfigure the resolver settings to someplace bad, that risk is truly tangible and possibly severely disruptive to the industry. If I can't trust that I am reaching my bank, email, etc.. what impact will that have? My Bank (Bank of America) put in something to mitigate against this about 2 years ago (IIRC), so they were clearly anticipating something like this. Not only do you have to verify that you are you, you also have to verify that the bank is the bank. Regards Marshall If you've not factored these things into your business process, hardware acquisition, I think you will end up with a bad situation. - Jared -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: Is it time to abandon bogon prefix filters?
On Mon, 25 Aug 2008 09:38:00 EDT, Chris Marlatt said: IIRC bogon is specific to unallocated space. Whether it be advertised or not should not matter. Right. Tell that to everybody who's ever been at the wrong end of a bogon filter for 69/8, 70/8, 71/8... I'll go out on a limb and say that if you see a BGP announcement for a prefix you think is a bogon, it's *more* likely that the space is no longer unallocated and you didn't get the memo, than it's still unallocated but being pirated by somebody. (Which raises a question - what % of sites that are doing bogon filtering but *not* listening to something like Team Cymru's bogon feed? If it's nearly ubiquitous, it's not a big problem. But given the number of places that have problems with bogon filters, only a small percentage seem to be doing so...) At the point that you're doing bogon filtering, you have no way to disambiguate those two cases. Which is why I said it's a BGP announcement filtering issue. pgpFceBGl2O1h.pgp Description: PGP signature
Re: Is it time to abandon bogon prefix filters?
In article [EMAIL PROTECTED] you write: On Aug 25, 2008, at 10:22 AM, Jared Mauch wrote: On Thu, Aug 21, 2008 at 08:03:19PM -0400, Sean Donelan wrote: With all the concern about DNS cache integrity, network abuse, etc.. networks that are not taking afirmative action to implement better policies, systems are going to continue to lower their overall value. If you think I'm wrong, I do suggest you sit back and ignore your network and customers further. When they are unable to trust your network to deliver the correct response to a dns query, they will ask for credits and will leave. If I were any sort of a bank, I would insist that my provider take actions to prevent my customers from being redirected to a phishing site. The interesting thing is the effort put into dns patching, dnssec, etc.. could all be helped by the networks doing u-rpf. Not 100% mitigated against, but the difference would be huge. this is no longer a ddos issue of people spoofing packets. That's gone, it's easier to take over a million desktops with malware than one on a fe/ge. But the ability to use those machines to brute-force or reconfigure the resolver settings to someplace bad, that risk is truly tangible and possibly severely disruptive to the industry. If I can't trust that I am reaching my bank, email, etc.. what impact will that have? My Bank (Bank of America) put in something to mitigate against this about 2 years ago (IIRC), so they were clearly anticipating something like this. Not only do you have to verify that you are you, you also have to verify that the bank is the bank. Regards Marshall While some people with some protocols have solutions to detect when the communication path has been compromised. Not all people with all protocols have a solution to this problem. There is no panecea to this problem, however *everyone* should do their best to reduce the problem. Any operator not implemting BCP 38 is potentially aiding and abetting some criminal. BCP 38 is over 10 years old. There is no excuse for not having equipment in place to handle the processing needs of BCP 38. Mark If you've not factored these things into your business process, hardware acquisition, I think you will end up with a bad situation. - Jared
Re: Is it time to abandon bogon prefix filters?
On Aug 20, 2008, at 7:00 AM, Kevin Loch wrote: It doesn't look like the feasible paths rpf handles the situation where your bgp customer is not announcing all or any of their prefixes to you. This can be done for TE or debugging an inbound routing issue. Announcing prefixes to me and then blackholing the traffic is not something I would appreciate as a customer. If you do this (or strict rpf) on BGP customers at least warn them up front that if they ever stop announcing prefixes to you then traffic they send you will get dropped. Clueful BGP admins know how to send their routes with no-advertise on them. There are fairly good reasons to require your direct customers always advertise their routes to you, even if you won't be readvertising them. uRPF is one. Not paying transit both inbound and out for multi- gig DoS attacks is my favorite. Etc. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: Is it time to abandon bogon prefix filters?
On Tue, 19 Aug 2008, Kevin Loch wrote: While you're at it, you also placed the reachable-via rx on all your customer interfaces. If you're paranoid, start with the 'any' rpf and then move to the strict rpf. The strict rpf also helps with routing loops. Be careful not to enable strict rpf on multihomed customers. This includes any bgp customer unless you know for sure they are single homed to you and that will not change. Isn't it time to change the assumption that sending arbitrary source IP addresses without checking is Ok? Unless the customer has specifically told their ISP about all the IP addresses they intend to use as source IP addresses, shouldn't the default be to drop those packets. If those multi-homed customers have not told their upstream ISPs about additional source IP addresses (hopefully also registered/authorized for use by the same customer) why can they still send packets with those source addresses? Instead shouldn't you say Be careful if you are a using source IP addresses without informing your upstream. In practice, how many multi-homed customers send packets with unannounced source IP addresses? And for those customers which do, why is the ISP unable to implement any of the alternative source IP checking options, such as using a ACL with uRPF or on the interface?
Re: Is it time to abandon bogon prefix filters?
On Mon, 18 Aug 2008, Danny McPherson wrote: All the interesting attacks today that employ spoofing (and the majority of the less-interesting ones that employ spoofing) are usually relying on existence of the source as part of the attack vector (e.g., DNS cache poisoning, BGP TCP RST attacks, DNS reflective amplification attacks, etc..), and as a result, loose mode gives folks a false sense of protection/action. Yep. Same thing with bogon filters. Any attacker which can source packets with bogon addresses, can by definition, source packets with any valid IP address too. Great as an academic exercise, but the bad guys are going to send evil packets without the evil bit nor using bogon addresses. If the bad guys are using spoofed addresses, they don't care about the reply packets to either valid or unallocated addresses. However, seeing packets with unallocated IP addresses on the Internet is evidence of a broken network. Just like when a network trips max prefix on a BGP session, shouldn't a broken network be shutdown until the problem is fixed. If you don't want to risk your network peers turning off the connections, make sure your network doesn't source spoofed packets.
Re: Is it time to abandon bogon prefix filters?
Pekka Savola wrote: On Tue, 19 Aug 2008, Kevin Loch wrote: While you're at it, you also placed the reachable-via rx on all your customer interfaces. If you're paranoid, start with the 'any' rpf and then move to the strict rpf. The strict rpf also helps with routing loops. Be careful not to enable strict rpf on multihomed customers. This includes any bgp customer unless you know for sure they are single homed to you and that will not change. Strict uRPF (feasible paths variant, RFC3704) works just fine with multihomed customers here. But we don't allow TE more specifics either from the customer or from peers, so the longest prefix matching doesn't get messed up. And with certain kind of p2p link numbering, you may need to add a dummy static route. But it works. It doesn't look like the feasible paths rpf handles the situation where your bgp customer is not announcing all or any of their prefixes to you. This can be done for TE or debugging an inbound routing issue. Announcing prefixes to me and then blackholing the traffic is not something I would appreciate as a customer. If you do this (or strict rpf) on BGP customers at least warn them up front that if they ever stop announcing prefixes to you then traffic they send you will get dropped. - Kevin
Re: Is it time to abandon bogon prefix filters?
Jared Mauch wrote: While you're at it, you also placed the reachable-via rx on all your customer interfaces. If you're paranoid, start with the 'any' rpf and then move to the strict rpf. The strict rpf also helps with routing loops. Be careful not to enable strict rpf on multihomed customers. This includes any bgp customer unless you know for sure they are single homed to you and that will not change. - Kevin
Re: Is it time to abandon bogon prefix filters?
On Tue, 19 Aug 2008, Kevin Loch wrote: While you're at it, you also placed the reachable-via rx on all your customer interfaces. If you're paranoid, start with the 'any' rpf and then move to the strict rpf. The strict rpf also helps with routing loops. Be careful not to enable strict rpf on multihomed customers. This includes any bgp customer unless you know for sure they are single homed to you and that will not change. Strict uRPF (feasible paths variant, RFC3704) works just fine with multihomed customers here. But we don't allow TE more specifics either from the customer or from peers, so the longest prefix matching doesn't get messed up. And with certain kind of p2p link numbering, you may need to add a dummy static route. But it works. For more see especially Section 3 of: http://tools.ietf.org/id/draft-savola-bcp84-urpf-experiences-03.txt (comments are also welcome.) -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
RE: Is it time to abandon bogon prefix filters?
for my own use, i use m4, python and perl, and peval() m4 is a macro processor that you probably should not bother learning since you can do everything that it does by using Python and regular expressions, or one of the Python parsing modules. For instance PLY supports conditional lexing and start conditions which you need to change parsing rules depending on which config section you are in. There is also a package called ciscoconfparse which I don't know much about http://ciscoconfparse.wiki.sourceforge.net/ peval() is part of the IRRToolSet which can be found here: http://www.isc.org/index.pl?/sw/IRRToolSet/ --Michael Dillon
RE: Is it time to abandon bogon prefix filters?
(Without an offline configuration generator, I postulate that it can't be done.) Doesn't everyone use an offline config generator these days? After all, there is a lot more CPU power and database capacity outside of the routers than there is inside. --Michael Dillon
Re: Is it time to abandon bogon prefix filters?
On Mon, Aug 18, 2008 at 09:51:20AM +0100, [EMAIL PROTECTED] wrote: m4 is a macro processor that you probably should not bother learning since you can do everything that it does by using Python Oh, Abley is gonna have fun with this... and for the record, my money is on Joe. He could probably implement python *IN* m4 if you offered enough beer! --Jeff
Re: Is it time to abandon bogon prefix filters?
On Sun, Aug 17, 2008 at 07:57:25PM -0500, Pete Templin wrote: Tomas L. Byrnes wrote: Since there are ways to dynamically filter the bogons, using BGP or DNS, I don't really see the need to stop doing so. If you're managing your routing and firewall filters manually, you have bigger problems than the release of Bogon space. Can you share the Cisco configuration snippet you recommend to dynamically FILTER bogons using BGP or DNS? On a router with full routes (ie: no default) the command is: Router(config-if)#ip verify unicast source reachable-via any Go ahead and try it out. you can view the resulting drop counter via the 'show ip int x/y' command. While you're at it, you also placed the reachable-via rx on all your customer interfaces. If you're paranoid, start with the 'any' rpf and then move to the strict rpf. The strict rpf also helps with routing loops. - Jared -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: Is it time to abandon bogon prefix filters?
Jared Mauch wrote: On a router with full routes (ie: no default) the command is: Router(config-if)#ip verify unicast source reachable-via any None of these suggestions (including the wisecrack ACLs) provide full filtering: If a miscreant originates a route in bogon space, their transit provider(s) doesn't filter their customers, and you or your peer/transit doesn't filter their peers/transits, your router will accept the route in bogon space and will accept the bogon packets. Filtering has not been accomplished, and the bogon attack vector remains open. Rather than hoping that everyone filters their customers or that all of my transits filter every peer, if I want to protect my network from bogon packets, I need to ensure that my routers won't accept any prefixes in bogon space. The Team Cymru BGP feed does NOT provide this function; it merely provides a way to inject null routes for bogon aggregates. And no, I don't have offline configuration generators. We don't have the coding experience in-house. Oh well. pt
Re: Is it time to abandon bogon prefix filters?
On 19/08/2008, at 2:01 AM, Sam Stickland wrote: I think you misunderstand the meaning of the ip verify unicasr source reachable-via any command. When a packet arrives the router will drop it if it doesn't have a valid return path for the source. Since the source is a bogon, and routed to Null0, then the inbound packet is dropped. If you read his post, I think you'll find that he understands perfectly. He is talking about both packet filtering, and prefix filtering. Scenario (exactly what Pete describes, but a bit more verbose): - We have bogon filtering using the method you describe. It works great, because we don't have any routes for things that are in bogon space, so we drop those packets on the floor. - Attacker has a BGP session with a carrier that, for whatever reason, doesn't filter their customer's announcements. Attacker advertises a longer prefix in bogon space than we have null routed, and that advertisement makes it on to the the wider network. - Because we now have an advertisement, we're going to accept packets sourced from that prefix. BGP triggered bogon filtering is no longer working for us, for that particular prefix. The question is, is this scenario really that likely, and if it is, is it going to happen often enough for it to be a problem? I would say that with the decrease in attackers using false source IPv4 addresses (because they all have big bot nets with throwaway nodes, so why bother hiding where those nodes are?), then this sort of attack loses value. Then again, not everyone who does these attacks thinks them through, so who knows? It's also obviously very easy to trace the source of these announcements, however that doesn't necessarily find the guilty party, in the case of a hacked router for example. I agree that bogon filtering with a Team Cymru BGP feed is good - it will do the job most of the time. However, it cannot be considered a complete solution. -- Nathan Ward
Re: Is it time to abandon bogon prefix filters?
Once upon a time, Sam Stickland [EMAIL PROTECTED] said: I think you misunderstand the meaning of the ip verify unicasr source reachable-via any command. When a packet arrives the router will drop it if it doesn't have a valid return path for the source. Since the source is a bogon, and routed to Null0, then the inbound packet is dropped. First, that is only true on Cisco routers (all the world is not a Cisco). Second, you are missing the point: you have bogon route for 10/8, but rouge route for 10.1/16 (or even 10.0/9 and 10.128/9) arrives; it is more specific and your automatic bogon filter is useless. -- Chris Adams [EMAIL PROTECTED] Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: Is it time to abandon bogon prefix filters?
Message: 3 Date: Mon, 18 Aug 2008 08:21:38 -0500 From: Pete Templin [EMAIL PROTECTED] Subject: Re: Is it time to abandon bogon prefix filters? None of these suggestions (including the wisecrack ACLs) provide full filtering: If a miscreant originates a route in bogon space, their transit provider(s) doesn't filter their customers, and you or your peer/transit doesn't filter their peers/transits, your router will accept the route in bogon space and will accept the bogon packets. Filtering has not been accomplished, and the bogon attack vector remains open. We recently expanded our network, separating our multi-homed transit network from our corporate and 'network services' LANs. We use BGP sessions between our transit and services networks to trade internal (RFC1918) routes as well as supply a default route. We do not trade external routes over these news sessions. A happy side-effect of this is that our black-hole router, with a cymru bogon feed, now populates the corporate routing table, rather than our full transit table, and by using strict URPF all bogon traffic gets dropped (inbound), and no more-specific routes learned by the transit routers will override our BH routes. - Eric AS17103
RE: Is it time to abandon bogon prefix filters?
If all you're using is BGP null routes, that's true. I would posit that BCP include Prefix filtering and ACLs as well, with dynamic updates. YMMV. -Original Message- From: Chris Adams [mailto:[EMAIL PROTECTED] Sent: Monday, August 18, 2008 7:30 AM To: NANOG list Subject: Re: Is it time to abandon bogon prefix filters? Once upon a time, Sam Stickland [EMAIL PROTECTED] said: I think you misunderstand the meaning of the ip verify unicasr source reachable-via any command. When a packet arrives the router will drop it if it doesn't have a valid return path for the source. Since the source is a bogon, and routed to Null0, then the inbound packet is dropped. First, that is only true on Cisco routers (all the world is not a Cisco). Second, you are missing the point: you have bogon route for 10/8, but rouge route for 10.1/16 (or even 10.0/9 and 10.128/9) arrives; it is more specific and your automatic bogon filter is useless. -- Chris Adams [EMAIL PROTECTED] Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: Is it time to abandon bogon prefix filters?
On Aug 18, 2008, at 6:33 AM, Jared Mauch wrote: On a router with full routes (ie: no default) the command is: Router(config-if)#ip verify unicast source reachable-via any Go ahead and try it out. you can view the resulting drop counter via the 'show ip int x/y' command. While you're at it, you also placed the reachable-via rx on all your customer interfaces. If you're paranoid, start with the 'any' rpf and then move to the strict rpf. The strict rpf also helps with routing loops. That's a good point. My problem with loose mode RPF is that it subjects a packet's source address to ANY FIB entry existence only mitigates spoofing of non-routed ranges. All the interesting attacks today that employ spoofing (and the majority of the less-interesting ones that employ spoofing) are usually relying on existence of the source as part of the attack vector (e.g., DNS cache poisoning, BGP TCP RST attacks, DNS reflective amplification attacks, etc..), and as a result, loose mode gives folks a false sense of protection/action. -danny
RE: Is it time to abandon bogon prefix filters?
Since there are ways to dynamically filter the bogons, using BGP or DNS, I don't really see the need to stop doing so. If you're managing your routing and firewall filters manually, you have bigger problems than the release of Bogon space. It's not just the number of attacks that is the issue, but the potential severity of them. Traffic sourced from Bogon space (REAL Bogon space) is 100% guaranteed to be traffic you DON'T want to receive. It could be advertised bogon space, in which case it is likely criminal, and thus something you REALLY don't want to see. Prioritization of defense effort is based on a product of probability and severity divided by a factor that takes the cost and unfavorable consequences of the mitigation strategy into account. For any given threat, you can choose methods that decrease or increase any factor, and address those with the highest payoff first. An example would be Thermonuclear attack: low probability, very high severity, with fairly significant cost and unpleasant side consequences, yet the result, total annihilation, is so high that we have ICBMs, Submarines, Bombers, and ABM technology, which taken together cost a lot more than the efforts spent on blocking SPAM, which is very probable, but unlikely to kill anyone. Applying Bogon filters, using dynamic sources, is a very low cost way to block attacks that can be of high severity, while unlikely to have adverse consequences, and so is a BCP. Filtering RFC1918 space at the edge has always been a BCP, independent of Bogon filters. You neither want to accept if from outside, or let any of yours leak. That should be part of the static filter set/null route table in any router. -Original Message- From: Robert E. Seastrom [mailto:[EMAIL PROTECTED] Sent: Friday, August 15, 2008 5:23 AM To: Randy Bush Cc: NANOG list Subject: Re: Is it time to abandon bogon prefix filters? Randy Bush [EMAIL PROTECTED] writes: bogon block attacks % of attacks 0.0.0.0/7 65 0.01 2.0.0.0/8 3 0.00 5.0.0.0/8 3 0.00 10.0.0.0/8 87941.21 23.0.0.0/8 4 0.00 27.0.0.0/8 7 0.00 92.0.0.0/6 101 0.01 100.0.0.0/6 374 0.05 104.0.0.0/5 303 0.04 112.0.0.0/5 775 0.11 120.0.0.0/8 45 0.01 127.0.0.0/8 6 0.00 172.16.0.0/12 36460.50 174.0.0.0/7 1 0.00 176.0.0.0/5 1 0.00 192.168.0.0/16 74511.02 223.0.0.0/8 10 0.00 224.0.0.0/3 8 0.00 well, we can see why andree wanted to look behind the 1918 stuff. it is the elephant. thanks, danny! randy In other words, our earlier estimate of 60% was way off... you can get 92.1% effectiveness at bogon filtering by just dropping 1918 addresses, a filter that you will never have to change. What's the operational cost trade-off with going after that remaining 7.9%? I'll betcha it's not justifiable. Maybe it's time to change the best current practices we recommend so that they stop biting us in the ass every time a chunk of our ever-dwindling pool of unused address space goes into play. My uncle used to tell this joke: Q: Why did the man hit himself in the head with a hammer? A: Because it felt so good when he stopped? -r
RE: Is it time to abandon bogon prefix filters?
In the case of routers and firewalls, managing your block lists dynamically is akin to checking the oil. Which is something too few car owners do as well. It's also relatively easy to do: shameless plug For firewalls, I came up with ThreatSTOP to make this simple for everyone. /shameless plug Team Cymru has been doing this for routers forever. -Original Message- From: Sean Donelan [mailto:[EMAIL PROTECTED] Sent: Friday, August 15, 2008 10:07 AM To: Steven M. Bellovin Cc: NANOG list Subject: Re: Is it time to abandon bogon prefix filters? On Fri, 15 Aug 2008, Steven M. Bellovin wrote: and i am saying that you should use a router configuration *system* that avoids ticking time bombs. no router should be neglected and unloved. That, I think, is why he distinguished between routers run by highly clueful people and routers run by others. I think we all agree on your basic point; it's just that too many people aren't clueful enough to realize that they even have a problem, let alone know how to solve it. (Of course, you and I both have a background in programming languages and compilers, which is why we naturally think of router configurations as a form of assembler language that only a compiler should every emit.) To avoid people feeling individually insulted, I sometimes try to distinguish between the purposes of equipment rather than the capabilities of the person maintaining it. A NASCAR racing team may perform extensive monitoring and maintenance on their racing cars; but that doesn't mean I should need a team of 5 mechanics to keep my regular street car operating safely with a few idiot lights on the dashboard.
Re: Is it time to abandon bogon prefix filters?
i contend that all one's routers should be rigorously configured as programmatically as possible. What sort of tools do you use to facilitate this? ntt/verio, level(3), ... have sophisticated locally developed systems. they see these as competitive advantage, so sharing is extremely unlikely. and, as they are home grown, they likely do not have a portable layer of indirection to corporate back-end data. some large telcos seem proud that the network is the database of record and are proud of it. i wish all my competitors thought that. for my own use, i use m4, python and perl, and peval() randy
Re: Is it time to abandon bogon prefix filters?
Randy Bush [EMAIL PROTECTED] writes: bogon block attacks % of attacks 0.0.0.0/7 65 0.01 2.0.0.0/8 3 0.00 5.0.0.0/8 3 0.00 10.0.0.0/8 87941.21 23.0.0.0/8 4 0.00 27.0.0.0/8 7 0.00 92.0.0.0/6 101 0.01 100.0.0.0/6 374 0.05 104.0.0.0/5 303 0.04 112.0.0.0/5 775 0.11 120.0.0.0/8 45 0.01 127.0.0.0/8 6 0.00 172.16.0.0/12 36460.50 174.0.0.0/7 1 0.00 176.0.0.0/5 1 0.00 192.168.0.0/16 74511.02 223.0.0.0/8 10 0.00 224.0.0.0/3 8 0.00 well, we can see why andree wanted to look behind the 1918 stuff. it is the elephant. thanks, danny! randy In other words, our earlier estimate of 60% was way off... you can get 92.1% effectiveness at bogon filtering by just dropping 1918 addresses, a filter that you will never have to change. What's the operational cost trade-off with going after that remaining 7.9%? I'll betcha it's not justifiable. Maybe it's time to change the best current practices we recommend so that they stop biting us in the ass every time a chunk of our ever-dwindling pool of unused address space goes into play. My uncle used to tell this joke: Q: Why did the man hit himself in the head with a hammer? A: Because it felt so good when he stopped? -r
Re: Is it time to abandon bogon prefix filters?
In other words, our earlier estimate of 60% was way off... you can get 92.1% effectiveness at bogon filtering by just dropping 1918 addresses, a filter that you will never have to change. my read is that the 60% was an alleged 60% of attacks came from *all* bogon space. this now seems in the low single digit percentge. of that, the majority is from 1918 space. randy
Re: Is it time to abandon bogon prefix filters?
On Aug 15, 2008, at 9:26 AM, Randy Bush wrote: In other words, our earlier estimate of 60% was way off... you can get 92.1% effectiveness at bogon filtering by just dropping 1918 addresses, a filter that you will never have to change. my read is that the 60% was an alleged 60% of attacks came from *all* bogon space. this now seems in the low single digit percentge. of that, the majority is from 1918 space. If (trying to reverse engineer this thread) previously 60% of all attacks came from bogonspace, and now only 2.96% do, that does not mean that if the bogon filters are removed, that number will stay at 3 %. It may just mean that the filtering is effective. Regards Marshall randy
Re: Is it time to abandon bogon prefix filters?
Randy Bush [EMAIL PROTECTED] writes: In other words, our earlier estimate of 60% was way off... you can get 92.1% effectiveness at bogon filtering by just dropping 1918 addresses, a filter that you will never have to change. my read is that the 60% was an alleged 60% of attacks came from *all* bogon space. this now seems in the low single digit percentge. of that, the majority is from 1918 space. so is there any case to be made for filtering bogons on upstream/peering ingress at all anymore? (this discussion is orthogonal to bcp38/urpf, which i think we all agree is a good thing and would be great if we could get it further deployed) ---rob
Re: Is it time to abandon bogon prefix filters?
In other words, our earlier estimate of 60% was way off... you can get 92.1% effectiveness at bogon filtering by just dropping 1918 addresses, a filter that you will never have to change. my read is that the 60% was an alleged 60% of attacks came from *all* bogon space. this now seems in the low single digit percentge. of that, the majority is from 1918 space. so is there any case to be made for filtering bogons on upstream/peering ingress at all anymore? maybe low percent is because it is effective. maybe not --- man walks into shrink's office waving open newspaper wildly. shrink asks why are you waving the newspaper? man replies, it keeps the elephants away. shrink says, elephants? there aren't any elephants for hundreds of kilometers. man replies, pretty effective, isn't it! --- personal guess: i suspect that at least rfc1918 filters are worthwhile if only because we make mistakes. randy
Re: Is it time to abandon bogon prefix filters?
On Fri, 15 Aug 2008, Robert E. Seastrom wrote: so is there any case to be made for filtering bogons on upstream/peering ingress at all anymore? Depends on where and how. On highly managed routers at highly managed interconnection points around the Internet, having some basic packet hygiene checks can serve as a fire breaks to keep the effectiveness of large scale attacks with reserved/unallocated address low. Unlike BCP38/uRPF/SAVI, it doesn't need 100% deployment; just enough to make it less attractive as an attack vector compared to other things. Even within a single provider, you might not deploy it everywhere. Maybe just between different continents or regions, depending on your hardware and operational capabilities. For highly managed routers, operational management of allocation updates is more limited because you only need to keep track of IANA changes (or use some of Team Cymru's tools) rather than figure out which peer or customer is authorized to use unallocated source addresses. Again, I think bogon filters are a bad idea for unmanaged or semi-managed routers (or inclusion as a default in anything, i.e. Cisco's auto-secure). (this discussion is orthogonal to bcp38/urpf, which i think we all agree is a good thing and would be great if we could get it further deployed) I agree.
Re: Is it time to abandon bogon prefix filters?
On Fri, 15 Aug 2008 09:49:38 -0400 (EDT) Sean Donelan [EMAIL PROTECTED] wrote: On Fri, 15 Aug 2008, Randy Bush wrote: my read is that the 60% was an alleged 60% of attacks came from *all* bogon space. this now seems in the low single digit percentge. of that, the majority is from 1918 space. Although I've disagreed with Rob about the configuration of bogon filters, especially on unmanaged (or semi-managed) routers, it is important to remember attacks and bogus packets are not naturally occuring phenomenon. The attacker chooses the attack vector and target, usually based on effectiveness and vulnerability but often on ease for the attacker. Packet and especially source address hygiene can be very useful for highly managed equipement. However, bogon filters have often become more a source of recurring security consultant maintenance revenue than effective packet controls. Understanding the operational maintenance demands is also an important part of implementing good security controls. For unmanaged and semi-managed routers, I'd suggest strict out-bound packet controls (i.e. be conservative in what you send) because you already need to make operational updates when they change. But consider using inbound controls that require less extensive recurring maintenance, e.g. only filtering martians (i.e. 0/8, 127/8, 255.255.255.255/32, etc) instead of updating bogons (i.e. changing reserved and unallocated) every few months. Martians plus 1918 space, I'd say, though that requires knowing which are border interfaces. Other than that, I agree 100% -- bogon filters have little security relevance for most sites. Furthermore, as the allocated address space increases, the percentage of actual bogon space decreases and the rate of false positives -- packets that are rejected that shouldn't be -- will increase. Security? Remember that availability is a security issue, too. --Steve Bellovin, http://www.cs.columbia.edu/~smb
Re: Is it time to abandon bogon prefix filters?
On Fri, 15 Aug 2008, Steven M. Bellovin wrote: Martians plus 1918 space, I'd say, though that requires knowing which are border interfaces. Whether you include or exclude rfc1918 addresses is another issue. Whack the martians first :-) Unfortunately, enough ISPs use rfc1918 addresses on their backbone links filtering rfc1918 also breaks traceroute (* * *) and people use rfc1918 internally enough that rfc1918 requires more professional thought about configuring those filters. From an operational perspective, whacking martians has fewer caveats for amateur network operators or default equipment configuration settings. Other than that, I agree 100% -- bogon filters have little security relevance for most sites. Furthermore, as the allocated address space increases, the percentage of actual bogon space decreases and the rate of false positives -- packets that are rejected that shouldn't be -- will increase. Security? Remember that availability is a security issue, too. Violent agreement.
Re: Is it time to abandon bogon prefix filters?
Sean Donelan [EMAIL PROTECTED] writes: For unmanaged and semi-managed routers, I'd suggest strict out-bound packet controls (i.e. be conservative in what you send) because you already need to make operational updates when they change. But consider using inbound controls that require less extensive recurring maintenance, e.g. only filtering martians (i.e. 0/8, 127/8, 255.255.255.255/32, etc) instead of updating bogons (i.e. changing reserved and unallocated) every few months. I think we're in violent agreement here. -r
Re: Is it time to abandon bogon prefix filters?
Sean Donelan [EMAIL PROTECTED] writes: On Fri, 15 Aug 2008, Robert E. Seastrom wrote: so is there any case to be made for filtering bogons on upstream/peering ingress at all anymore? Depends on where and how. On highly managed routers at highly managed interconnection points around the Internet, having some basic packet hygiene checks can serve as a fire breaks to keep the effectiveness of large scale attacks with reserved/unallocated address low. ... Again, I think bogon filters are a bad idea for unmanaged or semi-managed routers (or inclusion as a default in anything, i.e. Cisco's auto-secure). You make a very good point about the difference between routers that are being routinely maintained by highly clueful people and routers that are in the field and untouched/unloved for months to years at a time. The latter is the situation that I was thinking of when I was talking about the operational hit from the overzealous bogon filters. Problem is, when we post BCPs they tend to assume a flat application space (which is a bad plan) or people tend to assume that they are more clueful or the routers will be better maintained than they actually will be (the airport diamond security lane for expert travelers problem). ---Rob
Re: Is it time to abandon bogon prefix filters?
Again, I think bogon filters are a bad idea for unmanaged or semi-managed routers (or inclusion as a default in anything, i.e. Cisco's auto-secure). You make a very good point about the difference between routers that are being routinely maintained by highly clueful people and routers that are in the field and untouched/unloved for months to years at a time. in the field != untouched/unloved i contend that all one's routers should be rigorously configured as programmatically as possible. randy
Re: Is it time to abandon bogon prefix filters?
as a mutual friend who pretends he does not read nanog emailed privately rfc1918 filters, like bcp38 filters, could be construed as topological assertions rather than bogon filters per se. certainly they are for edge routers, but even in the dfz, i don't think we're in rfc 1918 space anymore, toto. randy
Re: Is it time to abandon bogon prefix filters?
Randy Bush wrote: in the field != untouched/unloved i contend that all one's routers should be rigorously configured as programmatically as possible. It seems to me that those are the routers where the filtering of both packets and routes is easiest and most effective. If every such router (which almost be definition knows what source addresses and routes are legitimate) filtered out all the crap, there would not be much crap getting to the DFZ. Too hard. I don't think so. When I administered a /16 with only a hundred or so such routers, a simple skeleton config-file-base allowed quick construction of a config file at installation--which was then rarely touched ever again. (We did log at a central location and used SNMP monitors for supervison.) -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actioInfallibility, and the ability to learn from their mistakes. Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs
Re: Is it time to abandon bogon prefix filters?
Steven M. Bellovin [EMAIL PROTECTED] writes: Security? Remember that availability is a security issue, too. It never ceases to amaze me how many security people walk around oblivious to this basic notion. -r
Re: Is it time to abandon bogon prefix filters?
Robert E. Seastrom wrote: Steven M. Bellovin [EMAIL PROTECTED] writes: Security? Remember that availability is a security issue, too. It never ceases to amaze me how many security people walk around oblivious to this basic notion. But of course! The most secure object is one nobody knows about and can't get to anyway. That is the whole point!
Re: Is it time to abandon bogon prefix filters?
Randy Bush [EMAIL PROTECTED] writes: Again, I think bogon filters are a bad idea for unmanaged or semi-managed routers (or inclusion as a default in anything, i.e. Cisco's auto-secure). You make a very good point about the difference between routers that are being routinely maintained by highly clueful people and routers that are in the field and untouched/unloved for months to years at a time. in the field != untouched/unloved That's why I used the conjunction and. i contend that all one's routers should be rigorously configured as programmatically as possible. Not sure what you mean by this, but the painful reality is that most stuff, once deployed, gets promptly forgotten about, much the same as you might ignore a wall wart power supply under your desk until it started smelling funny or stopped delivering electricity. Thus, I contend that one's routers should be configured to avoid ticking time bombs. As smb so eloquently just asserted, availability is a security issue too. -r
Re: Is it time to abandon bogon prefix filters?
Not sure what you mean by this, but the painful reality is that most stuff, once deployed, gets promptly forgotten about, much the same as you might ignore a wall wart power supply under your desk until it started smelling funny or stopped delivering electricity. Thus, I contend that one's routers should be configured to avoid ticking time bombs. and i am saying that you should use a router configuration *system* that avoids ticking time bombs. no router should be neglected and unloved. randy
Re: Is it time to abandon bogon prefix filters?
Randy Bush [EMAIL PROTECTED] writes: Not sure what you mean by this, but the painful reality is that most stuff, once deployed, gets promptly forgotten about, much the same as you might ignore a wall wart power supply under your desk until it started smelling funny or stopped delivering electricity. Thus, I contend that one's routers should be configured to avoid ticking time bombs. and i am saying that you should use a router configuration *system* that avoids ticking time bombs. no router should be neglected and unloved. I agree 100%, I'm just acknowledging reality and suggesting that we should not promulgate practices which don't take into account the skew between best-implementation-and-followthrough and oversight-by-PHB. -r
Re: Is it time to abandon bogon prefix filters?
On Fri, 15 Aug 2008 08:56:27 -0700 Randy Bush [EMAIL PROTECTED] wrote: Not sure what you mean by this, but the painful reality is that most stuff, once deployed, gets promptly forgotten about, much the same as you might ignore a wall wart power supply under your desk until it started smelling funny or stopped delivering electricity. Thus, I contend that one's routers should be configured to avoid ticking time bombs. and i am saying that you should use a router configuration *system* that avoids ticking time bombs. no router should be neglected and unloved. That, I think, is why he distinguished between routers run by highly clueful people and routers run by others. I think we all agree on your basic point; it's just that too many people aren't clueful enough to realize that they even have a problem, let alone know how to solve it. (Of course, you and I both have a background in programming languages and compilers, which is why we naturally think of router configurations as a form of assembler language that only a compiler should every emit.) --Steve Bellovin, http://www.cs.columbia.edu/~smb
Re: Is it time to abandon bogon prefix filters?
On Fri, 15 Aug 2008, Steven M. Bellovin wrote: and i am saying that you should use a router configuration *system* that avoids ticking time bombs. no router should be neglected and unloved. That, I think, is why he distinguished between routers run by highly clueful people and routers run by others. I think we all agree on your basic point; it's just that too many people aren't clueful enough to realize that they even have a problem, let alone know how to solve it. (Of course, you and I both have a background in programming languages and compilers, which is why we naturally think of router configurations as a form of assembler language that only a compiler should every emit.) To avoid people feeling individually insulted, I sometimes try to distinguish between the purposes of equipment rather than the capabilities of the person maintaining it. A NASCAR racing team may perform extensive monitoring and maintenance on their racing cars; but that doesn't mean I should need a team of 5 mechanics to keep my regular street car operating safely with a few idiot lights on the dashboard.
Re: Is it time to abandon bogon prefix filters?
Hi Randy, .-- My secret spy satellite informs me that at Thu, 07 Aug 2008, Randy Bush wrote: serious curiosity: what is the proportion of bad stuff coming from unallocated space vs allocated space? real measurements, please. and are there longitudinal data on this? are the uw folk, gatech, vern, ... measuring? I did some measurements in The Netherlands (SURFnet) using netflow around 1,5 years ago. During this project around 86 million 'Bogon flows' were analyzed. This was not more then 0.1% (probably even lower) of all flows during that 1 week period. The majority of these flows were actually from/to RFC1918 address space. One of the things (amongst others) we looked at was SMTP traffic from / to bogons, to verify the theory that spammers announce a bogon prefix to sent spam. From the 86 million bogon flows analyzed, 12 SMTP flows were found, very minimal. Other things we looked at, were type of traffic (applications) protocols and the sources of those flows. We saw some strange (interesting) things, but that was really just a few flows in many many many milions of flows. Anyways, if you're interested the research report can be found here: http://www.toonk.nl/bogon-traffic-analysis.pdf There's also a presentation http://www.toonk.nl/presentations.php Cheers, Andree -- Andree Toonk http://www.toonk.ca/blog/
Re: Is it time to abandon bogon prefix filters?
On Aug 6, 2008, at 9:01 AM, Randy Bush wrote: serious curiosity: what is the proportion of bad stuff coming from unallocated space vs allocated space? real measurements, please. and are there longitudinal data on this? are the uw folk, gatech, vern, ... measuring? Some data from our anonymous stats program (currently ~90 ISPs) included below. In short, ~3% of 727k attacks we've seen over the last 631 days employed bogon source addresses. (definition of what constitutes attack is subjected to reporting participant operational policy, but these are primarily rate-based DDoS attacks) -danny --- General Statistics total_days 631 total_attacks 1137265 avg_attacks_day 1802 avg_collectors_day 47 avg_attacks_collector_day 38 total_good_attacks 727410 63.96% --- Bogon Summary bogon block attacks % of attacks 0.0.0.0/7 65 0.01 2.0.0.0/8 3 0.00 5.0.0.0/8 3 0.00 10.0.0.0/8 87941.21 23.0.0.0/8 4 0.00 27.0.0.0/8 7 0.00 92.0.0.0/6 101 0.01 100.0.0.0/6 374 0.05 104.0.0.0/5 303 0.04 112.0.0.0/5 775 0.11 120.0.0.0/8 45 0.01 127.0.0.0/8 6 0.00 172.16.0.0/12 36460.50 174.0.0.0/7 1 0.00 176.0.0.0/5 1 0.00 192.168.0.0/16 74511.02 223.0.0.0/8 10 0.00 224.0.0.0/3 8 0.00 bogonTotal 21597 2.97
Re: Is it time to abandon bogon prefix filters?
bogon block attacks % of attacks 0.0.0.0/7 65 0.01 2.0.0.0/8 3 0.00 5.0.0.0/8 3 0.00 10.0.0.0/8 87941.21 23.0.0.0/8 4 0.00 27.0.0.0/8 7 0.00 92.0.0.0/6 101 0.01 100.0.0.0/6 374 0.05 104.0.0.0/5 303 0.04 112.0.0.0/5 775 0.11 120.0.0.0/8 45 0.01 127.0.0.0/8 6 0.00 172.16.0.0/12 36460.50 174.0.0.0/7 1 0.00 176.0.0.0/5 1 0.00 192.168.0.0/16 74511.02 223.0.0.0/8 10 0.00 224.0.0.0/3 8 0.00 well, we can see why andree wanted to look behind the 1918 stuff. it is the elephant. thanks, danny! randy
Re: Is it time to abandon bogon prefix filters?
On Aug 6, 2008, at 12:01 PM, Sean Donelan wrote: Attacks or misconfigured leaks? Leaks of RFC1918 stuff is pretty common, just ask any of the root server operators how many packets they see from RFC1918 leaking networks or do a traceroute across several residential cable network backbones. Attacks aren't as common because there is enough (not 100%) anti- spoofing (good) and/or bogon-filters (not as good) in different parts of the Internet it requires more thought to launch a spoofed DDOS than it does just to use tens of thousands of non-spoofed bots to launch a DDOS. Arbor Networks has some data. I shared some data on bogon source appearances in *observed* attacks in another email. Orthogonal of that, here's the current Infrastructure Security Survey (again: see below for participation information, if so inclined) totals for questions related to BCP 38 and uRPF application among respondents. A pointer to a complete set of data across ~70 ISPs from last years survey is provided below. (Note: it's my opinion that one should assume at least a slightly more clue-dense respondent base than the larger network operator pool - i.e., the actual BCP 38/uRPF numbers are likely lower, and you're more clueful if you complete the survey :-) -danny - Self-classified respondent network type (approaching 50 responses): Tier 1: 13.33% Tier 2: 28.89% Pure Content Network: 11.11% Hosting Provider: 8.89% Education or Academic Network: 13.33% Enterprise or Hybrid Network: 2.22% Other: 22.22% --- Do you employ strict uRPF or BCP 38 on the dedicated customer edge of your network? Yes: 51.11% No: 33.33% Other: 15.56% --- Do you employ strict uRPF or BCP 38 style filters on the broadband edge of your network? Yes: 40.00% No: 33.33% Other: 26.67% --- Do you employ uRPF or BCP 38 style filters on the peering edge of your network? Yes: 46.67% No: 46.67% Other: 6.67% [snip] Folks, The 2008 Infrastructure Security Survey is up and available for input. You can register to complete the survey at this URL: https://www.tcb.net/survey/index.php?sid=19672lang=en I've added many questions this time from past participants of the survey, this should be evidenced throughout. Thanks to all those that reviewed and provided questions explicitly for this edition. The survey response window will be ~2 weeks. We hope to make the results available by the end of September at the latest. Also, please recall that NO personally (or organizationally) identifiable information will be shared in any manner. The 2007 edition of the survey is available here: http://www.tcb.net/wisp07.pdf Or on the Arbor web site (reg required): http://www.arbornetworks.com/report Thanks in advance for your participation! -danny
Re: Is it time to abandon bogon prefix filters?
Patrick W. Gilmore wrote: Filter your bogons. But do it in an automated fashion, from a trusted source. Of course, I recommend Team Cymru, which has a most sterling record. Nearly perfect (other than the fact they still recommend MD5 on BGP sessions :). How can you recommend Team Cymru, when their product is not in any way a filter? It is merely an automated method of injecting aggregate null routes for bogons, but in no way prevents a network from accepting aggregate or specific bogon announcements (i.e. it does not _filter_). pt
Re: Is it time to abandon bogon prefix filters?
On Aug 7, 2008, at 2:04 PM, Pete Templin wrote: Patrick W. Gilmore wrote: Filter your bogons. But do it in an automated fashion, from a trusted source. Of course, I recommend Team Cymru, which has a most sterling record. Nearly perfect (other than the fact they still recommend MD5 on BGP sessions :). How can you recommend Team Cymru, when their product is not in any way a filter? It is merely an automated method of injecting aggregate null routes for bogons, but in no way prevents a network from accepting aggregate or specific bogon announcements (i.e. it does not _filter_). HUH? Team Cymru offers many ways to set up filters, null routes, etc. See http://www.team-cymru.org/Services/Bogons/ . Oh, and to answer Randy's question about how much actually comes from bogons, on that same page: quote How much does it help to filter the bogons? In one study conducted by Rob Thomas of a frequently attacked site, fully 60% of the naughty packets were obvious bogons (e.g. 127.1.2.3, 0.5.4.3, etc.). A presentation based on that study, entitled 60 Days of Basic Naughtiness, can be viewed here. Your mileage may vary, and you may opt to filter more conservatively or more liberally. As always, you must KNOW YOUR NETWORK to understand the effects of such filtering. /quote I guess that means filtering bogons is useful. -- TTFN, patrick
Re: Is it time to abandon bogon prefix filters?
Patrick W. Gilmore [EMAIL PROTECTED] writes: How much does it help to filter the bogons? In one study conducted by Rob Thomas of a frequently attacked site, fully 60% of the naughty packets were obvious bogons (e.g. 127.1.2.3, 0.5.4.3, etc.) Stated another way, you can get 60% success on bogon filtering by ignoring the free pool (which is getting smaller over time which indicates the value in filtering it is asymptotic to zero) and only filtering obvious crud, whose definition is not going to change over time. In other words, Leo is right, and I'd submit that we're past the point where putting in non-auto-updated filters for the free pool has a value that exceeds the operational cost of dealing with their lossage... by a couple of years. -r
Re: Is it time to abandon bogon prefix filters?
How much does it help to filter the bogons? In one study conducted by Rob Thomas of a frequently attacked site, fully 60% of the naughty packets were obvious bogons (e.g. 127.1.2.3, 0.5.4.3, etc.) Stated another way, you can get 60% success on bogon filtering by ignoring the free pool if 127.1.2.3 and 0.5.4.3 are in the free pool, we have a few more /8s in the bank then we thought, eh? :) btw, patrick neglected the last sentences of that paragraph, which made me wonder what rob would actually say. luckily, in response to my post, rob replied that he/they would try to get some useful measures in the near term. i am patient. but your post makes me inclined to beg that he/that he have a few taxa within the bogon space. randy
Re: Is it time to abandon bogon prefix filters?
Randy Bush [EMAIL PROTECTED] writes: How much does it help to filter the bogons? In one study conducted by Rob Thomas of a frequently attacked site, fully 60% of the naughty packets were obvious bogons (e.g. 127.1.2.3, 0.5.4.3, etc.) Stated another way, you can get 60% success on bogon filtering by ignoring the free pool if 127.1.2.3 and 0.5.4.3 are in the free pool, we have a few more /8s in the bank then we thought, eh? :) I guess I didn't really word that clearly. My point was that by not including the free pool in your candidates for filtering (i.e., only filtering out packets from addresses that will never be allocated or are permanently reserved such as 1918 space), you're only sacrificing 40% of your likely hits... and that number is going down over time. Why not just cut to the chase and make a filter that will never go stale, take any possible lumps on the bogus packet announcement side, and collect handsomely on the operational side? btw, patrick neglected the last sentences of that paragraph, which made me wonder what rob would actually say. luckily, in response to my post, rob replied that he/they would try to get some useful measures in the near term. i am patient. I read that thrice and thought wtf? twice, until I properly dereferenced rob to robt, not rs. Heh. but your post makes me inclined to beg that he/that he have a few taxa within the bogon space. Come, come, elucidate your thoughts. -r
Re: Is it time to abandon bogon prefix filters?
Hi, NANOG (he says with a shout)! btw, patrick neglected the last sentences of that paragraph, which made me wonder what rob would actually say. luckily, in response to my post, rob replied that he/they would try to get some useful measures in the near term. i am patient. Yep yep, have some results at last. Sorry, the queries took a bit longer than planned. Note that the study I conducted which populated the 60 Days of Basic Naughtiness presentation is now years old. Such studies, like me, don't necessarily age well. :) This is not meant to replace a more comprehensive and clueful study by the likes of Vern, Stefan, and the CAIDA crew. As folks may know we have a large Darknet[1] project. In there we collect the scanning activity of malware, backscatter, and the like. Often we can tie the scanning pattern to a family of malware or maltool. If the source of a scan or probe is a bogon, we tag it that way in our data store. I went back to 2008-01 and found the following percentages of bogons in our data: 2008-01: 0.001095262% 2008-02: 0.001759343% 2008-03: 0.001619555% 2008-04: 0.001433908% 2008-05: 0.001182351% 2008-06: 0.130534559% 2008-07: 0.002327683% 2008-08: 0.001258054% (thus far) That's not a lot of bogon activity in the Darknets, though Darknets are only one measure of malevolent traffic. Your mileage may vary, etc. [1] http://www.team-cymru.org/Services/darknets.html Thanks, Rob. -- Rob Thomas Team Cymru http://www.team-cymru.org/ cmn_err(CEO_PANIC, Out of coffee!);
Re: Is it time to abandon bogon prefix filters?
[Just a correction because Randy attributed something to me that I didn't do.] On Aug 7, 2008, at 4:14 PM, Randy Bush wrote: btw, patrick neglected the last sentences of that paragraph, which made me wonder what rob would actually say. luckily, in response to my post, rob replied that he/they would try to get some useful measures in the near term. i am patient. _patrick_ did not cut anything from that paragraph. Check the archives, the whole paragraph is in my post. Rob Seastrom cut patrick's quote off when he replied. -- TTFN, patrick
Re: Is it time to abandon bogon prefix filters?
On Aug 7, 2008, at 5:35 PM, Robert E. Seastrom wrote: Randy Bush [EMAIL PROTECTED] writes: How much does it help to filter the bogons? In one study conducted by Rob Thomas of a frequently attacked site, fully 60% of the naughty packets were obvious bogons (e.g. 127.1.2.3, 0.5.4.3, etc.) Stated another way, you can get 60% success on bogon filtering by ignoring the free pool if 127.1.2.3 and 0.5.4.3 are in the free pool, we have a few more / 8s in the bank then we thought, eh? :) I guess I didn't really word that clearly. My point was that by not including the free pool in your candidates for filtering (i.e., only filtering out packets from addresses that will never be allocated or are permanently reserved such as 1918 space), you're only sacrificing 40% of your likely hits... and that number is going down over time. Why not just cut to the chase and make a filter that will never go stale, take any possible lumps on the bogus packet announcement side, and collect handsomely on the operational side? I guess I parsed that differently than you did. When he said fully 60% of the naughty packets were obvious bogons, I read that as meaning 60% of all bad packets (bogon-sourced or otherwise) were from bogon space. If my interpretation is correct, you cannot tell anything about which % was from permanently bad space vs. unallocated space. Rob T., could you clarify for us please? Also, filtering bogons has the same utility / dangers of MD5. Many people think MD5 is a good thing, even though the amount of downtime caused by it is (at least) several orders of magnitude larger than the amount of downtime caused by successful RST attacks. I think the danger outweighs the benefit. If you are arguing the same thing here, that's fine with me. But let's find out what the danger is and make the decision. Oh, and then everyone should take their own advice and de-configure MD5. :-) -- TTFN, patrick
Re: Is it time to abandon bogon prefix filters?
I guess I parsed that differently than you did. When he said fully 60% of the naughty packets were obvious bogons, I read that as meaning 60% of all bad packets (bogon-sourced or otherwise) were from bogon space. That's correct. -- Rob Thomas Team Cymru http://www.team-cymru.org/ cmn_err(CEO_PANIC, Out of coffee!);
Re: Is it time to abandon bogon prefix filters?
rob, If the source of a scan or probe is a bogon, we tag it that way in our data store. I went back to 2008-01 and found the following percentages of bogons in our data: 2008-01: 0.001095262% 2008-02: 0.001759343% 2008-03: 0.001619555% 2008-04: 0.001433908% 2008-05: 0.001182351% 2008-06: 0.130534559% 2008-07: 0.002327683% 2008-08: 0.001258054% (thus far) this is an extremely far cry from 60%. what am i not understanding? and can you separate reserved (127, ...) and unallocated? randy
Re: Is it time to abandon bogon prefix filters?
* [EMAIL PROTECTED] (Randy Bush) [Fri 08 Aug 2008, 00:59 CEST]: rob, If the source of a scan or probe is a bogon, we tag it that way in our data store. I went back to 2008-01 and found the following percentages of bogons in our data: [..] 2008-08: 0.001258054% (thus far) this is an extremely far cry from 60%. what am i not understanding? and can you separate reserved (127, ...) and unallocated? This is scanning of darknets - usually you're interested in what comes back, i.e. can you 0wn it? so src has to be valid. (D)DoS of course are much more likely to come closer to the 60% number. No need to get the SYN+ACKs or the ICMP echo replies back... -- Niels.
Re: Is it time to abandon bogon prefix filters?
Hey, Randy. this is an extremely far cry from 60%. what am i not understanding? There are a few factors at work here. One, the 60% figure was from 2001-03-16. There were more bogons then, and our sundry measures saw a lot more malevolence from bogon space. A popular belief in the underground in 2001 was that spoofing in general, and the use of bogon space specifically, added a layer of protection for their collections of compromised hosts. In the age of masses of compromised routers, servers, and workstations, that's no longer a necessary defensive measure. At circa US $.04 each, bots are easily replaced. Compromised routers don't cost much more than that. Two, we really can't compare the two (time issues aside). The 60% figure came from a study of a frequently (as in daily) attacked web site. The figures I shared today came from our Darknets, which are more global and not limited to a certain type of service or site owner. Third, that site has been split into multiple sites (after about 2005) so unfortunately I can't easily reproduce the study from 2001. That is a real bummer. So I'm not comparing apples and apples. We also track DDoS attacks, malware propagation, and other Internet malevolence. As a shot from the hip, I'll say we see very little abuse from bogon IP space. I won't say we see no abuse from bogon space, however, so we keep bogons automatically filtered on our border. I like to keep the online criminal toolkit as sparse as I can. :) and can you separate reserved (127, ...) and unallocated? I can indeed, though it'll take me a bit to do so. Again, stay tuned. Thanks, Rob. -- Rob Thomas Team Cymru http://www.team-cymru.org/ cmn_err(CEO_PANIC, Out of coffee!);
Re: Is it time to abandon bogon prefix filters?
This is scanning of darknets - usually you're interested in what comes back, i.e. can you 0wn it? so src has to be valid. Yep yep. -- Rob Thomas Team Cymru http://www.team-cymru.org/ cmn_err(CEO_PANIC, Out of coffee!);
Is it time to abandon bogon prefix filters?
Bogon filters made a lot of sense when most of the Internet was bogons. Back when 5% of the IP space was allocated blocking the other 95% was an extremely useful endevour. However, by the same logic as we get to 80-90% used, blocking the 20-10% unused is reaching diminishing returns; and at the same time the rate in which new blocks are allocated continues to increase causing more and more frequent updates. Have bogon filters outlived their use? Is it time to recommend people go to a simpler bogon filter (e.g. no 1918, Class D, Class E) that doesn't need to be updated as frequently? -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpC6GPSPZlqX.pgp Description: PGP signature
RE: Is it time to abandon bogon prefix filters?
Yes. 1918 (10/8, 172.16/12, 192.168/16), D, E, reflective (outgoing mirroring), and as always individual discretion. --Patrick Darden -Original Message- From: Leo Bicknell [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 06, 2008 9:10 AM To: nanog@nanog.org Subject: Is it time to abandon bogon prefix filters? Bogon filters made a lot of sense when most of the Internet was bogons. Back when 5% of the IP space was allocated blocking the other 95% was an extremely useful endevour. However, by the same logic as we get to 80-90% used, blocking the 20-10% unused is reaching diminishing returns; and at the same time the rate in which new blocks are allocated continues to increase causing more and more frequent updates. Have bogon filters outlived their use? Is it time to recommend people go to a simpler bogon filter (e.g. no 1918, Class D, Class E) that doesn't need to be updated as frequently? -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
Re: Is it time to abandon bogon prefix filters?
This makes sense especially for static filters. Automated feeds, such as the bogon route-server or DNS zones, leaves folks with options. -- Rob Thomas Team Cymru http://www.team-cymru.org/ cmn_err(CEO_PANIC, Out of coffee!);
Re: Is it time to abandon bogon prefix filters?
On Aug 6, 2008, at 10:28 AM, Rob Thomas wrote: This makes sense especially for static filters. Automated feeds, such as the bogon route-server or DNS zones, leaves folks with options. Honestly, I don't believe the 80/20 rules applies here. Until all transit networks are willing to strictly filter their downstreams (and themselves!), if there is any unused space (note I said unused, not unallocated), the miscreants will use it. They are not going around saying oh, damn, there are only a few /8s left, we better stop!. Filter your bogons. But do it in an automated fashion, from a trusted source. Of course, I recommend Team Cymru, which has a most sterling record. Nearly perfect (other than the fact they still recommend MD5 on BGP sessions :). -- TTFN, patrick
Re: Is it time to abandon bogon prefix filters?
Until all transit networks are willing to strictly filter their downstreams (and themselves!), if there is any unused space (note I said unused, not unallocated), the miscreants will use it. serious curiosity: what is the proportion of bad stuff coming from unallocated space vs allocated space? real measurements, please. and are there longitudinal data on this? are the uw folk, gatech, vern, ... measuring? randy
Re: Is it time to abandon bogon prefix filters?
serious curiosity: what is the proportion of bad stuff coming from unallocated space vs allocated space? real measurements, please. and are there longitudinal data on this? Let me see what we can produce in the way of data. I'll just count 2008, though I could go back further if there's interest. Stay tuned, I should have some answers in a few hours. -- Rob Thomas Team Cymru http://www.team-cymru.org/ cmn_err(CEO_PANIC, Out of coffee!);
Re: Is it time to abandon bogon prefix filters?
Randy Bush wrote: serious curiosity: what is the proportion of bad stuff coming from unallocated space vs allocated space? real measurements, please. and are there longitudinal data on this? are the uw folk, gatech, vern, ... measuring? I still have 2 of my borders using an inbound ACL to filter BOGONs vs null routes. For the ACLs I've broken down the BOGONs to nothing larger than a /8. I see a number of hits on those entries, especially on 94/8. and 0/8. While some of the other hits are accidental I'm sure, I would seriously doubt if those 2 /8s are. Justin
Re: Is it time to abandon bogon prefix filters?
Leo Bicknell wrote: Have bogon filters outlived their use? Is it time to recommend people go to a simpler bogon filter (e.g. no 1918, Class D, Class E) that doesn't need to be updated as frequently? In my opinion no; BOGON filters are still very useful. Back when only 5% of the IP space was allocated we didn't have the same kinds of serious threats to our networks and our users that we have today. We didn't have spammers hijacking unallocated space (can if be considered hijacking when the block hasn't been allocated yet?) to mass mail our users, host phishing servers, run CC servers for botnets, etc. Today we do and the use of what few networks are still unallocated for bad purposes are prevalent. For my users I only recommend that they use dynamic methods of keeping up to date with changes in the BOGON list. While I still do much of my BOGON work manually, as I'm sure many of us do, I have my local BOGON lists updated within a few hours of learning of a new allocation (sometimes even before the bogon-announce email arrives). For those that aren't uber network geeks I recommend using something automated. Look at it this way: you have what's essentially a mostly static list of netblocks from which all traffic is unquestionably malicious. Wouldn't you block it if you could for the sake of your network security and that of your users? Justin
Re: Is it time to abandon bogon prefix filters?
I see a number of hits on those entries, especially on 94/8. and 0/8. You do know that 94/8 has been assigned to the RIPE NCC, right? :-) Cheers, Rob
Re: Is it time to abandon bogon prefix filters?
Leo Bicknell wrote: Have bogon filters outlived their use? Is it time to recommend people go to a simpler bogon filter (e.g. no 1918, Class D, Class E) that doesn't need to be updated as frequently? Seems like filtering against those could be done on the backplane, so to speak. One of the things that has always puzzled me is this: In the default-free zone, why is necessary to filter _against_ anybody? Seems like traffic for which there is no route would at most be dumped to an error-log someplace. For folks with a default route, I have long advocated (with no success what ever) filtering against stuff like the above, your own networks as sourced somewhere else, such. I also think a central blacklist a la spamhaus for networks makes sense. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actioInfallibility, and the ability to learn from their mistakes. Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs
Re: Is it time to abandon bogon prefix filters?
Rob Evans wrote: I see a number of hits on those entries, especially on 94/8. and 0/8. You do know that 94/8 has been assigned to the RIPE NCC, right? :-) I knew I should have logged into a production box to look at the ACL counters. But no, I thought the former border that I was already logged into was good enough. Apparently not! :-) I stopped updating it's BOGON list when it was decommissioned and retasked. I could have sworn that was just this past April and the only change since then was 112 and 113/8 which I accounted for mentally. Apparently it was longer ago than I thought! Justin
Re: Is it time to abandon bogon prefix filters?
On Aug 6, 2008, at 11:46 AM, Laurence F. Sheldon, Jr. wrote: Leo Bicknell wrote: Have bogon filters outlived their use? Is it time to recommend people go to a simpler bogon filter (e.g. no 1918, Class D, Class E) that doesn't need to be updated as frequently? Seems like filtering against those could be done on the backplane, so to speak. One of the things that has always puzzled me is this: In the default-free zone, why is necessary to filter _against_ anybody? Seems like traffic for which there is no route would at most be dumped to an error-log someplace. For folks with a default route, I have long advocated (with no success what ever) filtering against stuff like the above, your own networks as sourced somewhere else, such. I'm confused. Why does it matter if you are DF or not? If the packets are just coming in, there does not need to be a prefix in the table. If duplex communication is required (e.g. spam runs), a prefix need to be in the table whether you have a 0/0 or not. We know spammers have done runs by announcing a block (which gets it into the DFZ if it is not filtered properly), send spam, pull prefix. So again, why does it matter if you have a default route or not? I also think a central blacklist a la spamhaus for networks makes sense. See Team Cymru. -- TTFN, patrick
RE: Is it time to abandon bogon prefix filters?
Then again, it does make Team Cymru an attractive target for DoS or even compromise if they can control routing policy to a degree for a large number of disparate networks. Especially if it gets in the way of for-profit spammers. (Not trying to knock them, just providing a for consideration. I would certainly hope and expect that Team Cymru would do their due dilligance in that respect, but it seems like an attractive central point of failure to attack to me.) - S (Sent via dumb phone mail client, apologies for any formatting badness). -Original Message- From: Patrick W. Gilmore [EMAIL PROTECTED] Sent: Wednesday, August 06, 2008 11:59 To: NANOG list nanog@nanog.org Subject: Re: Is it time to abandon bogon prefix filters? On Aug 6, 2008, at 11:46 AM, Laurence F. Sheldon, Jr. wrote: Leo Bicknell wrote: Have bogon filters outlived their use? Is it time to recommend people go to a simpler bogon filter (e.g. no 1918, Class D, Class E) that doesn't need to be updated as frequently? Seems like filtering against those could be done on the backplane, so to speak. One of the things that has always puzzled me is this: In the default-free zone, why is necessary to filter _against_ anybody? Seems like traffic for which there is no route would at most be dumped to an error-log someplace. For folks with a default route, I have long advocated (with no success what ever) filtering against stuff like the above, your own networks as sourced somewhere else, such. I'm confused. Why does it matter if you are DF or not? If the packets are just coming in, there does not need to be a prefix in the table. If duplex communication is required (e.g. spam runs), a prefix need to be in the table whether you have a 0/0 or not. We know spammers have done runs by announcing a block (which gets it into the DFZ if it is not filtered properly), send spam, pull prefix. So again, why does it matter if you have a default route or not? I also think a central blacklist a la spamhaus for networks makes sense. See Team Cymru. -- TTFN, patrick
RE: Is it time to abandon bogon prefix filters?
1. DOS of Cymru (as noted below). 2. False Positives. Your network is suddenly stranded. Maybe on purpose. (DOS of a network, e.g. China or Youtube). 3. False Negatives. A bogus network is suddenly centrally rubber-stamped. Could happen. We've seen a lot of shenanigans with the domain registrars--similar issues could happen here. . . I guess I am just trying to say that a centralized trusted repository brings with it a chance for a single point of failure. Could be the pros outweigh the cons. There are issues with a de-centralized system as well (which is what brought this conversation about.) Nothing specific to Cymru. --Patrick Darden -Original Message- From: Skywing [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 06, 2008 1:25 PM To: Patrick W. Gilmore; NANOG list Subject: RE: Is it time to abandon bogon prefix filters? Then again, it does make Team Cymru an attractive target for DoS or even compromise if they can control routing policy to a degree for a large number of disparate networks. Especially if it gets in the way of for-profit spammers. (Not trying to knock them, just providing a for consideration. I would certainly hope and expect that Team Cymru would do their due dilligance in that respect, but it seems like an attractive central point of failure to attack to me.) - S
Re: Is it time to abandon bogon prefix filters?
On Thu, 7 Aug 2008, Randy Bush wrote: serious curiosity: what is the proportion of bad stuff coming from unallocated space vs allocated space? real measurements, please. and are there longitudinal data on this? are the uw folk, gatech, vern, ... measuring? Attacks or misconfigured leaks? Leaks of RFC1918 stuff is pretty common, just ask any of the root server operators how many packets they see from RFC1918 leaking networks or do a traceroute across several residential cable network backbones. Attacks aren't as common because there is enough (not 100%) anti-spoofing (good) and/or bogon-filters (not as good) in different parts of the Internet it requires more thought to launch a spoofed DDOS than it does just to use tens of thousands of non-spoofed bots to launch a DDOS. Arbor Networks has some data.
Re: Is it time to abandon bogon prefix filters?
Hi, Skywing. We've had a few DDoS attacks and lots of scans and hack attempts. Some of the DDoS attacks managed to wipe out our front-end. At no point were the route-servers impacted, since we keep them well away from our networks, widely distributed, and vigorously monitored (configs, responsiveness, advertisements). Of course we're not perfect and there is no 100% solution, but we understand the implications of filtering gone awry (especially since we use it ourselves), and spend a lot of time and code keeping an eye on these things. Knowing that no one has a monopoly on imagination, we also have some friends at commercial pen-testers hit us regularly, just to be sure. :) Thanks, Rob. -- Rob Thomas Team Cymru http://www.team-cymru.org/ cmn_err(CEO_PANIC, Out of coffee!);
Re: Is it time to abandon bogon prefix filters?
Skywing wrote: Then again, it does make Team Cymru an attractive target for DoS or even compromise if they can control routing policy to a degree for a large number of disparate networks. Especially if it gets in the way of for-profit spammers. (Not trying to knock them, just providing a for consideration. I would certainly hope and expect that Team Cymru would do their due dilligance in that respect, but it seems like an attractive central point of failure to attack to me.) Use a prefix list of existing bogons against the Team Cymru BGP feed. If they are hacked this limits the possible attacks to the following bounds: 1) They advertise no address space, and you end up with no bogon filtering. 2) They advertise all of the IPv4 address space, but your prefix list limits this to (an admittedly out-of-date) list of bogons. Sam
