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
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
Could we not just have a file somewhere that shows all ranges allocated to RIR's. ISP's could then script to generate their filters. Jon
Jon, What you suggest is exactly what Team Cymru does by using the IANA pages This only works for the clueful though. It doesn't matter how much the RIR's and IANA announce the briningin into circulation of /8s there always seems to be those who are not watching for such issues, or who are totally unaware that the filters should and do change. What Daniel is suggesting is a more pro-active approach on behalf of the RIR's. The advantage is that it may reach those who normally would not even be aware that they have an issue. My personal opinion is that such an effort should be applauded. John Crain Jon Lawrence wrote:
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
Could we not just have a file somewhere that shows all ranges allocated to RIR's. ISP's could then script to generate their filters.
Jon
On Tuesday 24 February 2004 19:17, John Crain wrote:
Jon,
What you suggest is exactly what Team Cymru does by using the IANA pages This only works for the clueful though. It doesn't matter how much the RIR's and IANA announce the briningin into circulation of /8s there always seems to be those who are not watching for such issues, or who are totally unaware that the filters should and do change.
In theory, ISP's running BGP services should have some 'clue' and if they're using filters then they should know what they are etc etc.
What Daniel is suggesting is a more pro-active approach on behalf of the RIR's. The advantage is that it may reach those who normally would not even be aware that they have an issue.
Whilst a proactive approach is a good idea, is it really the RIR's position to do this ? As has been said previously, it's not the RIR's responsibility to ensure routability of IP addtresses this must lie with the various ISP's. Jon
On 24.02 19:41, Jon Lawrence wrote:
What Daniel is suggesting is a more pro-active approach on behalf of the RIR's. The advantage is that it may reach those who normally would not even be aware that they have an issue.
Whilst a proactive approach is a good idea, is it really the RIR's position to do this ? As has been said previously, it's not the RIR's responsibility to ensure routability of IP addtresses this must lie with the various ISP's.
I note that explicitly in my draft. If there are many ISPs opposed to the RIRs doing this we will gladly not do it and point those experiencing connectivity problems because of false positive matches on out-dated bogon filters to the fact that our community does not want us to do anything about it pro-actively. ;-( Daniel
At 23:02 24-2-2004, Daniel Karrenberg wrote:
On 24.02 19:41, Jon Lawrence wrote:
What Daniel is suggesting is a more pro-active approach on behalf of the RIR's. The advantage is that it may reach those who normally would not even be aware that they have an issue.
Whilst a proactive approach is a good idea, is it really the RIR's position to do this ? As has been said previously, it's not the RIR's responsibility to ensure routability of IP addtresses this must lie with the various ISP's.
I note that explicitly in my draft. If there are many ISPs opposed to the RIRs doing this we will gladly not do it and point those experiencing connectivity problems because of false positive matches on out-dated bogon filters to the fact that our community does not want us to do anything about it pro-actively. ;-(
I think a proactive approach from the RIR's is the only way to put enough pressure behind this to make sure the bogon filters get updated in a timely fashion. Being one of those LIR's who was assigned an early allocation out of 83/8, I can say from experience that outdated bogon filters were (are) both very widespread, and definately noy just restricted to the category of "small(er) ISP's who might have missed the announcements on the RIR/network mailing lists". Outdated bogon filters were (are) to be found anywhere from individuals with a "copy & paste" ipchains/ipfw script up to the very largest of the big-media companies and transit providers. Arjen Wolfs
On 24.02 23:02, Daniel Karrenberg wrote:
On 24.02 19:41, Jon Lawrence wrote:
Whilst a proactive approach is a good idea, is it really the RIR's position to do this ? As has been said previously, it's not the RIR's responsibility to ensure routability of IP addtresses this must lie with the various ISP's.
I note that explicitly in my draft. If there are many ISPs opposed to the RIRs doing this we will gladly not do it and point those experiencing connectivity problems because of false positive matches on out-dated bogon filters to the fact that our community does not want us to do anything about it pro-actively. ;-(
Jon, on re-reading this message this morning I realise that its tone was a bit inappropriate. My only excuse is the serious abuse I have been exposed to in private messages since I posted this draft. It looks like a lot of people take me personally responsible for out-dated bogon filters I have no responsibility for whatsoever. Once again, apologies for the tone of voice. The message remains: If you want the RIRs to do the pro-active testing and notofocation that I propose you will have to make your voice heared to them, just as you have to make your voice heared if you believe they should not do this. Regards Daniel
On Wednesday 25 February 2004 14:19, Daniel Karrenberg wrote:
on re-reading this message this morning I realise that its tone was a bit inappropriate. My only excuse is the serious abuse I have been exposed to in private messages since I posted this draft. It looks like a lot of people take me personally responsible for out-dated bogon filters I have no responsibility for whatsoever. Once again, apologies for the tone of voice.
The message remains: If you want the RIRs to do the pro-active testing and notofocation that I propose you will have to make your voice heared to them, just as you have to make your voice heared if you believe they should not do this.
No worries, tone was fine by me :) and I can see no reason as to why people should send you any abuse. The question is a valid question - should more proactive notification be something that the RIR's do or not ?. Regards, Jon
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
What Daniel is suggesting is a more pro-active approach on behalf of the RIR's. The advantage is that it may reach those who normally would not even be aware that they have an issue.
Whilst a proactive approach is a good idea, is it really the RIR's position to do this ? As has been said previously, it's not the RIR's responsibility to ensure routability of IP addtresses this must lie with the various ISP's.
I don't think that what Daniel is proposing has anything to do with ensuring routability. It is simply a means to visualize where you might encoutner problems. Best regards, - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQDxU5aarNKXTPFCVEQKmaQCg0JfM2tzrWzs3d0Zu1iDBhp4kkwMAn04s D88NuNdzGaECxat388nlrBVk =5cNc -----END PGP SIGNATURE-----
On 25.02 08:55, Kurt Erik Lindqvist wrote:
I don't think that what Daniel is proposing has anything to do with ensuring routability.
Exactly! I do not usually propose things that are impossible to achieve. This is about pro-active notification. Routing policy is squarely in the hands of the network operators. Daniel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-02-25, at 15.21, Daniel Karrenberg wrote:
On 25.02 08:55, Kurt Erik Lindqvist wrote:
I don't think that what Daniel is proposing has anything to do with ensuring routability.
Exactly! I do not usually propose things that are impossible to achieve. This is about pro-active notification. Routing policy is squarely in the hands of the network operators.
From having read the comments on the RIPE mailinglists and Nanog, I think that most people seems to have read this in a very different way that I think Daniel meant this to come across. I talked about this with Daniel when it was first originally brought up, and I got to review the document before it came out. Unfortunately I didn't have time, but even then I am not sure I would could have helped make the idea more clear. What I think we need (and what I think Daniel is proposing) is the same as the volunteers doing this today. The advantages with the scheme proposed by Daniel is that a) RIPE do have a pretty large number of probes. b) They don't (necessarily) have the same issue of getting a large enough block out of the new IANA allocation to make the test useful. It's no more, no less. I really have a hard time with seeing what is controversial with the basic proposal. If is is, then we are down to having to change the wording in the document. I can see that there is plenty of room for discussion around what to do with the data and how to publish it though. And _that_ is a discussion I think is worth having. Best regards, - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQD0FP6arNKXTPFCVEQIy8wCffnVHpJ4phY0JyTfINr3qz3cb5OAAoL4P pXj8kPOxkjfY7ePO4SQTXxti =xxir -----END PGP SIGNATURE-----
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
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 (14)
-
Andre Oppermann -
Arjen Wolfs -
Barry Greene (bgreene) -
Daniel Karrenberg -
Gert Doering -
Jeff Williams -
Jerome Fleury -
John Crain -
Jon Lawrence -
Jørgen Hovland -
Kurt Erik Lindqvist -
Michael.Dillon＠radianz.com -
Rob Thomas -
Sascha Lenz