From lasse at jarlskov.dk Sun Feb 15 16:39:13 2004 From: lasse at jarlskov.dk (Lasse Jarlskov) Date: Sun, 15 Feb 2004 16:39:13 +0100 Subject: [address-policy-wg] (no subject) In-Reply-To: <1075143442.24413.809.camel@thilo> References: <1075143442.24413.809.camel@thilo> Message-ID: On Mon, 26 Jan 2004 19:57:23 +0100, you wrote: >Has anybody used 82/8 subnets and gathered real life experience on how >they route? I'd much rather be prepared, if this turns into a teaching >assignment. Sorry for a late reply to this. FWIW we have been routing 82.180/16 for quite some time now. We have lots of private customers using these addresses and we have received no complaints about this at all. /Jarlskov From TBekdemir at dol.com.tr Mon Feb 16 16:31:55 2004 From: TBekdemir at dol.com.tr (Tahsin Bekdemir) Date: Mon, 16 Feb 2004 17:31:55 +0200 Subject: [address-policy-wg] IP assignment Message-ID: <4D403C88E41C704C9A90336CA54619CE09267F@dolxch11.dol.int> Hi, One of the our customers use an IP block including few IP addresses now. They plan to upgrade their IP network and will need C class network.They asked us a independent IP block . What is the requirements for a PI assignment? Tahsin BEKDEMIR Network Services Dogan Online Hurriyet Medya Towers,Gunesli Istanbul, TURKEY Phone: +90-212-677 00 00 /ext:2363 E-mail: tbekdemir at dol.com.tr -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Thilo Salmon Sent: Monday, January 26, 2004 8:57 PM To: address-policy-wg at ripe.net Subject: [address-policy-wg] (no subject) Hello everyone, when RIPE received 82/8 from IANA about a year ago, there has been a discussion on potential routing issues due to ancient filters on this list. That thread went far enough to raise the question whether or not subnets in question should be returned. Getting my daily fix of tech rants I noticed this issue appears to have resurfaced in the mainstream media at http://heise.de/newsticker/data/hob-26.01.04-000/ (German) http://translate.google.com/translate?hl=en&sl=de&u=http://heise.de/news ticker/data/hob-26.01.04-000/ (Google translation) We received a prefix from within this network which we plan to use soon and I am now wondering whether or not we can expect to run into problems. Going through a number of looking glasses I could see my announcement just fine. But then, ISPs who offer lookging glass services are probably more likely to keep their filters up to date. Has anybody used 82/8 subnets and gathered real life experience on how they route? I'd much rather be prepared, if this turns into a teaching assignment. Thilo From leo at ripe.net Fri Feb 20 01:45:15 2004 From: leo at ripe.net (leo vegoda) Date: Fri, 20 Feb 2004 08:45:15 +0800 Subject: [address-policy-wg] Draft minutes: RIPE 47 Address Policy WG session Message-ID: <0C9CBB50-633E-11D8-8E33-000A95DAB530@ripe.net> Dear Colleagues, Draft minutes from the Address Policy Working Group session at RIPE 47 can be found at: http://www.ripe.net/ripe/wg/address-policy/r47-minutes.html Please check the minutes for errors or omissions. Comments and corrections can be sent directly to this list or to one of the WG chairs personally. Kind regards, -- leo vegoda Registration Services Manager RIPE NCC From ncc at ripe.net Mon Feb 23 11:55:30 2004 From: ncc at ripe.net (Nick Hyrka) Date: Mon, 23 Feb 2004 11:55:30 +0100 Subject: [address-policy-wg] RIPE 47 Meeting Report Message-ID: <5.2.1.1.2.20040223114431.03dd5eb0@mailhost.ripe.net> (Apologies for any duplicate mails.) RIPE 47 Meeting Report Dear Colleagues, The RIPE 47 Meeting was held from 26 - 30 January 2004 at the Grand Hotel Krasnapolsky, Amsterdam, the Netherlands. There were a total of 253 attendees comprised of the RIPE NCC membership, the RIPE community and government representatives. Attendees also included representatives from APNIC, ARIN, AfriNIC, LACNIC, ICANN and IANA. HIGHLIGHTS ========== - Highlights of RIPE 47 included the open discussion on the services of the RIPE NCC during the RIPE NCC Services Working Group; updates on the World Summit on the Information Society from Mirjam Khne, ISOC, and Axel Pawlik, Managing Director, RIPE NCC; an AfriNIC update; the proposal by the RIPE community to make RIPE 152 ( 'Charging by Local Internet Registries') a historical document. - As announced by Rob Blokzijl, RIPE Chair, two RIPE Meetings will be held in 2005. Based on the feedback from the community, this schedule will continue in 2006. The RIPE NCC will offer additional support to RIPE Working Groups to facilitate discussion and progress between RIPE Meetings. - Robin Tasker (CCLRC) gave a presentation on the European Commission-sponsored DataTAG project. - The European Operators Forum (EOF) featured an NSP Security BoF, a presentation on which types of SMTP flows should be blocked to prevent spam, a case study on the migration of AOL's backbone network from OSPF to IS-IS and discussion on the use of XML in network configuration. EOF presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-47/presentations/index.html#eof - The RIPE NCC, Afilias, Cisco, NIKHEF, NOKIA, Riverhead and SURFnet are thanked for the support they provided to the meeting. Global Voice Networks are thanked for the provision of excellent Internet connectivity. SUMMARY ======== ADDRESS POLICY - It was proposed that RIPE 152 ('Charging by Local Internet Registries') should be made a historical document and that the RIPE NCC should make a clear statement on www.ripe.net that it does not charge for IP addresses. - Hans Petter Holen, Chair, will form a task force to write a policy development process proposal. - Consensus is needed on the mailing list on the AfriNIC proposal regarding /22 minimum allocation size. - Hans Petter Holen, Chair, will start a discussion on the mailing list on changing the 80% rule for IPv4 allocations. Address Policy Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-47/presentations/#ap DATABASE - The issue of CRISP versus joint Whois was discussed. - The proposal to introduce new attribute "abuse-c" in the inet(6)num objects was discussed. - A detailed proposal about "abuse-c" will be sent to Database Working Group mailing list. Database Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-47/presentations/#db TEST TRAFFIC MEASUREMENT (TTM) - It was noted that as of 1/1/2004 changes were made to the TTM service contract: Fees were lowered (from 3000 EUR per year to 1000 EUR per year) and all data has been made public as specified in RIPE 300 ('Test Traffic Measurement Service Data Disclosure Policy'). - Two presentations made use of TTM delay data: a presentation on delay tomography used traceroute data from the TTM project; a presentation on the reordering of IP packets used delay data. TTM Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-47/presentations/#tt ANTI-SPAM - A proposal has been sent to the Database Working Group mailing list regarding the inclusion of an abuse-c attribute/object in the RIPE Database to help solve the problem of misdirected/multiple spam complaints. - It was noted that the European Commission Directive is now widely implemented and that in the United States CAN-SPAM is the first federal legislation. IPv6 - The anycast policy discussion was sent to the Address Policy Working Group. - There was discussion on how 6 to 4 is being used to spoof IPv4 origin addresses to make Distributed Denial of Service (DDoS) attacks anonymous. - There was a presentation on the security implications of IPv6 on IPv4 networks. IPv6 Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-47/presentations/#ipv6 EIX - An editorial group will be set up to revise the exchange point operator wish list for switches. - Operator-member charters for exchange points were discussed. - DE-CIX presented their experience migrating to new hardware and adding new premises. EIX Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-47/presentations/#eix DN* - The DNR Forum and the DNS Working Group were combined under the DNS Working Group heading. - It was noted that the ENUM RFC 2916bis has been approved by the IETF Working Group and is in the queue of the RFC editor. - It was noted that Internationalized Domain Names (IDN) are being deployed in more new regions. DN* Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-47/presentations/#dn ROUTING - There was a presentation on RISwhois, a tool that allows IP address to origin ASN mapping. - Case studies about convergence of IGP protocols were presented and discussed. Routing Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-47/presentations/#routing RIPE NCC SERVICES - Bijal Sanghani, FLAG Telecom, was appointed as the co-chair of the Working Group. - The RIPE NCC will explore the possibility of providing a service giving test statistics on the routability of new blocks. - The RIPE NCC will give a status update on the Activity Plan 2004 and request input for the Activity Plan 2005 during the RIPE NCC Services Working Group at RIPE 48. RIPE NCC Services Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-47/presentations/#ncc-services TUTORIALS ========= The RIPE NCC staff presented the RIPE NCC IP Request Tutorial. It explained address space assignment and allocation procedures in the RIPE NCC region: http://www.ripe.net/ripe/meetings/ripe-47/tutorials/ip-request/ RIPE 47 WEBCASTING AND ARCHIVES ============================== During RIPE 47, the RIPE NCC held trials in collecting feedback from participants watching the webcast. The mediums used for this were IRC and Jabber. Archives of presentations, webcasts and IRC/Jabber feedback from RIPE 47 are available at: http://www.ripe.net/ripe/meetings/ripe-47/sessions-archive.html HOSTMASTER CONSULTATION CENTRE (HCC) ==================================== The RIPE NCC Hostmaster Consultation Centre was open at RIPE 47, allowing RIPE NCC Members to discuss issues relating to their business directly with RIPE NCC Hostmasters. RIPE 47 REFERENCE PAGE ====================== A complete list of RIPE 47 sessions, tutorials and presentations can be found at: http://www.ripe.net/ripe/meetings/ripe-47/index.html "MEET & GREET" ============= The RIPE NCC's "Meet & Greet" was available for first-time RIPE Meeting attendees at RIPE 47. "Meet & Greet" introduces newcomers to the meetings, to key attendees from the RIPE community and to social events throughout the week. More information can be obtained by contacting: . RIPE 48 ====== RIPE 48 will be held in Amsterdam, the Netherlands, from 3 - 7 May 2004. Information on RIPE 48 will soon be made available at: http://www.ripe.net/ripe/meetings/ripe-48/ New Local Internet Registries (LIRs) ========================== Please note: New LIRs are entitled to two (2) free tickets to attend a RIPE Meeting. The tickets cover the meeting fee only and do not apply to the RIPE dinner, travel or hotel accommodation. More information on the new LIR tickets can be found at: http://www.ripe.net/ripe/meetings/new-lir.html For more information, contact . -- end -- From webmaster at ripe.net Tue Feb 24 16:48:38 2004 From: webmaster at ripe.net (RIPE NCC WebMaster) Date: Tue, 24 Feb 2004 16:48:38 +0100 Subject: [address-policy-wg] New Draft Document: De-boganising New Address Blocks Message-ID: <200402241548.i1OFmce2005266@birch.ripe.net> (Apologies for duplicate mails) Dear Colleagues, The RIPE NCC has prepared a draft document titled "De-Bogonising New Address Blocks": Abstract "This document describes an improvement in the notification process about new blocks of address space being distributed by the RIRs. It is a draft at this stage and your comments are solicited. However to gain experience before finalising the procedures, the RIPE NCC will shortly start announcing the routes from 84/8 described in the document under "pilot"." This document is published as a draft document in order to give RIPE NCC members time to read it and provide feedback. This draft document can be discussed on the RIPE NCC Services Working Group mailing list at . Regards, Webmaster RIPE NCC From Michael.Dillon at radianz.com Tue Feb 24 17:17:28 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Tue, 24 Feb 2004 16:17:28 +0000 Subject: [address-policy-wg] New Draft Document: De-boganising New Address Blocks Message-ID: >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 From daniel.karrenberg at ripe.net Tue Feb 24 17:29:42 2004 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 24 Feb 2004 17:29:42 +0100 Subject: [address-policy-wg] New Draft Document: De-boganising New Address Blocks In-Reply-To: References: Message-ID: <20040224162942.GO1508@reifa-wave.karrenberg.net> On 24.02 16:17, Michael.Dillon at 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 From oppermann at pipeline.ch Tue Feb 24 17:36:03 2004 From: oppermann at pipeline.ch (Andre Oppermann) Date: Tue, 24 Feb 2004 17:36:03 +0100 Subject: [address-policy-wg] New Draft Document: De-boganising New AddressBlocks References: Message-ID: <403B7D73.7363498D@pipeline.ch> Michael.Dillon at 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 From jon at lawrence.org.uk Tue Feb 24 17:45:32 2004 From: jon at lawrence.org.uk (Jon Lawrence) Date: Tue, 24 Feb 2004 16:45:32 +0000 Subject: [address-policy-wg] New Draft Document: De-boganising New Address Blocks In-Reply-To: <20040224162942.GO1508@reifa-wave.karrenberg.net> References: <20040224162942.GO1508@reifa-wave.karrenberg.net> Message-ID: <200402241645.32714.jon@lawrence.org.uk> > > > 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 From slz at baycix.de Tue Feb 24 17:39:53 2004 From: slz at baycix.de (Sascha Lenz) Date: Tue, 24 Feb 2004 17:39:53 +0100 Subject: [ncc-services-wg] Re: [address-policy-wg] New Draft Document: De-boganising New Address Blocks In-Reply-To: References: Message-ID: <403B7E59.2080902@baycix.de> Hay, Michael.Dillon at 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 at baycix.de = = NOC BayCIX GmbH = = http://www.noc.baycix.de/ * PGP public Key on demand * = ======================================================================== From crain at icann.org Tue Feb 24 20:17:25 2004 From: crain at icann.org (John Crain) Date: Tue, 24 Feb 2004 11:17:25 -0800 Subject: [address-policy-wg] New Draft Document: De-boganising New Address Blocks In-Reply-To: <200402241645.32714.jon@lawrence.org.uk> References: <20040224162942.GO1508@reifa-wave.karrenberg.net> <200402241645.32714.jon@lawrence.org.uk> Message-ID: <403BA345.9050803@icann.org> 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 > From jon at lawrence.org.uk Tue Feb 24 20:41:19 2004 From: jon at lawrence.org.uk (Jon Lawrence) Date: Tue, 24 Feb 2004 19:41:19 +0000 Subject: [address-policy-wg] New Draft Document: De-boganising New Address Blocks In-Reply-To: <403BA345.9050803@icann.org> References: <200402241645.32714.jon@lawrence.org.uk> <403BA345.9050803@icann.org> Message-ID: <200402241941.19385.jon@lawrence.org.uk> 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 From daniel.karrenberg at ripe.net Tue Feb 24 23:02:40 2004 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 24 Feb 2004 23:02:40 +0100 Subject: [address-policy-wg] New Draft Document: De-boganising New Address Blocks In-Reply-To: <200402241941.19385.jon@lawrence.org.uk> References: <200402241645.32714.jon@lawrence.org.uk> <403BA345.9050803@icann.org> <200402241941.19385.jon@lawrence.org.uk> Message-ID: <20040224220240.GA824@dhcp-17.karrenberg.net> 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 From leslien at arin.net Tue Feb 24 23:21:56 2004 From: leslien at arin.net (Leslie Nobile) Date: Tue, 24 Feb 2004 17:21:56 -0500 Subject: [address-policy-wg] REMINDER: ARIN to allocate from 70.0.0.0/8 Message-ID: <004301c3fb24$9ebae9f0$538888c0@arin.net> Hello- This is a reminder that ARIN will begin allocating IP address space from 70.0.0.0/8 in the immediate future. This will include allocations of /20 and shorter prefixes, according to ARIN's minimum allocation policy. You may wish to adjust any filters you have in place accordingly. For informational purposes, a list of ARIN's currently administered IP blocks can be found under "CIDR Blocks" at: http://www.arin.net/statistics/index.html Regards, Leslie Nobile Director, Registration Services American Registry for Internet Numbers (ARIN) From jwkckid1 at ix.netcom.com Wed Feb 25 02:47:59 2004 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Tue, 24 Feb 2004 17:47:59 -0800 Subject: [address-policy-wg] New Draft Document: De-boganising New Address Blocks References: <200402241548.i1OFmce2005266@birch.ripe.net> Message-ID: <403BFECE.7948921C@ix.netcom.com> All Colleagues, I for one along with many of our members are glad to see that RIPE has decided to address this long standing and increasingly irritating issue. It is a shame that ICANN could not have addressed this some 3 years ago... Now if ARIN and other RIR's can start addressing this issue... RIPE NCC WebMaster wrote: > (Apologies for duplicate mails) > > Dear Colleagues, > > The RIPE NCC has prepared a draft document titled "De-Bogonising New > Address Blocks": > > > > Abstract > "This document describes an improvement in the notification process > about new blocks of address space being distributed by the RIRs. It is > a draft at this stage and your comments are solicited. However to gain > experience before finalising the procedures, the RIPE NCC will shortly > start announcing the routes from 84/8 described in the document under > "pilot"." > > This document is published as a draft document in order to give RIPE > NCC members time to read it and provide feedback. > > This draft document can be discussed on the RIPE NCC Services Working > Group mailing list at . > > Regards, > > Webmaster > RIPE NCC 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 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 From jwkckid1 at ix.netcom.com Wed Feb 25 02:53:59 2004 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Tue, 24 Feb 2004 17:53:59 -0800 Subject: [address-policy-wg] New Draft Document: De-boganising New Address Blocks References: <20040224162942.GO1508@reifa-wave.karrenberg.net> Message-ID: <403C0033.96153217@ix.netcom.com> Daniel and all, Daniel Karrenberg wrote: > On 24.02 16:17, Michael.Dillon at 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 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 From kurtis at kurtis.pp.se Wed Feb 25 08:55:13 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Wed, 25 Feb 2004 08:55:13 +0100 Subject: [address-policy-wg] New Draft Document: De-boganising New Address Blocks In-Reply-To: <200402241941.19385.jon@lawrence.org.uk> References: <200402241645.32714.jon@lawrence.org.uk> <403BA345.9050803@icann.org> <200402241941.19385.jon@lawrence.org.uk> Message-ID: -----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----- From jerome.fleury at fr.tiscali.com Tue Feb 24 17:56:13 2004 From: jerome.fleury at fr.tiscali.com (Jerome Fleury) Date: Tue, 24 Feb 2004 17:56:13 +0100 Subject: [address-policy-wg] New Draft Document: De-boganising New AddressBlocks In-Reply-To: <403B7D73.7363498D@pipeline.ch> References: <403B7D73.7363498D@pipeline.ch> Message-ID: <443271380.1077645373@[10.33.50.16]> 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 wrote: > Michael.Dillon at 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 From arjen at euro.net Tue Feb 24 23:08:02 2004 From: arjen at euro.net (Arjen Wolfs) Date: Tue, 24 Feb 2004 23:08:02 +0100 Subject: [address-policy-wg] New Draft Document: De-boganising New Address Blocks In-Reply-To: <20040224220240.GA824@dhcp-17.karrenberg.net> References: <200402241645.32714.jon@lawrence.org.uk> <403BA345.9050803@icann.org> <200402241941.19385.jon@lawrence.org.uk> <20040224220240.GA824@dhcp-17.karrenberg.net> Message-ID: <6.0.1.1.2.20040224230713.03261370@pop.euronet.nl> 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 From daniel.karrenberg at ripe.net Wed Feb 25 15:19:06 2004 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 25 Feb 2004 15:19:06 +0100 Subject: [address-policy-wg] New Draft Document: De-boganising New Address Blocks In-Reply-To: <20040224220240.GA824@dhcp-17.karrenberg.net> References: <200402241645.32714.jon@lawrence.org.uk> <403BA345.9050803@icann.org> <200402241941.19385.jon@lawrence.org.uk> <20040224220240.GA824@dhcp-17.karrenberg.net> Message-ID: <20040225141906.GF824@dhcp-17.karrenberg.net> 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 From daniel.karrenberg at ripe.net Wed Feb 25 15:20:04 2004 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 25 Feb 2004 15:20:04 +0100 Subject: [address-policy-wg] New Draft Document: De-boganising New AddressBlocks In-Reply-To: <443271380.1077645373@[10.33.50.16]> References: <403B7D73.7363498D@pipeline.ch> <443271380.1077645373@[10.33.50.16]> Message-ID: <20040225142004.GG824@dhcp-17.karrenberg.net> 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 From daniel.karrenberg at ripe.net Wed Feb 25 15:21:45 2004 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 25 Feb 2004 15:21:45 +0100 Subject: [address-policy-wg] New Draft Document: De-boganising New Address Blocks In-Reply-To: References: <200402241645.32714.jon@lawrence.org.uk> <403BA345.9050803@icann.org> <200402241941.19385.jon@lawrence.org.uk> Message-ID: <20040225142145.GH824@dhcp-17.karrenberg.net> 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 From oppermann at pipeline.ch Wed Feb 25 16:43:05 2004 From: oppermann at pipeline.ch (Andre Oppermann) Date: Wed, 25 Feb 2004 16:43:05 +0100 Subject: [address-policy-wg] New Draft Document: De-boganising New AddressBlocks References: <00d501c3fbb5$6bc04180$4513180a@amer.cisco.com> Message-ID: <403CC289.985554E4@pipeline.ch> "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 From jon at lawrence.org.uk Wed Feb 25 19:12:13 2004 From: jon at lawrence.org.uk (Jon Lawrence) Date: Wed, 25 Feb 2004 18:12:13 +0000 Subject: [address-policy-wg] New Draft Document: De-boganising New Address Blocks In-Reply-To: <20040225141906.GF824@dhcp-17.karrenberg.net> References: <20040224220240.GA824@dhcp-17.karrenberg.net> <20040225141906.GF824@dhcp-17.karrenberg.net> Message-ID: <200402251812.13631.jon@lawrence.org.uk> 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 From kurtis at kurtis.pp.se Wed Feb 25 21:27:24 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Wed, 25 Feb 2004 21:27:24 +0100 Subject: [address-policy-wg] New Draft Document: De-boganising New Address Blocks In-Reply-To: <20040225142145.GH824@dhcp-17.karrenberg.net> References: <200402241645.32714.jon@lawrence.org.uk> <403BA345.9050803@icann.org> <200402241941.19385.jon@lawrence.org.uk> <20040225142145.GH824@dhcp-17.karrenberg.net> Message-ID: <05B8FB0E-67D1-11D8-970C-000A95928574@kurtis.pp.se> -----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----- From oppermann at pipeline.ch Wed Feb 25 21:30:28 2004 From: oppermann at pipeline.ch (Andre Oppermann) Date: Wed, 25 Feb 2004 21:30:28 +0100 Subject: [address-policy-wg] New Draft Document: De-boganising New AddressBlocks References: <00d501c3fbb5$6bc04180$4513180a@amer.cisco.com> Message-ID: <403D05E4.FEF46DF6@pipeline.ch> 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. > > > > > 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 From jorgen at hovland.cx Wed Feb 25 22:23:48 2004 From: jorgen at hovland.cx (=?ISO-8859-1?Q?J=F8rgen_Hovland?=) Date: Wed, 25 Feb 2004 22:23:48 +0100 (CET) Subject: [ncc-services-wg] Re: [address-policy-wg] New Draft Document: De-boganising New AddressBlocks In-Reply-To: <403D05E4.FEF46DF6@pipeline.ch> References: <00d501c3fbb5$6bc04180$4513180a@amer.cisco.com> <403D05E4.FEF46DF6@pipeline.ch> Message-ID: 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 From gert at space.net Wed Feb 25 23:11:53 2004 From: gert at space.net (Gert Doering) Date: Wed, 25 Feb 2004 23:11:53 +0100 Subject: [ncc-services-wg] Re: [address-policy-wg] New Draft Document: De-boganising New AddressBlocks In-Reply-To: References: <00d501c3fbb5$6bc04180$4513180a@amer.cisco.com> <403D05E4.FEF46DF6@pipeline.ch> Message-ID: <20040225221153.GK8040@Space.Net> 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 at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From bgreene at cisco.com Wed Feb 25 16:38:29 2004 From: bgreene at cisco.com (Barry Greene (bgreene)) Date: Wed, 25 Feb 2004 07:38:29 -0800 Subject: [address-policy-wg] New Draft Document: De-boganising New AddressBlocks In-Reply-To: <443271380.1077645373@[10.33.50.16]> Message-ID: <00d501c3fbb5$6bc04180$4513180a@amer.cisco.com> -----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----- From robt at cymru.com Wed Feb 25 21:00:18 2004 From: robt at cymru.com (Rob Thomas) Date: Wed, 25 Feb 2004 14:00:18 -0600 (CST) Subject: [address-policy-wg] New Draft Document: De-boganising New AddressBlocks In-Reply-To: <00d501c3fbb5$6bc04180$4513180a@amer.cisco.com> References: <00d501c3fbb5$6bc04180$4513180a@amer.cisco.com> Message-ID: 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. 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); From robt at cymru.com Wed Feb 25 21:44:21 2004 From: robt at cymru.com (Rob Thomas) Date: Wed, 25 Feb 2004 14:44:21 -0600 (CST) Subject: [address-policy-wg] New Draft Document: De-boganising New AddressBlocks In-Reply-To: <403D05E4.FEF46DF6@pipeline.ch> References: <00d501c3fbb5$6bc04180$4513180a@amer.cisco.com> <403D05E4.FEF46DF6@pipeline.ch> Message-ID: 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); From michel at arneill-py.sacramento.ca.us Fri Feb 27 05:28:04 2004 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Thu, 26 Feb 2004 20:28:04 -0800 Subject: [address-policy-wg] New Draft Document: De-boganising New AddressBlocks Message-ID: > Rob Thomas wrote: > The reality is that the miscreants are seeing a lower > return on the investment when spoofing from bogon prefixes. Because they are being filtered :-) If more people filtered bogons, the "ROI" would be even lower. Although it is clear that bogon filtering is not a complete cure for spoofing, it does help and it also helps for some spammers. The only negative effect of bogon filtering is not-up-to-date filters, which is why we have written this draft that will expand the applicability domain of bogon route servers and other filtering schemes. Michel. From robt at cymru.com Wed Feb 25 21:00:18 2004 From: robt at cymru.com (Rob Thomas) Date: Wed, 25 Feb 2004 14:00:18 -0600 (CST) Subject: [ncc-services-wg] RE: [address-policy-wg] New Draft Document: De-boganising New AddressBlocks In-Reply-To: <00d501c3fbb5$6bc04180$4513180a@amer.cisco.com> References: <00d501c3fbb5$6bc04180$4513180a@amer.cisco.com> Message-ID: 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. 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);