Re: [address-policy-wg] New Draft Document: De-boganising New Address Blocks
The RIPE NCC has prepared a draft document titled "De-Bogonising New Address Blocks":
That is a misleading title. The problem is that ISPs cannot react quickly enough to open filters when new ranges are allocated. The proposed solution is to provide advance notification. I suppose this could allow ISPs to open filters before the new addresses are actually in use officially. However, it will also allow spammers to announce this space and get it through bogon filters. The real solution to this problem is to make it possible for ISPs to closely track RIR allocations in their filters in a semi-automated way. There may still be a few days of delay before a new allocation is fully routable but ISPs can compensate for that with internal processes. Why can't ISPs subscribe to a feed of all new RIPE allocations in near real-time? --Michael Dillon
On 24.02 16:17, Michael.Dillon@radianz.com wrote:
The RIPE NCC has prepared a draft document titled "De-Bogonising New Address Blocks":
That is a misleading title.
I thought it was to the point and rather cute ;-).
The problem is that ISPs cannot react quickly enough to open filters when new ranges are allocated. The proposed solution is to provide advance notification. I suppose this could allow ISPs to open filters before the new addresses are actually in use officially.
This is the status quo, aka best *current* practise.
However, it will also allow spammers to announce this space and get it through bogon filters.
Correct, but only in the absence of more specific filtering. the problem this proposal aims to correct is the increasing number of false positives caused by the apparent *serious* lag in relatively static bogon filtering.
The real solution to this problem is to make it possible for ISPs to closely track RIR allocations in their filters in a semi-automated way. There may still be a few days of delay before a new allocation is fully routable but ISPs can compensate for that with internal processes.
Why can't ISPs subscribe to a feed of all new RIPE allocations in near real-time?
Personally I think this is a great idea and if we hear from a lot of operators actually willing to take such feeds it may become reality. However there are a number of serious issues with something like this, not the least of which are the liability issues in case this goes wrong very dynamically and semi-automatdly. It is certainly something to progress if there is enough interest. However I think the current proposal shold go ahead too because the false positives are a real problem now Daniel
Daniel and all, Daniel Karrenberg wrote:
On 24.02 16:17, Michael.Dillon@radianz.com wrote:
The RIPE NCC has prepared a draft document titled "De-Bogonising New Address Blocks":
That is a misleading title.
I thought it was to the point and rather cute ;-).
- snip-
Why can't ISPs subscribe to a feed of all new RIPE allocations in near real-time?
Personally I think this is a great idea and if we hear from a lot of operators actually willing to take such feeds it may become reality. However there are a number of serious issues with something like this, not the least of which are the liability issues in case this goes wrong very dynamically and semi-automatdly.
I also agree this is a really good idea as well. But also share the concerns that many ISP's cannot or will not assume.
It is certainly something to progress if there is enough interest.
However I think the current proposal shold go ahead too because the false positives are a real problem now
Daniel
Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827
Michael.Dillon@radianz.com wrote:
The RIPE NCC has prepared a draft document titled "De-Bogonising New Address Blocks":
That is a misleading title.
The problem is that ISPs cannot react quickly enough to open filters when new ranges are allocated. The proposed solution is to provide advance notification. I suppose this could allow ISPs to open filters before the new addresses are actually in use officially.
ISPs should not filter the IANA reserved IP ranges but only the Martians stuff that is defined to be unrouteable. Everything else is causing more problems than it solves. Otherwise we wouldn't have this discussion over and over again each time a RIR opens a fresh /8.
However, it will also allow spammers to announce this space and get it through bogon filters.
There is no way you can block spammers by filtering the IANA reserved ranges. There are many other ways spammers can set up bogon netblocks. For example there are many netblocks which are assigned/allocated by the RIRs but never announced in the global routing system. Just walk the prefix table of current /8s used by the RIRs and use the holes to send your spam. Again, the cure of filtering is worse than the desease of not filtering.
The real solution to this problem is to make it possible for ISPs to closely track RIR allocations in their filters in a semi-automated way. There may still be a few days of delay before a new allocation is fully routable but ISPs can compensate for that with internal processes.
There is no way every ISP is going to follow that and adjust his filters within "a few days".
Why can't ISPs subscribe to a feed of all new RIPE allocations in near real-time?
Just don't filter IANA reserved space. It's that easy. -- Andre
I fully agree with that. Most of all, the problem of filters is not located at ISP borders, but mostly at customers borders (e.g. small hosting companies) who do not update their filters, and who often have no idea what they are useful for. Andre is right, the best solution is definitely not to filter bogons. We have recently been allocated a /13 in 83/8, and now we have to deal with many many many customers complaining not to be able to reach many sites (expsecially in US). I'm very angry about RIPE and IANA allocating those blocks too quickly, without any vision of consequences for LIRs, and without any communications going down from Tier1 to the smallest company. --On mardi 24 février 2004 17:36 +0100 Andre Oppermann <oppermann@pipeline.ch> wrote:
Michael.Dillon@radianz.com wrote:
The RIPE NCC has prepared a draft document titled "De-Bogonising New Address Blocks":
That is a misleading title.
The problem is that ISPs cannot react quickly enough to open filters when new ranges are allocated. The proposed solution is to provide advance notification. I suppose this could allow ISPs to open filters before the new addresses are actually in use officially.
ISPs should not filter the IANA reserved IP ranges but only the Martians stuff that is defined to be unrouteable. Everything else is causing more problems than it solves. Otherwise we wouldn't have this discussion over and over again each time a RIR opens a fresh /8.
However, it will also allow spammers to announce this space and get it through bogon filters.
There is no way you can block spammers by filtering the IANA reserved ranges. There are many other ways spammers can set up bogon netblocks. For example there are many netblocks which are assigned/allocated by the RIRs but never announced in the global routing system. Just walk the prefix table of current /8s used by the RIRs and use the holes to send your spam.
Again, the cure of filtering is worse than the desease of not filtering.
The real solution to this problem is to make it possible for ISPs to closely track RIR allocations in their filters in a semi-automated way. There may still be a few days of delay before a new allocation is fully routable but ISPs can compensate for that with internal processes.
There is no way every ISP is going to follow that and adjust his filters within "a few days".
Why can't ISPs subscribe to a feed of all new RIPE allocations in near real-time?
Just don't filter IANA reserved space. It's that easy.
-- Andre
-- Jerome Fleury Tiscali France Network Engineer Tel: +33 1 45082314
On 24.02 17:56, Jerome Fleury wrote:
... > I'm very angry about RIPE and IANA allocating those blocks too quickly, without any vision of consequences for LIRs, and without any communications going down from Tier1 to the smallest company.
What would be an appropriate timing in your opinion? Daniel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Andre is right, the best solution is definitely not to filter bogons.
It does not seem people are getting at the core of the problem. Prefix filtering the IANA reserved space was a reactionary consequence - not something ISPs did on a whim. All I'm seeing is people being upset over the consequence of the reactionary consequence of IANA Reserved with out getting to the crux of the problem. -----BEGIN PGP SIGNATURE----- Version: PGP 8.0 iQA/AwUBQDzBLb/UEA/xivvmEQLLJQCg4UWIcbpLBAliAXNo7K088o1dKhAAoIL9 Fn0qKvv5+whsAc1+AID31cqc =yH2U -----END PGP SIGNATURE-----
"Barry Greene (bgreene)" wrote:
Andre is right, the best solution is definitely not to filter bogons.
It does not seem people are getting at the core of the problem. Prefix filtering the IANA reserved space was a reactionary consequence - not something ISPs did on a whim. All I'm seeing is people being upset over the consequence of the reactionary consequence of IANA Reserved with out getting to the crux of the problem.
Ok, it seems like a) filtering of IANA reserved prefixes creates more problems than it solves. b) noboby has named the "crux" of the problem yet. -- Andre
Hi, team. ] Andre is right, the best solution is definitely not to filter bogons. Best solution for what problem, exactly? :) Bogon filtering does help, though it can be accomplished in a variety of ways (e.g. bogon route-servers, ACLs, uRPF with prefix filtering). 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! 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. 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. 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. :) Thanks, Rob. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);
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
Hi, Andre. There are presently 95 bogon prefixes advertised by the bogon route-servers. That is plenty of space from which to generate spoofed source addresses. The reality is that the miscreants are seeing a lower return on the investment when spoofing from bogon prefixes. Thus they are more inclined to use routed space as the source of spoofed addresses. You can see this in much of the more popular spoofed packet generating malware. A lot of this malware specifically checks to ensure that the source addresses are not bogons, or ensures that the source addresses are in the same /16 as where the infected host resides. If the malware spoofs within its own /16, or has blocks to ensure that bogon prefixes are not used in the spoofing, suddenly "perfection" isn't so perfect. These addresses most certainly will be in the routing tables of most routers. This is why we never state that bogon filtering is the perfect answer to the problem of spoofing. ] 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. Ah, but that isn't perfect if the source address is routed when it shouldn't be. :) What if a bogon gets into the FIB of a router? One must filter to ensure that the routing table only includes legitimate prefixes. This is why I mentioned uRPF with prefix filtering in my previous note, and also why I suggested that there is more than one way to solve the problem. :) Thanks, Rob. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);
Hi On Wed, 25 Feb 2004, Andre Oppermann wrote:
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!
There are actually some people here doing exactly that: Sending packets with an unroutable source-ip - with totally "legit" reasons. It's bad enough that people actually use bogon-filters for reserved blocks when it after my oppinion should be limited to unallocated blocks (for traffic blocking, not routes). You simply don't block anyones ip-range just because it isn't routable. Blocking traffic is a security concern (still after my oppinion). Internet was probably designed for bi-directional communication, but it doesn't mean you should ban one-way communication.
Summary: Bogon filtering based on the IANA reserved listings is very much bogus in itself.
The problem with any list is that you have to maintain it. Many people don't do that. The general solution could be to stop using bogon filters at all? I have seen it too, spammers advertising unallocated prefixes. Don't have a routing-based solution to that. Spammers could might as well announce an allocated block already routed or not. That's something to think about! Joergen Hovland ENK
Hi, On Wed, Feb 25, 2004 at 10:23:48PM +0100, Jørgen Hovland wrote:
There are actually some people here doing exactly that: Sending packets with an unroutable source-ip - with totally "legit" reasons.
Could you be somewhat more specific about these "legit" reasons? [..]
Internet was probably designed for bi-directional communication, but it doesn't mean you should ban one-way communication.
One-Way communication works quite well with legit (read: assigned to the sender) source addresses. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 58081 (57882) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On Wed, 25 Feb 2004, Gert Doering wrote:
Hi,
On Wed, Feb 25, 2004 at 10:23:48PM +0100, Jørgen Hovland wrote:
There are actually some people here doing exactly that: Sending packets with an unroutable source-ip - with totally "legit" reasons.
Could you be somewhat more specific about these "legit" reasons?
Well.. Generally any device that would like to send messages without the need of a reply, or not in need of a reply through the same transport method/layer or ip (kind of asynchronous communication). I could name some, but I think what you are looking for is this: Routers with a non-routed ip-address by choice or by nature. IX-prefix for instance. IPv6 applies here specially. Besides from that there are software taking advantage of it like our own little project AP2P, truly anonymous P2P. Joergen Hovland ENK
Hi, On Thu, Feb 26, 2004 at 06:20:01AM +0100, Jørgen Hovland wrote:
On Wed, Feb 25, 2004 at 10:23:48PM +0100, Jørgen Hovland wrote:
There are actually some people here doing exactly that: Sending packets with an unroutable source-ip - with totally "legit" reasons.
Could you be somewhat more specific about these "legit" reasons?
Well.. Generally any device that would like to send messages without the need of a reply, or not in need of a reply through the same transport method/layer or ip (kind of asynchronous communication).
No specific reason why these applications couldn't use "proper" source-IPs, even if not expecting a reply.
I could name some, but I think what you are looking for is this: Routers with a non-routed ip-address by choice or by nature. IX-prefix for instance. IPv6 applies here specially.
IXP prefixes can be non-routed, but *are* well-known and properly assigned. So bogon source filtering will (usually) NOT blackhole IXP prefixes (while excessive uRPF on upstream lines will).
Besides from that there are software taking advantage of it like our own little project AP2P, truly anonymous P2P.
Now this is an interesting problem indeed. You need to weigh the benefits of this (in comparision to things like encrypted P2P clouds that claim to bring anonymity as well) against the chances of non-trackable abuse. This is a tricky question. I have made my decision on that: our customers can do whatever they like - as long as they do it from IP addresses that are well-assigned to them (even if temporary). If they commit abuse, in whatever form, be it a virus infection or intentional hacking, they can be traced back, and can be made legally liable for any damage they cause (if necessary). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 58081 (57882) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Hay, Michael.Dillon@radianz.com wrote:
The RIPE NCC has prepared a draft document titled "De-Bogonising New Address Blocks":
That is a misleading title. [...] The real solution to this problem is to make it possible for ISPs to closely track RIR allocations in their filters in a semi-automated way. There may still be a few days of delay before a new allocation is fully routable but ISPs can compensate for that with internal processes.
Why can't ISPs subscribe to a feed of all new RIPE allocations in near real-time?
the problem never were the ISPs which do their job and follow the new RIR Allocation and Smallest Prefix Size Announcements. The problem always are those ISPs with dummy admins who just took some bogon template from some cool looking BGP configuration website and never update them at all, don't read RIR-mailinglists or things like NANOG-list and/or just don't care. (...and so on). I don't think a technical solution helps against this problem at all since only those ISPs who already care about their filters would use it, and there certainly will be some ISPs who don't want to pass the control about their filters to some 3rd party. ==> The only reasonable solution for now is just what's RIPE trying to do, look into the routability itself and kick all those who haven't updated their filters in time. That's a bit unfortunate since RIPE usually shouldn't have to do much with routing-issues in the first place, but actually i like that idea of THEM doing that. It's a benefit for all LIRs so it's a nice idea in my eyes. I'm currently quite amused watching some collegues of a customer of us trying to track down all unreachable sites and reach their admins for about two months now, especially since they already started putting end-user el-cheapo-DSL customers in their nice new 83.x.x.x IP-block which are the worst of all customer-types you can possibly get. I don't really want to experience that myself some day. Fortunately i could avoid playing early-adoption betatester for newly Allocated /8s up to now :) . o O(and then there was this big(?) european Telco/ISP still filtering AS-numbers >30000 up to some weeks ago :-) ) -- ======================================================================== = Sascha 'master' Lenz SLZ-RIPE slz@baycix.de = = NOC BayCIX GmbH = = http://www.noc.baycix.de/ * PGP public Key on demand * = ========================================================================
participants (10)
-
Andre Oppermann -
Barry Greene (bgreene) -
Daniel Karrenberg -
Gert Doering -
Jeff Williams -
Jerome Fleury -
Jørgen Hovland -
Michael.Dillon＠radianz.com -
Rob Thomas -
Sascha Lenz