Hi, Hank. ] I do as well, but does this scale? Can Team CYMRU handle 2,000 BGP ] sessions? 20K? 200K? -Hank We can handle quite a lot of sessions, and already do, thanks to the distributed nature of the Bogon route-server project. We have several routers deployed, and are prepared to deploy more if necessary. By the way we recommend that folks peer with at least two of the Bogon route-servers. Thanks, Rob. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);

On 5 Dec 2004, at 06:50, Cliff Albert wrote:

I have one question regarding the CYMRU bogon route-server. What good is it if more-specific bogons are going around in the BGP table ?

With OpenBSD 3.6 running pf and bgpd, you can apply a filter rule to BGP updates received from individual peers which updates a pf radix table with the network received: # team cymru bogon route servers group "bogons" { remote-as 65333 local-address A.B.C.D multihop 64 announce none max-prefix 1000 tcp md5sig password "xxsomethingxx" neighbor E.F.G.H neighbor I.J.K.L } # cymru set 65333:888 on bogon routes allow from any community 65333:888 set pftable "bogons" allow from any community 65333:888 set nexthop blackhole This allows you to block inbound/outbound packets in the packet filter, and not just rely on blackhole routing (I left the "nexthop blackhole" policy statement in there to provide some coverage in case I accidentally disable pf one day due to caffeine deficiency). The pf config bits are: table <bogons> persist # no bogon sources or destinations block quick from <bogons> to any block quick from any to <bogons> This seems to work very nicely, and neatly accommodates the problem of what to do with packets which follow more-specific routes of the cymru bogon supernets. The rules above would probably need to be loosened somewhat for a network which used 1918 addresses and NAT, since the 1918 addresses are included in the bogon feed. This is an answer that is probably not useful for the average ISP backbone, but I tried it out a week or so ago on my home network firewall/router boxes, and it works very nicely. It's a good solution for (say) an enterprise network whose external traffic falls within the bounds of what an OpenBSD box can handle (or boxes, if you do stateful failover with CARP and pfsync). Joe

Cliff Albert wrote:

On Sun, Dec 05, 2004 at 12:41:32PM -0500, Joe Abley wrote:

...

...

I have one question regarding the CYMRU bogon route-server. What good is it if more-specific bogons are going around in the BGP table ?

With OpenBSD 3.6 running pf and bgpd, you can apply a filter rule to BGP updates received from individual peers which updates a pf radix table with the network received:

Nice - anyone know of anything equivalent for ipf/pfil on Solaris?

Interesting, but no option on Juniper/IOS boxes/foundry boxen.

Since 12.0(29)S and 12.2(25)S, this feature: BGP Support for IP Prefix Import from Global Table into a VRF Table http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120... does the trick nicely, as long as you trust builds that new, and your linecards are new enough. Worked fine in my testing. This is effectively a way of populating a VRF and then pointing uRPF at it. I think it was aimed at feasible path uRPF, but can do the bogon stuff as well. -- Ian Dickinson Development Engineer PIPEX ian.dickinson@pipex.net http://www.pipex.net This e-mail is subject to: http://www.pipex.net/disclaimer.html

william(at)elan.net wrote:

On Sun, 5 Dec 2004, Joe Abley wrote:

...

On 5 Dec 2004, at 06:50, Cliff Albert wrote:

...

I have one question regarding the CYMRU bogon route-server. What good is it if more-specific bogons are going around in the BGP table ?

With OpenBSD 3.6 running pf and bgpd, you can apply a filter rule to BGP updates received from individual peers which updates a pf radix table with the network received:

PF and bgpd with local filter table is good when you're expecting those filtered ip routes to change often.

I dont understand this attitude. Automating everything that is safely automatable is the only right way to do things. Its always worth it and it is always good. Everyone has always professed to believe in this. In this case this is the exact cause of the problem the thread started addressing: Manual updates that dont keep up. Once upon a time this was the argument of sendmail access database V. dnsbls. Once upon a time you were expected to manually update virus definitions. Once upon a time you were expected to etc.. the list goes on. Every "weekly" task an admin takes on manually adds up. It may be great job insurance but it starts to suck quick for anyone with half a brain. Now to throw some whacky ideas out instead of opinions. I think that a BGP mechanism to tag routes as "ignore all more specifics" would solve this problem nicely. (and perhaps a whole lot others -- such as needless deaggregation) As far as router vendors such as Cisco autosecure, I do not think there is any way to make default access lists lossless. They should step up to the plate and offer md5 by system serial number keyed multihop BGP bogons in the manner of cymru. Its their responsibility. Also good that it makes them eat even more of their own dogfood which is probably ill suited to this kind of thing. They should ask team cymru to help them do it and give them a nice fat check while they are at it. Failing that they could offer radius/tacaccs loading of that access list. Anything else is negligence. And using BGP for /32 blacklist routes probably has very limited scalability. Any one have any relevant numbers? Everybody who posts lists of static access lists should seriously consider stopping. If not that, offer an email subscription to announce updates. (think I beat the S:N? --even if my S is nonsense?) Joe

Hi, NANOGers. ] - That's only some 40% of all address space, so you need to be able to ] deal with the other 60% anyway. Why wouldn't whatever mechanism that ] deals with the 60% be unable to deal with the additional 40%? In a study of one oft' scanned and attacked site, we found that 66.85% of the source IPs were bogon (RFC1918, unallocated, etc.). You can read about it at the following URL: <http://www.cymru.com/Presentations/60days.ppt> Filtering out bogons removes yet one more potential source of badness. Does it remove all badness? Of course not. We win by degrees. Removing any tool from the bad persons' toolkit is useful. Those who track backscatter (the detritus of a spoofed source attack) are still seeing a healthy bit of traffic. While spoofing is less popular than it once was, it still remains a viable attack feature. Tools such as bang.c depend entirely on the ability to spoof. Not all spoofing uses bogon IP space. That's fine, we can reduce the alternatives bit by bit. Dealing with the other sources of badness is an exercise for other ideas. The Darknet Project is one such way to spot that badness. <http://www.cymru.com/Darknet/> How you choose to respond to that badness (report it to the source, report it to their upstreams, null route them, do nothing) is of course up to you. ] - (Loose) uRPF will buy you the exact same functionality and more ] without any upkeep. Even with uRPF one needs to keep the RIB clean. That means the use of filtering. We and others provide those as well: <http://www.cymru.com/Documents/secure-bgp-template.html> <http://www.cymru.com/gillsr/documents/junos-bgp-template.htm> <ftp://ftp-eng.cisco.com/cons/isp/security/Ingress-Prefix-Filter-Templates/> Thanks, Rob. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);

On Sun, 5 Dec 2004, Jørgen Hovland wrote:

Blocking bogons will result in that attackers use existing netblocks instead. This will again result in more insecureness since any attack will

If the people making attack code would stay out of 224.0.0.0/4 space (both for dest and src) it would be a big improvement. -- Mikael Abrahamsson email: swmike@swm.pp.se

On 5-dec-04, at 20:03, Rob Thomas wrote:

] - That's only some 40% of all address space, so you need to be able to ] deal with the other 60% anyway. Why wouldn't whatever mechanism that ] deals with the 60% be unable to deal with the additional 40%?

In a study of one oft' scanned and attacked site, we found that 66.85% of the source IPs were bogon (RFC1918, unallocated, etc.).

Well, I didn't keep a running total, but I'd say that in the attacks that I've dealt with 80%+ used real addresses or something indistinguishable. I understand this is what most people see. So unless someone has data that indicates otherwise, I'll assume your experiences are an exception.

Filtering out bogons removes yet one more potential source of badness.

...while at the same time introducing a new one: the risk of filters going un-updated. (Generally speaking. For a BGP feed from you this isn't much of a risk.)

] - (Loose) uRPF will buy you the exact same functionality and more ] without any upkeep.

Even with uRPF one needs to keep the RIB clean.

Yes, but how do you do that without an authoritative prefix->AS mapping? (And good tools. I know there are some, but I find them too hard to work with.)

<http://www.cymru.com/Documents/secure-bgp-template.html>

Note though that so far, nobody has tried to inject bogon routes into the global routing table just so packets from bogon sources wouldn't be filtered. The reason we want this is because of address space hijacking (such as done by spammers) and configuration mistakes. So filtering at the /8 level as in the document linked above isn't really going to buy you much in practice.

On 5-dec-04, at 22:06, Cliff Albert wrote:

...

So filtering at the /8 level as in the document linked above isn't really going to buy you much in practice.

/8 le /32 still stands for /8 and more-specifics as I remember ? :)

You don't say... What will they come up with next?? My point is that if there is even a small part of a /8 in use, then the /8 isn't in the bogon list. For instance, 191.0.0.0/8 isn't there, although AFAIK this space isn't used, it's just that 191.255.0.0/16 is "reserved".

Secondly not everything is about security but also about keeping routing tables clean and useful, as more people noticed today.

If only we could...

Filtering bogons away is just an extra step in making sure that you transport real traffic instead of bogus traffic of which you are 100% sure that it's *useless* traffic. uRPF will fix it for your own network,

Right. So there is no need to use bogon lists.

but filtering bogon routes away in BGP will also make your downstream a happier place.

You are assuming that there are significant bogon routes in the routing table. I'm sure there is bad stuff in the global routing table from time to time that Rob's bogon list will catch, but I seriously doubt it's very much. Injecting bogon routes so you can get past uRPF doesn't make sense (except maybe for the first hop AS) and for any other (ab)use such as spamming selecting something that isn't as obvious is much more useful. (In any case, ISPs accepting bogon routes from their customers is completely unacceptable. Filtering routes from peers isn't always feasible, and even lack of source address filtering on ingress from customers can be excusable at times, but filtering BGP advertisements from customers is every ISP's sacred duty.)

The only argument from you I have seen against bogon filtering is the fact that the lists aren't updated by certain parties.

I've never felt that it's useful. So one argument against is more than sufficient. However, allow me to contradict myself by taking the position that it's better for us network operators to do bogon filtering so our customers don't have to, rather than have any fool with an ipfw or similar shoot himself in the foot. The preferred way to do this would be uRPF.

Hi, Sean. ] Unless you are a professional router driver, using Team Cymru's ] suggested router configuration will hurt most average users. Which is ] a problem because a lot of the Team Cymru recommendations are good ] router hygenie. But I can't in good faith recommend people use the Team ] Cymru, because of those dangerous inclusions. This is one of the reasons why we offer the list in a wide variety of colors and models. :) Take a peek at the RADb entries, which do differentiate based on type: <http://www.cymru.com/Bogons/index.html#radb> - fltr-unallocated - fltr-martian - fltr-bogons I hope this helps! We could also divide the list in our text and HTML offerings, and add separate communities for special use and unallocated. I'm always sorry to hear that folks can't use our projects, especially if they don't convey to us why. Suggestions are always welcome! Thanks, Rob. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);

On Dec 6, 2004, at 6:30 AM, Michael.Dillon@radianz.com wrote:

The point is that the bogon feed doesn't need to be hooked directly into your routers. This is what Patrick Gilmore does, i.e. he takes the bogon feed into a managenment system, generates an ACL and then periodically applies the ACL to his routers. Presumably that ACL gets checked by a clueful person before it goes out.

Just to be clear, I did not say that is what I did, or any organization I work for did. It was just a possible suggestion, not a requirement or a statement of fact. I'm just interested in cleaning up the cruft on the 'Net. Useless deaggregates, bogons, spoofed source, etc. You know, the things YOU can do with YOUR network and YOUR customers so _I_ do not have to deal with it. Given how much time and effort has been spent on things like "filtering on allocation boundaries" because some big networks do not want to take some /24s when little guys multi-home, you would think everyone would get behind this and push really hard. Just seems like a much bigger win with far fewer religious questions. But, of course, that wouldn't be nearly as fun. :) -- TTFN, patrick

On Sun, 5 Dec 2004, william(at)elan.net wrote:

On Sun, 5 Dec 2004, Joe Abley wrote:

...

On 5 Dec 2004, at 06:50, Cliff Albert wrote:

...

I have one question regarding the CYMRU bogon route-server. What good is it if more-specific bogons are going around in the BGP table ?

With OpenBSD 3.6 running pf and bgpd, you can apply a filter rule to BGP updates received from individual peers which updates a pf radix table with the network received:

PF and bgpd with local filter table is good when you're expecting those filtered ip routes to change often. But this is not true about bogons

Ok, I guess I did not read original post closely enough. PF is for reinjecting routes that match local rules back into bgp, right? If so I apologize, I though it was talking about taking bgp data and using it to filter local servers.... For looking at active routes and seeing which ones match the rules I personally use "hacked" bird daemon, but it is not ready for public testing... --- William Leibzon, Elan Networks: mailto: william@elan.net Anti-Spam and Email Security Research Worksite: http://www.elan.net/~william/emailsecurity/

Hi, Cliff. ] I have one question regarding the CYMRU bogon route-server. What good is ] it if more-specific bogons are going around in the BGP table ? At present, none. We have feature requests into some major router vendors to make this more useful. The goal is to provide a syntax similar to prefix-list that would permit you to filter on a prefix and anything more specific. Stay tuned! Thanks, Rob. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);

On Sun, Dec 05, 2004 at 07:38:06PM +0100, Cliff Albert wrote:

On Sun, Dec 05, 2004 at 12:36:08PM -0600, Rob Thomas wrote:

...

] I have one question regarding the CYMRU bogon route-server. What good is ] it if more-specific bogons are going around in the BGP table ?

At present, none. We have feature requests into some major router vendors to make this more useful. The goal is to provide a syntax similar to prefix-list that would permit you to filter on a prefix and anything more specific. Stay tuned!

Indeed, that's the biggest problem at the moment. I have seen some folks feature requesting this at juniper, but seems they all got a big NO back.

-- Cliff Albert <cliff@oisec.net>

Just FYI -- Team Cymru also provides IRR objects for those using automated BGP policies with ease. Using IRR objects, dependent on how *you* set it up, you should be able to filter out specifics. Their object is fltr-bogons on whois.radb.net: filter-set: fltr-bogons descr: All bogon IPv4 prefixes. filter: fltr-unallocated OR fltr-martian tech-c: RTH32-ARIN admin-c: RTH32-ARIN mnt-by: MAINT-BOGON-FILTERS changed: radb@cymru.com 20040420 source: RIPE Example for filtering bogons from transit: import: from AS209 accept ANY and not fltr-bogons I make use of these objects for configuring BGP for customers who are multihomed to different ISP's, so far with great success. Hope this helps, -J -- James Jun TowardEX Technologies, Inc. Technical Lead Boston IPv4/IPv6 Web Hosting, Colocation and james@towardex.com Network design/consulting & configuration services cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net