From Michael.Dillon at radianz.com Wed Jan 21 06:08:08 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Wed, 21 Jan 2004 11:08:08 +0000 Subject: [ppml] Bogons etc... Message-ID: There are various projects out there which try to address the issue of which IP address ranges should be visible on the Internet. The major one that many of you will know of is Team Cymru's Bogon Route Server project http://www.cymru.com/BGP/bogon-rs.html This project tries to track an announce IP address ranges which should not be visible on the Internet, i.e. bogons. There is another project found at http://69box.atlantic.net which deals with a related but somewhat opposite issue. This project deals with making sure that IP address ranges which should be visible on the Internet are indeed functioning. It seems to me that this kind of project is something that should be coming from ARIN or the RIRs jointly. For the past few years we have not had any overall RIR coordinating body. IANA has withered away to becoming a minor administrative function performed by ICANN under contract to the DoC. IANA can no longer play a role in making policy and it can no longer fulfill its part in the appeals process mentioned in RFC 2050. At the same time, ICANN has been embroiled in all sorts of issues that arise from its oversight of the domain naming system. Now that the NRO memorandum has been signed, there is the possibility that we might have a place to discuss and agree on joint RIR actions for things that affect the entire IP addressing system like bogons. Does anyone else agree with me that we should be looking for a way to incorporate the bogon-related work into ARIN and the other RIRs? In other words, should ARIN (and the other RIRs) publish a real-time up-to-date directory of all IP address ranges currently allocated to someone and all IP address ranges not currently in use in a form that could replace the bogon route server and 69box.atlantic.net? --Michael Dillon From jeroen at unfix.org Wed Jan 21 06:39:00 2004 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 21 Jan 2004 12:39:00 +0100 Subject: [ppml] Bogons etc... In-Reply-To: Message-ID: <004e01c3e013$2a62e2f0$210d640a@unfix.org> -----BEGIN PGP SIGNED MESSAGE----- Michael.Dillon at radianz.com wrote: > There are various projects out there which try to address the > issue of > which IP address ranges should be visible on the Internet. The major > one that many of you will know of is Team Cymru's Bogon Route > Server project http://www.cymru.com/BGP/bogon-rs.html Indeed Team Cymru is doing a great job. Even though ARIN doesn't have a system in place, RIPE has RIS (http://ris.ripe.net) Next to that another very important one is Netlantis which takes another angle into the RIS setup and they even share a Route Collector, see http://www.netlantis.org Netlantis is, in part, sponsored by RIPE. Next to that another important one is ofcourse William Leibzon's Completewhois at http://www.completewhois.com/ For IPv6 I have been showing the problems at the last couple of RIPE meetings in Amsterdam using my GRH tool which can be found at http://www.sixxs.net/tools/grh/ Gert Doering has been doing anomaly checking for quite some time longer and has also been presenting that at the various RIPE meetings. What I personally would rather see is a global list where these problems can be discussed. Usually I notify people directly but I'd rather see a mailinglist where people who want to get notice of these problems can join and get it. NANOG, though globally watched, doesn't have a complete worldwide audience for instance and is revolving around the US and not around Asia or Europe. Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / http://unfix.org/~jeroen iQA/AwUBQA5k1CmqKFIzPnwjEQLkKQCeNo3Kn9rUtQCNXO3pWmZfMIa8vQsAn0M8 8z99XmGlsL395Ds/16rJzEGJ =H33I -----END PGP SIGNATURE----- From ibaker at codecutters.org Wed Jan 21 06:57:01 2004 From: ibaker at codecutters.org (Ian Baker) Date: Wed, 21 Jan 2004 11:57:01 -0000 Subject: [ppml] Bogons etc... References: Message-ID: <012501c3e015$adfb52d0$642fa8c0@codecutters.org> ----- Original Message ----- From: To: Sent: Wednesday, January 21, 2004 11:08 AM Subject: [ppml] Bogons etc... > There are various projects out there which try to address the issue of > which IP address ranges should be visible on the Internet. The major > one that many of you will know of is Team Cymru's Bogon Route > Server project http://www.cymru.com/BGP/bogon-rs.html > This project tries to track an announce IP address ranges which > should not be visible on the Internet, i.e. bogons. There is another > project found at http://69box.atlantic.net which deals with a related > but somewhat opposite issue. This project deals with making sure > that IP address ranges which should be visible on the Internet are > indeed functioning. > > It seems to me that this kind of project is something that should > be coming from ARIN or the RIRs jointly. It's an interesting idea, but very open-ended in terms of resource required. What were you thinking of as incentives for ISPs etc. to stop the leakage? Fines? Regards, Ian Baker Webmaster, codecutters.org From jmcburnett at msmgmt.com Wed Jan 21 07:32:25 2004 From: jmcburnett at msmgmt.com (McBurnett, Jim) Date: Wed, 21 Jan 2004 07:32:25 -0500 Subject: [ppml] Bogons etc... Message-ID: <9BF6F06C4BC90746ADD6806746492A33690F8F@msmmail01.msmgmt.com> reward for ISP's HMMM.. Ya know if ARIN did this, this then gives them to ability to "recall" IP space.. If the major ISP's sign on, and a IP block is hijacked and then proven. ARIN places that block in the BOGON filter the MAJOR ISP's stop routing it and we solve hijacking, "leaked" blocks and do it from an administrative body. Thoughts? J -----Original Message----- From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of Ian Baker Sent: Wednesday, January 21, 2004 6:57 AM To: ppml at arin.net Subject: Re: [ppml] Bogons etc... ----- Original Message ----- From: To: Sent: Wednesday, January 21, 2004 11:08 AM Subject: [ppml] Bogons etc... > There are various projects out there which try to address the issue of > which IP address ranges should be visible on the Internet. The major > one that many of you will know of is Team Cymru's Bogon Route > Server project http://www.cymru.com/BGP/bogon-rs.html > This project tries to track an announce IP address ranges which > should not be visible on the Internet, i.e. bogons. There is another > project found at http://69box.atlantic.net which deals with a related > but somewhat opposite issue. This project deals with making sure > that IP address ranges which should be visible on the Internet are > indeed functioning. > > It seems to me that this kind of project is something that should > be coming from ARIN or the RIRs jointly. It's an interesting idea, but very open-ended in terms of resource required. What were you thinking of as incentives for ISPs etc. to stop the leakage? Fines? Regards, Ian Baker Webmaster, codecutters.org From ibaker at codecutters.org Wed Jan 21 08:03:43 2004 From: ibaker at codecutters.org (Ian Baker) Date: Wed, 21 Jan 2004 13:03:43 -0000 Subject: [ppml] Bogons etc... References: <9BF6F06C4BC90746ADD6806746492A33690F8F@msmmail01.msmgmt.com> Message-ID: <019d01c3e01e$ff5b7390$642fa8c0@codecutters.org> ----- Original Message ----- From: "McBurnett, Jim" To: "Ian Baker" ; Sent: Wednesday, January 21, 2004 12:32 PM Subject: RE: [ppml] Bogons etc... reward for ISP's HMMM.. Ya know if ARIN did this, this then gives them to ability to "recall" IP space.. If the major ISP's sign on, and a IP block is hijacked and then proven. ARIN places that block in the BOGON filter the MAJOR ISP's stop routing it and we solve hijacking, "leaked" blocks and do it from an administrative body. The thought certainly crossed my mind, but the overall programme would still need funding (hence the thought about fines). The situation would probably be even worse for people like LACNIC & APNIC, who are that much smaller. Remember - there's also a complete grievance and appeals procedure to fund (a gigantic ISP might be unhappy at being taken offline from a single mistake by a contractor; as might their customers!) The principle's great, but.. lots of details that need to function consistently, the world over. Regards, Ian -----Original Message----- From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of Ian Baker Sent: Wednesday, January 21, 2004 6:57 AM To: ppml at arin.net Subject: Re: [ppml] Bogons etc... ----- Original Message ----- From: To: Sent: Wednesday, January 21, 2004 11:08 AM Subject: [ppml] Bogons etc... > There are various projects out there which try to address the issue of > which IP address ranges should be visible on the Internet. The major > one that many of you will know of is Team Cymru's Bogon Route > Server project http://www.cymru.com/BGP/bogon-rs.html > This project tries to track an announce IP address ranges which > should not be visible on the Internet, i.e. bogons. There is another > project found at http://69box.atlantic.net which deals with a related > but somewhat opposite issue. This project deals with making sure > that IP address ranges which should be visible on the Internet are > indeed functioning. > > It seems to me that this kind of project is something that should > be coming from ARIN or the RIRs jointly. It's an interesting idea, but very open-ended in terms of resource required. What were you thinking of as incentives for ISPs etc. to stop the leakage? Fines? Regards, Ian Baker Webmaster, codecutters.org From jmcburnett at msmgmt.com Wed Jan 21 08:57:35 2004 From: jmcburnett at msmgmt.com (McBurnett, Jim) Date: Wed, 21 Jan 2004 08:57:35 -0500 Subject: [ppml] Bogons etc... Message-ID: <9BF6F06C4BC90746ADD6806746492A339F7EBB@msmmail01.msmgmt.com> . -> ->The thought certainly crossed my mind, but the overall ->programme would still ->need funding (hence the thought about fines). The situation ->would probably ->be even worse for people like LACNIC & APNIC, who are that ->much smaller. -> ->Remember - there's also a complete grievance and appeals ->procedure to fund ->(a gigantic ISP might be unhappy at being taken offline from a single ->mistake by a contractor; as might their customers!) -> ->The principle's great, but.. lots of details that need to function ->consistently, the world over. -> ->Regards, -> ->Ian let's talk about this for a second: What does TEAM CYMRU do? Can it be scaleable? If 4 volenteers do it now and keep it going, why would you need more than 2 full timers? Ya know so #1 can go on vacation? And does it even need to be full timers? ARIN has a website, and a network, can the net admin do BGP? How would it take a whole ISP offline? IE can you really see 12.0.0.0/8 added as a bogon? (Sorry AT&T, it was the first IP block I could think of) Details, well maybe this should be a thought for the ARIN meeting? Or maybe the wishful dinner conversation? Or maybe a thought and RFC from the IETF? Something should be done! Later, Jim From ibaker at codecutters.org Wed Jan 21 09:27:54 2004 From: ibaker at codecutters.org (Ian Baker) Date: Wed, 21 Jan 2004 14:27:54 -0000 Subject: [ppml] Bogons etc... References: <9BF6F06C4BC90746ADD6806746492A339F7EBB@msmmail01.msmgmt.com> Message-ID: <01e701c3e02a$ccad8d00$642fa8c0@codecutters.org> ----- Original Message ----- From: "McBurnett, Jim" To: "Ian Baker" ; Sent: Wednesday, January 21, 2004 1:57 PM Subject: RE: [ppml] Bogons etc... >-> >->The thought certainly crossed my mind, but the overall >->programme would still >->need funding (hence the thought about fines). The situation >->would probably >->be even worse for people like LACNIC & APNIC, who are that >->much smaller. >-> >->Remember - there's also a complete grievance and appeals >->procedure to fund >->(a gigantic ISP might be unhappy at being taken offline from a single >->mistake by a contractor; as might their customers!) >-> >->The principle's great, but.. lots of details that need to function >->consistently, the world over. >let's talk about this for a second: >What does TEAM CYMRU do? >Can it be scaleable? >If 4 volenteers do it now and keep it going, why would you need more than >2 full timers? Ya know so #1 can go on vacation? It's a few more than four volunteers.. might not take many people (for updates - I suspect that a rationalization of current data might take a little more work). Heck, I even have something that could probably be adapted to do it.. might be interesting to see how many empty blocks there are if one includes micro-allocations. >And does it even need to be full timers? >ARIN has a website, and a network, can the net admin do BGP? >How would it take a whole ISP offline? IE can you really see 12.0.0.0/8 added as a >bogon? (Sorry AT&T, it was the first IP block I could think of) Possibly - it depends on how "harsh" the rules are. Do we let off large ISPs (all of those Trojaned home weenies) and hammer small companies? Hmm. Probably just my reaction to some of the badly-worded laws that have been appearing in the UK just recently (e.g. when they banned mobile phone handset use in cars, did they /really/ intend to fine drivers that lock the phone in the glovebox? The law reads that way.. and has apparently already been applied. If you believe what you read in the papers) >Details, well maybe this should be a thought for the ARIN meeting? >Or maybe the wishful dinner conversation? >Or maybe a thought and RFC from the IETF? Here's what I have at the moment: o We have a technical observation that could potentially have a noticeable benefit to the Internet community as a whole o We're not yet sure what size of list we would need to implement (I might be able to help there, when I get time. GeoLyse lists about 1.9 million allocated blocks worldwide - the next time I do a rebuild, I'll see if I can write something that checks for gaps) o While it's not possible to define revenue-neutral funding requirements without knowing the size of the problem, it might be worth discussing possible mechanisms o (Possibly the bit where we're taking different views on the proposal) do we limit the list to specific unallocated blocks, or include "leakage" of invalid/reserved/private traffic from allocated blocks? There are potential legal and financial implications for ARIN members. o There needs to be some form of "punishment" for people who violate. This has to be legally watertight, to prevent any loss-of-revenue lawsuits in the event of erroneous blocking. o If it's to work, then it needs to be world-wide (which implies an RFC, in my view) o Discuss.. Regards, Ian Baker Webmaster, codecutters.org From Michael.Dillon at radianz.com Wed Jan 21 10:22:55 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Wed, 21 Jan 2004 15:22:55 +0000 Subject: [ppml] Bogons etc... Message-ID: >let's talk about this for a second: >What does TEAM CYMRU do? >Can it be scaleable? I think that they compile and maintain a small directory and publish that directory via BGP. >How would it take a whole ISP offline? IE can you really see 12.0.0.0/8 added as a >bogon? (Sorry AT&T, it was the first IP block I could think of) I'm only suggesting that ARIN and the other RIRs take on the task of compiling and maintaining and publishing the directory. I think it would be an excellent idea for every ISP to accept a live realtime feed of this directory whether through BGP or through LDAP. However, I think it would be extremely foolish for any ISP to hook this feed directly to their core routers. Of course, if the feed is published by some means other than BGP then it makes it almost impossible for anyone to hold ARIN liable for the effect on someones core network. --Michael Dillon From michel at arneill-py.sacramento.ca.us Wed Jan 21 10:22:23 2004 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Wed, 21 Jan 2004 07:22:23 -0800 Subject: [ppml] Bogons etc... Message-ID: > Ian Baker wrote: > Or maybe a thought and RFC from the IETF? This does not appear to be a good idea at the time; there is IETF work ongoing WRT the issue, however it's in the realm of enhancing the distribution of filtering information (much needed for really efficient of bogon route-servers), not about regulating the who filters bogons and why. More info here: http://arneill-py.sacramento.ca.us/draft-py-idr-redisfilter-01.txt http://arneill-py.sacramento.ca.us/redisfilter.pdf http://arneill-py.sacramento.ca.us/redisfilter.ppt It appears to me that at this time the RIRs' involvement should be on perfecting the mechanism. Michel. From Michael.Dillon at radianz.com Wed Jan 21 10:25:55 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Wed, 21 Jan 2004 15:25:55 +0000 Subject: [ppml] Bogons etc... Message-ID: >o There needs to be some form of "punishment" for people who violate. This >has to be legally watertight, to prevent any loss-of-revenue lawsuits in the >event of erroneous blocking. Things like recall and punishments are really a separate policy issue. Right now I'd like to focus on just getting an authoritative and up to date listing made available so that people have the opportunity to do the right thing. --Michael Dillon From michel at arneill-py.sacramento.ca.us Wed Jan 21 10:39:11 2004 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Wed, 21 Jan 2004 07:39:11 -0800 Subject: [ppml] Bogons etc... Message-ID: > Michael.Dillon at radianz.com wrote: > However, I think it would be extremely foolish for any > ISP to hook this feed directly to their core routers. Without having a chance to check it first, indeed. However, this is not the issue. Why did we have problems with 69/8 and why do we have problems with 70/8? Not because the list of bogons is difficult to find. It's not. It's because it takes time for any large organization to update their bogon filters on all their routers. Which is why what we need is a good distribution mechanism of the bogons. http://arneill-py.sacramento.ca.us/draft-py-idr-redisfilter-01.txt Which will also allow more granular filtering than bogons. > Things like recall and punishments are > really a separate policy issue. Indeed. > Right now I'd like to focus on just getting an > authoritative and up to date listing made > available so that people have the opportunity > to do the right thing. http://www.cymru.com/Bogons/index.html I'm using the real-time BGP feed myself, works for me. The cymru team is not immune to errors, but neither am I. Michel. From bicknell at ufp.org Wed Jan 21 11:30:04 2004 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 21 Jan 2004 11:30:04 -0500 Subject: [ppml] Bogons etc... In-Reply-To: References: Message-ID: <20040121163004.GA32398@ussenterprise.ufp.org> In a message written on Wed, Jan 21, 2004 at 11:08:08AM +0000, Michael.Dillon at radianz.com wrote: > Does anyone else agree with me that we should be looking for a way > to incorporate the bogon-related work into ARIN and the other RIRs? I'd like to see the efforts to get the RIR's involved go in a different direction. Borrowing from the distributed is good playbook, having one entity tell me what is bad globally is not a good solution. Indeed, having anyone tell me what is bad is problematic, because no one person controls it all. The RIR's do know what is "good", at least for their part of the resource space. The problem is that what is good is not published in readily available scriptable form. Further, I think the place to do this is with DNS, much like many of the spam black lists. A top level should be set aside (allocated?) and delegated as appropriate. For instance, ARIN might be delegated 70.allocated. Further, ARIN may choose to return simply the whole thing as valid, or to return sub-information, including but not limited to: 1.70.allocated. TXT "allocated" - This block has been allocated. 70.allocated. TXT "prefixlength 13 22" - Minimum /13, maximum /22's. TXT "allocated" 2.70.allocated. TXT "whois NET-MYISP-CONTACTS" TXT "allocated" Allow ISP's to secondary. Convince some router vendors that: ip prefix-list dns check-allocated check-length Is a good idea. This would give us a fully distributed system, based on positive information. It could be easily scripted, easily added to router code, and easily integrated with existing anti-spam solutions. Granted, there are a whole lot more details (what the records can and can't say, txt vrs ptr with special IP's, etc), and they should be done in a written standard, across RIR's, but I think the information can easily fit in DNS, there is precident (anti-spam stuff), it's easy to use and understand, it's distributed, and it can be easily mirrored locally by ISP's to take the load off the RIR's. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From michel at arneill-py.sacramento.ca.us Wed Jan 21 11:49:48 2004 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Wed, 21 Jan 2004 08:49:48 -0800 Subject: [ppml] Bogons etc... Message-ID: I don't think tossing DNS in the middle of this is a good idea. It's a layer violation, and it creates a circular reference issue. Michel. -----Original Message----- From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On Behalf Of Leo Bicknell Sent: Wednesday, January 21, 2004 8:30 AM To: ppml at arin.net Subject: Re: [ppml] Bogons etc... In a message written on Wed, Jan 21, 2004 at 11:08:08AM +0000, Michael.Dillon at radianz.com wrote: > Does anyone else agree with me that we should be looking for a way > to incorporate the bogon-related work into ARIN and the other RIRs? I'd like to see the efforts to get the RIR's involved go in a different direction. Borrowing from the distributed is good playbook, having one entity tell me what is bad globally is not a good solution. Indeed, having anyone tell me what is bad is problematic, because no one person controls it all. The RIR's do know what is "good", at least for their part of the resource space. The problem is that what is good is not published in readily available scriptable form. Further, I think the place to do this is with DNS, much like many of the spam black lists. A top level should be set aside (allocated?) and delegated as appropriate. For instance, ARIN might be delegated 70.allocated. Further, ARIN may choose to return simply the whole thing as valid, or to return sub-information, including but not limited to: 1.70.allocated. TXT "allocated" - This block has been allocated. 70.allocated. TXT "prefixlength 13 22" - Minimum /13, maximum /22's. TXT "allocated" 2.70.allocated. TXT "whois NET-MYISP-CONTACTS" TXT "allocated" Allow ISP's to secondary. Convince some router vendors that: ip prefix-list dns check-allocated check-length Is a good idea. This would give us a fully distributed system, based on positive information. It could be easily scripted, easily added to router code, and easily integrated with existing anti-spam solutions. Granted, there are a whole lot more details (what the records can and can't say, txt vrs ptr with special IP's, etc), and they should be done in a written standard, across RIR's, but I think the information can easily fit in DNS, there is precident (anti-spam stuff), it's easy to use and understand, it's distributed, and it can be easily mirrored locally by ISP's to take the load off the RIR's. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org From Michael.Dillon at radianz.com Wed Jan 21 12:05:33 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Wed, 21 Jan 2004 17:05:33 +0000 Subject: [ppml] Bogons etc... Message-ID: >Further, I think the place to do this is with DNS, much like many >of the spam black lists. I think we need to agree on the principle first, then sort out what will be published and only then decide on the mechanism for publishing. Today we use the horribly broken whois protocol and the much better (but somewhat obscure) BGP protocol and the ubiquitous (but primitive) DNS protocol. The IETF has also done a lot of work on creating a scalable directory access protocol (LDAP) that is widely deployed in corporate networks but strangely ignored on the Internet. In any case, like you, I'd like to see a mechanism that is scriptable by all concerned. Whois has show that it can't do that consistently. We've seen text parsing problems on both the server end and the client end. DNS, BGP and LDAP all potentially solve the parsing problems and all are scriptable. My personal opinion is that LDAP would be a better solution because it supports schemas which makes it darn near impossible to create a parsing problem. Anyone can set up a box with BIND or Zebra or OpenLDAP to receive a data feed and integrate it with their internal systems. If we stick to DNS and LDAP then it is easy to turn any Python/Perl/TCL/Ruby script into a DNS or LDAP client so there is even less infrastructure required. But what do we publish? Who is responsible? What are the limits? That's where we need some policy work to be done. --Michael Dillon From michel at arneill-py.sacramento.ca.us Wed Jan 21 12:41:15 2004 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Wed, 21 Jan 2004 09:41:15 -0800 Subject: [ppml] Bogons etc... Message-ID: > Michael.Dillon at radianz.com > DNS, BGP and LDAP all potentially solve the parsing > problems and all are scriptable. My personal opinion > is that LDAP would be a better solution because it > supports schemas which makes it darn near impossible > to create a parsing problem. Keep in mind though that the idea is to filter "bad" routes, which means BGP4 because that's the mechanism they are handled and this is not going to change. So an LDAP-based solution would ultimately have to hook with BGP anyway. Given the fact that the LDAP solution would require one more box and one more protocol that would need to be managed, and that the LDAP-to-BGP mechanism does not event exist as of today, please explain me what makes the LDAP solution so superior to the BGP solution that it balances the two pitfalls I just mentioned. Michel. From bicknell at ufp.org Wed Jan 21 12:59:42 2004 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 21 Jan 2004 12:59:42 -0500 Subject: [ppml] Bogons etc... In-Reply-To: References: Message-ID: <20040121175942.GA37240@ussenterprise.ufp.org> In a message written on Wed, Jan 21, 2004 at 05:05:33PM +0000, Michael.Dillon at radianz.com wrote: > But what do we publish? Who is responsible? What > are the limits? Agreed. To that end, I believe each RIR should publish the data that they control. I believe the only sticky issue that leaves is some of the "legacy" we-control-but-don't-control things ARIN inherited, and for those I think they should publsh the data as well. A minimum set of data should be what is "in use" (which does leave a little room for if a /8 is good enough, or if they should be more specific, a /8 is a fine starting point though), and what is the length of assignments the RIR made from that block. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From Michael.Dillon at radianz.com Wed Jan 21 13:02:33 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Wed, 21 Jan 2004 18:02:33 +0000 Subject: [ppml] Bogons etc... Message-ID: >Keep in mind though that the idea is to filter "bad" routes, which means >BGP4 because that's the mechanism they are handled and this is not going >to change. No, no, no. The idea is to publish authoritative information about IP address blocks. This is the ARIN public policy mailing list and we don't do route filtering here. > So an LDAP-based solution would ultimately have to hook with > BGP anyway. Precisely why LDAP is better for publishing the directory than using BGP4. With BGP4 the temptation is there to plug the directory right into core routers. With LDAP you would plug it into your ticketing system and some human being would make a judgement on how quickly the changes should be integrated into your network. > Given the fact that the LDAP solution would require one more > box It does not *REQUIRE* one more box. If you *choose* to run an OpenLDAP server (or a Zebra server or a BIND server) then you might also *choose* to run it on a brand-new standalone box. But you also might *choose* to write a Python/Perl/TCL/Ruby script that polls the ARIN directory server periodically looking for updates. > and one more protocol that would need to be managed, If your company is bigger than a handful of people then you are probably already running LDAP internally. In any case, nobody adds staff just because they are running another protocol. Who manages AIM in your company? ICQ? SOAP? XML-RPC? SIP? > and that the > LDAP-to-BGP mechanism does not event exist as of today, The mechanism exists today. It's called Python/Perl/TCL/Ruby otherwise known as scripting language glue. And even if we do decide to retain BGP4 as the publishing mechanism, a prudent network operator will still integrate it into their network using scripting glue, i.e. a BGP-to-BGP mechanism. > please explain >me what makes the LDAP solution so superior to the BGP solution >that it balances the two pitfalls I just mentioned. It was designed for the job of publishing directories. It's proven to be scalable to very large global networks. There is a lot more LDAP expertise out there if you don't count the router geeks and I don't count them because they are generally not responsible for maintaining and integrating servers and systems. Oh, and all the major scripting languages have libraries that allow you to add LDAP client capability to any tools you currently have. --Michael Dillon From bicknell at ufp.org Wed Jan 21 13:01:57 2004 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 21 Jan 2004 13:01:57 -0500 Subject: [ppml] Bogons etc... In-Reply-To: References: Message-ID: <20040121180157.GB37240@ussenterprise.ufp.org> In a message written on Wed, Jan 21, 2004 at 09:41:15AM -0800, Michel Py wrote: > Keep in mind though that the idea is to filter "bad" routes, which means That is one idea. I don't see it as the only idea. Many people filtering spam would make use of a service that accurately listed "dark" space, so even if someone was able to get it routed server admins could drop mail from it. Firewall admins would like to use it for packet filtering, not route filtering. Statistics people would like to use it to match traffic as seen on the net with source RIR, company, whatever. Making it easy to get into BGP is necessary, but far from sufficient. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From adb at onramp.ca Wed Jan 21 13:11:37 2004 From: adb at onramp.ca (Anthony DeBoer) Date: Wed, 21 Jan 2004 13:11:37 -0500 Subject: [ppml] Bogons etc... In-Reply-To: ; from Michael.Dillon@radianz.com on Wed, Jan 21, 2004 at 05:05:33PM +0000 References: Message-ID: <20040121131137.L32741@onramp.ca> Michael.Dillon at radianz.com wrote: > DNS, BGP and LDAP all potentially solve the parsing problems > and all are scriptable. My personal opinion is that LDAP would > be a better solution because it supports schemas which makes it > darn near impossible to create a parsing problem. Aaaaurgh, keep it simple! This is fundamentally a BGP issue; if your router doesn't have any bogus routes and is running defaultless, then all such packets nicely fall into the bit bucket. Accomplishing that state of affairs is something already being addressed by the RADB, Cymru, the redisfilter draft, and such. Ideally such routes (misconfigurations or stolen space) don't make it all the way across the backbone and into most peoples' routing tables, and ideally this can happen without having to touch the majority of router configs in the field either. Injecting selected overriding-blackhole routes in the language already spoken by BGP routers is preferable to coding new protocols, and keeping it dynamic avoids having legacy configs on routers that don't play well with current reality. Actually talking to providers injecting the bogons might be an idea too. I shouldn't need to care whether 70/8 is allocated or not; when it is, valid routes should show up for it. End of story. On the flip side, bogus addresses in the source side of the packet are still best addressed by source filtering; DoS packets allegedly sourced from a victim's server's legitimate address do a lot more damage than packets allegedly sourced from la-la land. -- Anthony DeBoer Onramp Technical Support From HRyu at norlight.com Wed Jan 21 13:27:08 2004 From: HRyu at norlight.com (Hyunseog Ryu) Date: Wed, 21 Jan 2004 12:27:08 -0600 Subject: [ppml] Bogons etc... Message-ID: As far as I understand, RIR should be working from policy side, not operational side. If we want to push RIRs to maintain operational aspect, there will be questions regarding responsibility, service reliability, etc. If RIRs work together to have consolidated list of bogon IP addresses, that will be great. But having RIRs running operational service using those info is not desirable, I believe. CYMRU's bogon BGP peering or its own in-house tools for bogon is responsibility by ISP or customer's its own responsibility. Do we want to address filtering issues using another protocol? I think that's overuse of protocols. For information for accurate bogon list info, I welcome RIR's involvement to publish those info. But for operational side, I think RIR should not be involved. Hyun ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Hyunseog Ryu / CCDA, MCSE, CCIE candidate(written test passed) Senior Network Engineer/Applications Engineering Norlight Telecommunications, Inc. 13935 Bishops Drive Brookfield, WI 53005 Tel. +1.262.792.7965 Fax. +1.262.792.7733 email: hryu at norlight.com From michel at arneill-py.sacramento.ca.us Wed Jan 21 13:43:45 2004 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Wed, 21 Jan 2004 10:43:45 -0800 Subject: [ppml] Bogons etc... Message-ID: > Michael.Dillon at radianz.com wrote: > No, no, no. > The idea is to publish authoritative information about > IP address blocks. This is the ARIN public policy mailing > list and we don't do route filtering here. I understand this, but what is the ultimate goal of publishing this? Route filtering. Publishing for the sake of publishing does not serve any purpose. Besides the fact that it would be re-inventing a wheel that we are already using operationally, what good does it do if its format is not compatible with what is used operationally. > Precisely why LDAP is better for publishing the directory > than using BGP4. With BGP4 the temptation is there to plug > the directory right into core routers. Indeed. And by the way it's never been a directory, it's always been a prefix-list. > With LDAP you would plug it into your ticketing system and > some human being would make a judgement on how quickly the > changes should be integrated into your network. Which precisely is what's broken today, and generates all these issues with 69/8 and 70/8. This DOES NOT work, we know it because it's driving people nuts TODAY. Bottom line is: present your LDAP idea at NANOG and see what you get as feedback. The mission of the RIRs is not to tell operators how to run their networks, and operators want to filter with BGP4 and not with LDAP. Michel. From leo at ripe.net Wed Jan 21 13:47:14 2004 From: leo at ripe.net (leo vegoda) Date: Wed, 21 Jan 2004 19:47:14 +0100 Subject: [ppml] Bogons etc... In-Reply-To: <20040121163004.GA32398@ussenterprise.ufp.org> References: <20040121163004.GA32398@ussenterprise.ufp.org> Message-ID: <3A9C4241-4C42-11D8-B6A8-000A95DAB530@ripe.net> Hi Leo, On Jan 21, 2004, at 5:30 pm, Leo Bicknell wrote: [...] > The RIR's do know what is "good", at least for their part of the > resource space. The problem is that what is good is not published > in readily available scriptable form. All the RIRs publish stats on what's been allocated and assigned. There's a standard format and location for the information with a file explaining the details. In addition to this, the RIPE NCC publishes a plain, vanilla list of ranges we've allocated or assigned (no dates or other information). You can pull this information (and some perl to do stuff with it) from our FTP site at: Regards, -- leo vegoda Registration Services Manager RIPE NCC From michel at arneill-py.sacramento.ca.us Wed Jan 21 13:56:06 2004 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Wed, 21 Jan 2004 10:56:06 -0800 Subject: [ppml] Bogons etc... Message-ID: > Leo Bicknell > Many people filtering spam would make use of a service that > accurately listed "dark" space, so even if someone was able > to get it routed server admins could drop mail from it. The idea is not to route it in the first place. Besides, it probably already exists on some RBLs. > Firewall admins would like to use it for packet > filtering, not route filtering. Packet filtering is what routers are for, and a BGP bogon feed does indeed make it very simple, as you can route to null0 all the bogons. I do this already operationally, I can discard that traffic even before the firewall. Michel. From jmcburnett at msmgmt.com Wed Jan 21 14:02:17 2004 From: jmcburnett at msmgmt.com (McBurnett, Jim) Date: Wed, 21 Jan 2004 14:02:17 -0500 Subject: [ppml] Bogons etc... Message-ID: <9BF6F06C4BC90746ADD6806746492A33690F99@msmmail01.msmgmt.com> This brings to mind another project I saw, DDoS filtering via BGP feed.... BGP input and then OSPF or RIP or EIGRP redis to firewall etc.. IE I pull it in to a small "one-armed" router sitting on the network and then redis to other specific points... in some cases I may not want to prevent some traffic from certain parts of my network, but want it filtered on other parts. Later, J ->-----Original Message----- ->From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of ->Michel Py ->Sent: Wednesday, January 21, 2004 1:56 PM ->To: Leo Bicknell; ppml at arin.net ->Subject: RE: [ppml] Bogons etc... -> -> ->> Leo Bicknell ->> Many people filtering spam would make use of a service that ->> accurately listed "dark" space, so even if someone was able ->> to get it routed server admins could drop mail from it. -> ->The idea is not to route it in the first place. Besides, it probably ->already exists on some RBLs. -> ->> Firewall admins would like to use it for packet ->> filtering, not route filtering. -> ->Packet filtering is what routers are for, and a BGP bogon feed does ->indeed make it very simple, as you can route to null0 all the ->bogons. I ->do this already operationally, I can discard that traffic even before ->the firewall. -> ->Michel. -> From william at elan.net Wed Jan 21 16:29:04 2004 From: william at elan.net (william at elan.net) Date: Wed, 21 Jan 2004 13:29:04 -0800 (PST) Subject: [ppml] Bogons etc... In-Reply-To: Message-ID: On Wed, 21 Jan 2004 Michael.Dillon at radianz.com wrote: > >Further, I think the place to do this is with DNS, much like many > >of the spam black lists. Its been done with dns, works fine (except cases when RIRs abroptly change location of their data files and notify about it several days later). If you're interested try bogons.dnsiplists.completewhois.com (it'll report 127.0.0.2 for all unallocated ips) > think we need to agree on the principle first, then > sort out what will be published and only then decide on > the mechanism for publishing. RIRs are already publishing such information using "statistics files" for that, see ftp://ftp.arin.net/pub/stats/ This data is ok for new space allocated by RIRs but have number of serious mistakes for legacy spaces. I track it down on daily basis in automated way as far as inaccuraces between RIR whois and RIR statistics files, see http://www.completewhois.com/bogons/ipwhois_data_analysis.htm I'll cleanup my code and release utility to convert statistics files to bogon list in the next couple month as part of larger ip list conversion utility that I'll release as gnu open source code. > Today we use the horribly broken whois protocol and > the much better (but somewhat obscure) BGP protocol BGP protocol is locking necessary tools to be able to correctly use bogon feed (Cymru approach is a hack and causes pains to setup). There is a draft ready, see http://arneill-py.sacramento.ca.us/draft-py-idr-redisfilter-00.txt and we're just waiting for vendors to implement it. Once done you'll see not only bogon feeds but other feeds as well, such as for spam filtering. > the ubiquitous (but primitive) DNS protocol. The IETF has > also done a lot of work on creating a scalable directory > access protocol (LDAP) that is widely deployed in corporate > networks but strangely ignored on the Internet. Its not hard to publish such list in LDAP, the question is if it would be used? There are no tools that change router config based on LDAP data, and to my knowledge firewalls do not have such tools for LDAP feed either, nor mail server software, etc. > In any case, like you, I'd like to see a mechanism that > is scriptable by all concerned. Whois has show that it > can't do that consistently. We've seen text parsing problems > on both the server end and the client end. There is RPSL definition for whois datathat is next layer up above whois protocol. RPSL is used for routing database (as published by ARIN for example) and is easily parseable and there are tools to convert this to be used for router configurations and firewall configurations. Publishing information by RPSL is a good idea that ARIN should consider doing instead of continuing to use its own non-standard WHOIS format (note: RIPE, APNIC, LACNIC are all using RPSL for whois data). As far as bogons, I've floated idea around to work on special filtering definition for that (current ones can be used if its plain IANA-only bogons as cymru is doing, but full list of unallocated blocks as RIRs are publishing in statistics files is too large and requires some new approach). There were not enough volunteers when I first mentioned in at NANOG to work on it, but if people are interested I have mailing list setup for just that purposes and I want to finish this approach as well. I would not be against if RIRs started doing some kind of route database publishing of bogon lists afterwards (considering that each RIR, except LACNIC, already is maintaining routing database for its users). > DNS, BGP and LDAP all potentially solve the parsing problems > and all are scriptable. My personal opinion is that LDAP would > be a better solution because it supports schemas which makes it > darn near impossible to create a parsing problem. > > Anyone can set up a box with BIND or Zebra or OpenLDAP to receive > a data feed and integrate it with their internal systems. Please do it. And release such software as open source and have at least two confirmed users (besides your own). After that come back here or to me personally and I promise you LDAP bogon feed will be ready in less then a week. > If we stick to DNS and LDAP then it is easy to turn any > Python/Perl/TCL/Ruby script into a DNS or LDAP client so there > is even less infrastructure required. Talking about writing software is easy, actually doing is not. > But what do we publish? Who is responsible? What > are the limits? > > That's where we need some policy work to be done. ARIN never liked idea of policies that effect what it considers to be its operations (most of my whois ideas never went through policy process). -- William Leibzon Elan Networks william at elan.net From jlewis at lewis.org Wed Jan 21 20:23:00 2004 From: jlewis at lewis.org (jlewis at lewis.org) Date: Wed, 21 Jan 2004 20:23:00 -0500 (EST) Subject: [ppml] Bogons etc... In-Reply-To: Message-ID: On Wed, 21 Jan 2004, Michel Py wrote: > Without having a chance to check it first, indeed. However, this is not > the issue. Why did we have problems with 69/8 and why do we have > problems with 70/8? Not because the list of bogons is difficult to find. > It's not. It's because it takes time for any large organization to > update their bogon filters on all their routers. Yeah right. Having personally interfaced with some of the broken networks, I'd say it's more a matter of "someone setup a filter" and nobody maintains it. In these cases, it would actually have been better if they did hook up a bogon BGP feed to their network...at least that would update itself when the person who configured it had moved on. It would be very interesting to setup a 70/8 interface on 69box.atlantic.net and see of the networks that had blocked 69/8 routes, how many are blocking 70/8 routes. I'd bet it'll be the majority of them...because when contacted, someone at these networks updated their filter(s)...but in general, still nobody maintains them. ---------------------------------------------------------------------- Jon Lewis *jlewis at lewis.org*| I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From michel at arneill-py.sacramento.ca.us Thu Jan 22 02:51:53 2004 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Wed, 21 Jan 2004 23:51:53 -0800 Subject: [ppml] Bogons etc... Message-ID: >> Michael.Dillon at radianz.com wrote: >> Further, I think the place to do this is with DNS, >> much like many of the spam black lists. > william at elan.net > Its been done with dns, [..] > If you're interested try bogons.dnsiplists.completewhois.com [for those of you that have not read the redisfilter draft yet, William is one of the co-authors and I am grateful for his contribution]. That being said, let's try to nail the coffin on this: IP filtering on a per-host basis (regardless it's using DNS, LDAP or something else) is a flawed concept in the first place. In the case of an SMTP session, it is valid to check the originating IP against a DNS RBL. If you get into more generic filtering, you just can't do this: are you going to wait for the hypothetical query against bogons.dnsiplists.completewhois.com or any other DNS or LDAP based service to decide to drop or not _each_ packet? Of course not. So Michael and Leo please stop trying to sell us a generic host-based filtering scheme based on LDAP or DNS, it just does not work nor scale, both because nothing can handle every host querying the DNS/LDAP servers and nothing can even handle a single host querying the DNS/LDAP server for each packet either. Filtering IP packets or datagrams is a layer 3 deal, it's done on a router not on a host, and the feed of the filtering information is a BGP deal. Grow up, that's what both the theoricians and the operators with tons of operational experience say. That's why layer violations generally _and_ in this case are a BAD idea, period. Michel. From michel at arneill-py.sacramento.ca.us Thu Jan 22 02:52:10 2004 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Wed, 21 Jan 2004 23:52:10 -0800 Subject: [ppml] Bogons etc... Message-ID: > Jon Lewis wrote: > Yeah right. Having personally interfaced with some > of the broken networks, I'd say it's more a matter > of "someone setup a filter" and nobody maintains it. That's exactly what I was _trying_ to say :-) Please not the blurry distinction between: >> Michel >> It's because it takes time for any large organization >> to update their bogon filters on all their routers. And > Jon > "someone setup a filter" and nobody maintains it. :-D > In these cases, it would actually have been better > if they did hook up a bogon BGP feed to their > network...at least that would update itself when > the person who configured it had moved on. Indeed! > [filters] but in general, still nobody maintains them. Thanks for making my point; that's precisely why I picked my co-authors for the redisfilter draft: they actually have clues on what it takes to maintain that kind of stuff and use it operationally. Michel. From Michael.Dillon at radianz.com Thu Jan 22 07:02:56 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 22 Jan 2004 12:02:56 +0000 Subject: [ppml] Bogons etc... Message-ID: > There are no tools that change router config based on LDAP data, >and to my knowledge firewalls do not have such tools for LDAP feed either, >nor mail server software, etc. LDAP is used heavily by mail server software, in fact this is one of its core uses. It is also used to some extent for firewalls, e.g. http://oldfaq.phoneboy.com/fom-serve/cache/208.html You have to remember that LDAP is just a lightweight protocol used to access a distributed database. You can put anything you want into the database including things like CIDR blocks and OSPF weights. http://www.networking.earthweb.com/netsp/article.php/1444871 >There is RPSL definition for whois datathat is next layer up above whois >protocol. RPSL is used for routing database (as published by ARIN for >example) and is easily parseable and there are tools to convert this to be >used for router configurations and firewall configurations. Publishing >information by RPSL is a good idea that ARIN should consider doing instead >of continuing to use its own non-standard WHOIS format (note: RIPE, APNIC, >LACNIC are all using RPSL for whois data). RPSL is definitely a step in the right direction and I'd be happy if ARIN would use this. On the other hand, RPSL is less standard and less supported than LDAP and it is easy to map an RPSL schema as Bernard Aboba has shown in this draft http://www.watersprings.org/pub/id/draft-aboba-rpsl-00.txt Thinking strategically I believe it is better for ARIN to use Common Of The Shelf (COTS) technology wherever possible and minimize the non-standard stuff including RPSL. If ARIN could implement a thin RPSL layer on top of an LDAP backend, then it would have a flexible solution that could drive multiple front-ends including port 43 whois, DNS, BGP route server, etc. And people who want to leverage their in-house LDAP expertise could get their datafeed straight in LDAP. >> Anyone can set up a box with BIND or Zebra or OpenLDAP to receive >> a data feed and integrate it with their internal systems. >Please do it. And release such software as open source and have at least >two confirmed users (besides your own). Unfortunately I can't do this in my current job and it doesn't make a lot of sense to set up a client for a service that does not exist. -- Michael Dillon From Michael.Dillon at radianz.com Thu Jan 22 07:09:36 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 22 Jan 2004 12:09:36 +0000 Subject: [ppml] Bogons etc... Message-ID: >So Michael and Leo please stop trying to sell us a generic host-based >filtering scheme based on LDAP or DNS, it just does not work nor scale, >both because nothing can handle every host querying the DNS/LDAP servers >and nothing can even handle a single host querying the DNS/LDAP server >for each packet either. I'm not trying to sell you a generic host-based filtering scheme based on anything. I am trying to sell you a scheme for the RIRs to publish their authoritative directory of IP address allocations using some sort of technology like LDAP that people can hook up to a wide variety of systems that need to know whether or not an IP address range is legitimately allocated. This includes email systems and peering routers and firewalls. And if someone wants to cache this data on their own internal LDAP server and do host-based filtering then that's their business. >Filtering IP packets or datagrams is a layer 3 deal, it's done on a >router not on a host, and the feed of the filtering information is a BGP >deal. Tell that to the firewall industry. >Grow up, that's what both the theoricians and the operators with >tons of operational experience say. That's why layer violations >generally _and_ in this case are a BAD idea, period. I don't happen to worship at the altar of ISO. --Michael Dillon From bicknell at ufp.org Thu Jan 22 10:53:34 2004 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 22 Jan 2004 10:53:34 -0500 Subject: [ppml] Bogons etc... In-Reply-To: References: Message-ID: <20040122155334.GA92683@ussenterprise.ufp.org> In a message written on Wed, Jan 21, 2004 at 11:51:53PM -0800, Michel Py wrote: > RBL. If you get into more generic filtering, you just can't do this: are > you going to wait for the hypothetical query against > bogons.dnsiplists.completewhois.com or any other DNS or LDAP based > service to decide to drop or not _each_ packet? Of course not. So No, but respectfully I think you're thinking about too narrow of a solution. There are many more things people might want to do than filter routes or packets. No matter what mechanism you use to filter routes or packets you're not going to do a dynamic query per lookup, you're going to cache. Even a BGP feed is a form of caching, since the local box keeps a copy of what it receives and checks against that. Be it distributed in BGP, DNS, or LDAP, or even SQL that's always going to be true. However, I think the best use of this data is up a few levels. Even if we could get all backbones to filter, it will take time to be implemented. The reality is not all backbones are going to filter. For any number of reasons a person could end up with a host on the end of a unfiltered link. I'm sure many people would like to have a reliable way to use this data to filter SMTP connections from unallocated space, or IRC connections, or modify host based firewall rules to drop the raw packets. ARIN is here to serve the community. Perhaps you have some major objection to using DNS, or LDAP, or to doing host based, or application based filtering. That's fine, run your network/hosts however you'd like. The point is there are members of the community who would like to do those sort of things, and ARIN should enable those people to do what they want unless someone can show it would hurt ARIN, or hurt the Network. Services like bogons.dnsiplists.completewhois.com exist today, and are in use today. My assertion that people want this service, and will use this service is not theoretical. My desire is to have it provided directly from ARIN, RIPE, APNIC, etc, and not from completewhois.com. I trust the RIR's more than I trust completewhois.com. If you want to lead the charge to make sure no bogus prefix ever appears on any backbone anywhere, and that no packets are ever sourced from a bogus block, by all means please do. That's good work I'll support. However, until that work is done let us have the slightly ugly duckling, but already deployed solution proped up a bit, so we at least have a fighting chance to stop some abuse in the interim. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From ahp at hilander.com Thu Jan 22 11:09:53 2004 From: ahp at hilander.com (Alec H. Peterson) Date: Thu, 22 Jan 2004 09:09:53 -0700 Subject: [ppml] Bogons etc... In-Reply-To: <20040122155334.GA92683@ussenterprise.ufp.org> References: <20040122155334.GA92683@ussenterprise.ufp.org> Message-ID: <2147483647.1074762593@[192.168.0.101]> We have been down these roads before. There are liability concerns that ARIN must address regardless of the protocol used to distribute this information. Nobody on this list aside from ARIN legal staff (if they are on the list) are qualified to render an authoritative opinion with respect to ARIN's legal exposure. As an ARIN AC member, I will bring this issue up (generally) at the next AC meeting and if there is sufficient consensus among AC members we will request a legal opinion. Now, on to operational considerations. Does anybody remember ORBS? They were DoS'ed off the 'net by spammers. If ARIN starts running this type of service, there will be a _significant_ operational cost increase taken on by ARIN, because the DoS attacks will come, and they may come with such a volume as to completely render all of ARIN offline. I do not suggest for a second that we should not implement such a directory simply for this reason, I merely bring it up so that the issue can be included in the larger discussion. Clearly there are ways to help deal with the issue (such as doing an anycast distribution of the directory). At any rate, I also think that this should be moved to the DBWG mailing list, as this really is an operational issue that specifically deals with the ARIN database. Alec Chair, ARIN AC From Michael.Dillon at radianz.com Thu Jan 22 11:56:10 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 22 Jan 2004 16:56:10 +0000 Subject: [ppml] Bogons etc... Message-ID: >We have been down these roads before. There are liability concerns that >ARIN must address regardless of the protocol used to distribute this >information. Nobody on this list aside from ARIN legal staff (if they are >on the list) are qualified to render an authoritative opinion with respect >to ARIN's legal exposure. As an ARIN AC member, I will bring this issue up >(generally) at the next AC meeting and if there is sufficient consensus >among AC members we will request a legal opinion. Will ARIN be shutting down their whois servers and web servers until they can get an authoritative legal opinion? >Now, on to operational considerations. Does anybody remember ORBS? They >were DoS'ed off the 'net by spammers. If ARIN starts running this type of >service, there will be a _significant_ operational cost increase taken on >by ARIN, because the DoS attacks will come, and they may come with such a >volume as to completely render all of ARIN offline. Correct me if I'm wrong but ARIN staff have already done a lot of engineering work to deal with DoS issues on the existing whois service. In any case, if ARIN implements this using a caching friendly protocol like LDAP or DNS then this is a non-issue because the information will not all be served from one place. >At any rate, I also think that this should be moved to the DBWG mailing >list, as this really is an operational issue that specifically deals with >the ARIN database. There is still a policy issue that belongs here. --Michael Dillon From michel at arneill-py.sacramento.ca.us Thu Jan 22 13:09:25 2004 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Thu, 22 Jan 2004 10:09:25 -0800 Subject: [ppml] Bogons etc... Message-ID: > Michael.Dillon at radianz.com wrote: > I am trying to sell you a scheme for the RIRs to publish > their authoritative directory of IP address allocations They already do. Here: ftp://ftp.ripe.net/pub/stats/ripencc/issued > using some sort of technology like LDAP that people > can hook up to a wide variety of systems As far as I'm concerned, this info is _already_ in use operationally by a wide variety of systems. If you don't like the format, read what ARIN publishes, transform it into LDAP or DNS possibly using the perl stuff that is there too, and let's see how many takers you get. The proof is in the pudding. Michel. From memsvcs at arin.net Thu Jan 22 13:34:58 2004 From: memsvcs at arin.net (Member Services) Date: Thu, 22 Jan 2004 13:34:58 -0500 (EST) Subject: [ppml] New Policies Ratified Message-ID: <200401221834.NAA04009@ops.arin.net> The following policies were ratified in the ARIN region and take effect January 22, 2004: 2003-13 6 Month Supply of IP Addresses http://www.arin.net/policy/2003_13.html 2003-14 Remove /13 Maximum Allocation http://www.arin.net/policy/2003_14.html The following policy was ratified in the ARIN region and will be forwarded to the ASO AC for consideration: 2003-12 IANA to RIR Allocation of IPv4 Address Space http://www.arin.net/policy/2002_3.html The following policies were ratified in the ARIN region. The implementation of these policies is pending the ARIN Board of Trustees' review of a new fee schedule that will have an impact on these policies. 2002-3 Address Policy for Multi-homed Networks http://www.arin.net/policy/2002_3.html 2003-15 IPv4 Allocation Policy for the Africa Portion of the ARIN Region http://www.arin.net/policy/2003_15.html These policies were created in accordance with ARIN's Internet Resource Policy Evaluation Process. Information about ARIN's Internet Resource Policy Evaluation Process is available at: http://www.arin.net/policy/ipep.html Note that all policy proposals reviewed under this process; including adopted, abandoned, and obsolete policies, can be found at the following location: http://www.arin.net/policy/proposal_archive.html Member Services American Registry for Internet Numbers (ARIN) From memsvcs at arin.net Thu Jan 22 13:37:12 2004 From: memsvcs at arin.net (Member Services) Date: Thu, 22 Jan 2004 13:37:12 -0500 (EST) Subject: [ppml] Internet Resource Policy Evaluation Process Message-ID: <200401221837.NAA04303@ops.arin.net> A new version of the Internet Resource Policy Evaluation Process (IRPEP) has been ratified by the ARIN Board of Trustees and will take effect immediately: http://www.arin.net/policy/ipep.html There are remaining active policy proposals which were presented at the ARIN Public Policy Meeting in Chicago in October of 2003. These policy proposals were initiated under the old Internet Resource Policy Evaluation Process. They will now be inserted into the new IRPEP at the appropriate stage of the process as follows: The following policy proposals are being worked on by the AC. Further discussion will be held on the ARIN Public Policy mailing list. Policy Proposal 2003-4: IPv6 Policy Changes Policy Proposal 2003-9: WHOIS Acceptable Use Policy Proposal 2003-16: POC Verification The following policy proposal is in the post Public Policy Meeting AC Review stage and will be posted to final call: Policy Proposal 2002-2: Experimental Internet Resource Allocations The ARIN Board of Trustees recently requested clarification for the following policy proposals. They are currently in the Last Call review stage: Policy Proposal 2003-3: Residential Customer Privacy Policy Proposal 2003-5: Distributed Information Server Use Requirements Member Services American Registry for Internet Numbers (ARIN) From michel at arneill-py.sacramento.ca.us Thu Jan 22 17:32:35 2004 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Thu, 22 Jan 2004 14:32:35 -0800 Subject: [ppml] Bogons etc... Message-ID: > Leo Bicknell wrote: > No matter what mechanism you use to filter routes or > packets you're not going to do a dynamic query per > lookup, you're going to cache. Even a BGP feed is > a form of caching, since the local box keeps a copy > of what it receives and checks against that. Be it > distributed in BGP, DNS, or LDAP, or even SQL > that's always going to be true. Ack this. However, DNS caching means secondary zones which causes numerous problems on a large scale, I have never seen a distributed/replicated LDAP database that works on a large scale, and a distributed/replicated SQL database among a large number of administratively separate participants would be a nightmare to get going. This is why bogon/filtering outfits are regrouping around BGP on AS29467. > I'm sure many people would like to have a reliable > way to use this data to filter SMTP connections from > unallocated space, or IRC connections, or modify > host based firewall rules to drop the raw packets. > [..] > but respectfully I think you're thinking about > too narrow of a solution. What's above is what I would call a too narrow solution; all these things can and already are derived from the BGP feed. > ARIN is here to serve the community [..] and ARIN > should enable those people to do what they want They already do. > My assertion that people want this service, and will > use this service is not theoretical. People _already_ use this service. The existing format was reviewed by the community, I believe. > If you want to lead the charge to make sure no bogus > prefix ever appears on any backbone anywhere, and that > no packets are ever sourced from a bogus block, by all > means please do. That's not the intent, actually. This would require some for of certificate or other authentication that is not currently available. Paging Geoff Huston... > However, until that work is done let us have the > slightly ugly duckling, but already deployed > solution proped up a bit, so we at least have a > fighting chance to stop some abuse in the interim. Which is my goal as well. Can you remind me about your publicly available operational work regarding filtering? Michel. From bicknell at ufp.org Thu Jan 22 19:07:21 2004 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 22 Jan 2004 19:07:21 -0500 Subject: [ppml] Bogons etc... In-Reply-To: References: Message-ID: <20040123000721.GA21047@ussenterprise.ufp.org> In a message written on Thu, Jan 22, 2004 at 02:32:35PM -0800, Michel Py wrote: > What's above is what I would call a too narrow solution; all these > things can and already are derived from the BGP feed. Which does not come from ARIN, which is the entire point. I can get a BGP feed from team cymru, I can get a DNS feed from completewhois.com. I want to be able to get them from ARIN so I don't have to trust some random third party. The assertion is not that ARIN doesn't publish the data, it's that it doesn't publish it in enough conveniant formats. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From andrew.dul at quark.net Wed Jan 28 23:53:12 2004 From: andrew.dul at quark.net (Andrew Dul) Date: Wed, 28 Jan 2004 20:53:12 -0800 Subject: [ppml] Required utilization for additional allocations Message-ID: <3.0.5.32.20040128205312.01b6cf18@pop3.quark.net> Hello, At the last ARIN meeting in Chicago, the policy proposal 2003-10 (Use of HD ratio for IPv4 allocations) was presented by a member of the ARIN community. There was no consensus by the membership that this policy should be moved forward and the AC directed the Board to abandon this policy proposal. However, there was interest by the membership for the ARIN AC to consider alternate utilization measurement methodologies for address blocks. The current IPv4 policy can be found at this URL: http://www.arin.net/policy/ipv4.html The AC would like to solicit additional input from the ARIN community regarding this topic. We are specifically interested in specific cases or examples where the current policy does not provide the adequate or intended goals consistent with ARIN's charter. Thank you, Andrew Dul ARIN AC From andrew.dul at quark.net Wed Jan 28 23:40:08 2004 From: andrew.dul at quark.net (Andrew Dul) Date: Wed, 28 Jan 2004 20:40:08 -0800 Subject: [ppml] RE: 2003-16 - POC Verification and publication Message-ID: <3.0.5.32.20040128204008.01b6cf18@pop3.quark.net> Hello, At the last ARIN meeting the AC presented the policy proposal 2003-16 for review and consideration by the membership. As a result of the discussion at the meeting and subsequent discussions at the AC meetings, the AC has been working on a rewrite of the policy to remove the procedural language from the proposed policy. It is our plan to present this rewrite at the next ARIN meeting. A couple of key points were raised at the meeting: 1) The possible malicious use of the "up-to-date" flag that was to be listed in the whois record. 2) The impact to ARIN staff from this policy change. 3) Timing and frequency of actions to be taken during the verification process. Following the meeting the AC also asked the ARIN staff to provide an impact statement regarding the additional workload that would be required to implement the policy. I have attached the statement that ARIN has provided. The text of the current policy can be found at this URL. http://www.arin.net/policy/2003_16.html The AC is requesting additional comments from the community regarding this proposal so that we can include your comments in the rewrite to be presented at the upcoming meeting. Thank you, Andrew Dul ARIN AC -------------- next part -------------- A non-text attachment was scrubbed... Name: 2003-16 Impact Analysis1.doc Type: application/msword Size: 29696 bytes Desc: not available URL: