This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/routing-wg@ripe.net/
[address-policy-wg] New Draft Document: De-boganising New AddressBlocks
- Previous message (by thread): [address-policy-wg] New Draft Document: De-boganising New AddressBlocks
- Next message (by thread): [ncc-services-wg] Re: [address-policy-wg] New Draft Document: De-boganising New AddressBlocks
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Andre Oppermann
oppermann at pipeline.ch
Wed Feb 25 21:30:28 CET 2004
Rob Thomas wrote: > > Hi, team. > > ] Andre is right, the best solution is definitely not to filter bogons. > > Best solution for what problem, exactly? :) That is the biggest question. It seems to be a moving target. The first problem mentioned was nasty spammers announcing prefixes from IANA reserved netblocks. Now you open a second one with stating that address spoofing from bogon ranges is a problem. > Bogon filtering does help, though it can be accomplished in a variety > of ways (e.g. bogon route-servers, ACLs, uRPF with prefix filtering). Positive bogon filtering is exactly the wrong thing to do. It simply doesn't scale. You don't want to get packets with non-routed source addresses. This again is very much different from bogons. There are many prefixes out of the allocated netblocks which are not routed in the global routing system. The only real fix you apply here is to check the source address of a packet if it is routeable. If not, just drop it. That alone is saving you any traffic from any kind of bogus prefix or netblock. And the best of it is it automagically takes care of adjusting to new netblocks without any operator invention! Summary: Bogon filtering based on the IANA reserved listings is very much bogus in itself. > Take a peek at my study entitled "60 Days of Basic Naughtiness" for > some data points on bogon address usage. > > <http://www.cymru.com/Presentations/60Days.zip> > <http://www.cymru.com/Presentations/60Days.ppt> > > Others see more or less of this depending on what they host or > transit. One thing we have seen in our darknet monitoring is a > decrease in the use of bogon source addresses. Why? Because they > are less effective (thankfully). Ah, but read on! I'd say you see less bogon source addresses because there are less... The RIRs have been opening a couple of fresh /8s recently. > Does this *solve* the problems of DDoS, hacking, scanning? No, of > course not. The miscreants have multiple methods in their toolkits, > with spoofing being only one. In fact spoofing applies to allocated > and routed space as much as it applies to unallocated (aka bogon) > space. What we are attempting to do is to reduce the effectiveness > of one particular set of badness. Your and some others problem is using/promoting the wrong solution to the [right]* problem. []* depending on what the problem de jour is. > Defense in depth works, and every little bit helps. Just as many > folks do not rely on a single provider for Internet access, we > shouldn't rely on a single method to mitigate or block malevolent > flows. Yes, I fully agree. But do it really right. Two wrongs don't make a right. > I love the idea of the RIRs and IANA providing the service! We at > Team Cymru are happy to help them in any way towards that goal. > Once those mechanisms are in place and tested, we're happy to turn > down our service in deference to their authoritative service. That > is a ways off, I suspect, so don't take that as a formal statement > or plan. :) There is absolutely no service for the RIRs or IANA to provide. You have got all tools you need already. If the source address is not routed, then don't route it. Very easy, very fast, very stable, no maintainance overhead, nothing that can go wrong. Just perfect. -- Andre
- Previous message (by thread): [address-policy-wg] New Draft Document: De-boganising New AddressBlocks
- Next message (by thread): [ncc-services-wg] Re: [address-policy-wg] New Draft Document: De-boganising New AddressBlocks
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]