From Michael.Dillon at radianz.com Fri Jul 18 10:41:08 2003 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Fri, 18 Jul 2003 15:41:08 +0100 Subject: [ppml] Reserved allocation commitments Message-ID: For various technical and business reasons, my company must carefully plan and deploy new IP address ranges into our network. All of this work creates the need for lead time and this severely shortens the 3 month cycle prescribed by the ARIN policies. However, some of these problems could be mitigated by changing some aspects of the relationship between ARIN and a regular subscriber member, i.e. an ISP that comes back regularly for additional allocations. Is there anything in the ARIN policies which would prevent ARIN staff from the following: 1. When issuing an allocation, reserve additional blocks (probably adjacent ones) to fulfill future allocations. 2. Along with the allocation, make a time-limited commitment to allocate a specific identifiable block of addresses at the next allocation on the condition that all normal rules for an allocation are met. If the time limit runs out, the commitment also expires. I suggest a time limit of 4 months. What does this achieve? It so happens, that in our network there are ACLs in a lot of edge routers that need to be changed before we can begin to use a new allocation and this change work takes a long time to plan and execute because we severely restrict any interventions to routers in our network during the time period that our business customers are using the network. If we knew 3 months in advance, what the new allocation would be, we could complete all the preparatory work before making the application for an allocation. So, is there any policy that prohibits ARIN from making a commitment that is both time-limited and conditional upon meeting all normal conditions? The net impact of doing this would be to tie up a small amount of reserved IP space for 3-4 months. The amount of IP space affected would be approximately 25% of ARIN's yearly allocations. ------------------------------------------------------- Michael Dillon Capacity Planning, Prescot St., London, UK Mobile: +44 7900 823 672 Internet: michael.dillon at radianz.com Phone: +44 20 7650 9493 Fax: +44 20 7650 9030 From ron at aol.net Fri Jul 18 13:14:07 2003 From: ron at aol.net (Ron da Silva) Date: Fri, 18 Jul 2003 13:14:07 -0400 Subject: [ppml] Reserved allocation commitments In-Reply-To: References: Message-ID: <20030718171407.GG575@aol.net> On Fri, Jul 18, 2003 at 03:41:08PM +0100, Michael.Dillon at radianz.com wrote: > So, is there any policy that prohibits ARIN from making a commitment that > is both time-limited and conditional upon meeting all normal conditions? > The net impact of doing this would be to tie up a small amount of reserved > IP space for 3-4 months. The amount of IP space affected would be > approximately 25% of ARIN's yearly allocations. Would this impact ARIN's ability to obtain additional address space from IANA? I suspect that "reserved in case member foo needs more addresses sometime later" is not a sufficient demostration of appropriately allocated address space. -ron From Michael.Dillon at radianz.com Mon Jul 21 05:16:31 2003 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Mon, 21 Jul 2003 10:16:31 +0100 Subject: [ppml] Reserved allocation commitments Message-ID: >On Fri, Jul 18, 2003 at 03:41:08PM +0100, Michael.Dillon at radianz.com wrote: >> So, is there any policy that prohibits ARIN from making a commitment that >> is both time-limited and conditional upon meeting all normal conditions? >> The net impact of doing this would be to tie up a small amount of reserved >> IP space for 3-4 months. The amount of IP space affected would be >> approximately 25% of ARIN's yearly allocations. >Would this impact ARIN's ability to obtain additional address space from >IANA? I suspect that "reserved in case member foo needs more addresses >sometime later" is not a sufficient demostration of appropriately allocated >address space. ARIN has always reserved space for ISP allocations that are likely to grow. However, I've always assumed that this was just an operational practice that was intended to reduce fragmentation of the IP space. What I'd like to know is whether there are any policies in place that restrict what ARIN can do in regard to reservations. If not, then I'd like to suggest that they move this out of the shadows of operational practice and make a commitment to ISPs that they will allocate a specific identified reserved block if the ISP submits a successful application before some specific date in the future. If there is a policy in place that limits ARIN's ability to do this then I will be suggesting that this policy be changed. --Michael Dillon From blake.sorensen at digitalenvoy.net Mon Jul 21 08:57:52 2003 From: blake.sorensen at digitalenvoy.net (Blake Sorensen) Date: Mon, 21 Jul 2003 08:57:52 -0400 Subject: [ppml] Access to Bulk WHOIS data - a possible proposal? In-Reply-To: Message-ID: william at elan.net wrote: > It does not have one-month requirement as many felt this is too often and > said something like 6 months or year would be better but there was no > agreement on what period would be best and I decided to drop specifics > and instead let ARIN staff decide based on each case on when and how they > want "re-authentication" done. Sorry for the delay in responding to this. Just my thoughts, but I'd like to see a time interval actually specified in the proposal, whether it be 6 or 12 months. Without that, we'd have access to the bulk data until ARIN changes the password, at which point you mail in another request and wait for them to send a new one. I've been waiting over a month as it stands now, with no response. With a specified time interval, we can send in the authorization by a certain point to avoid interrupting access to the bulk data. Thanks, -- Blake Sorensen Digital Envoy From Michael.Dillon at radianz.com Tue Jul 22 06:24:00 2003 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Tue, 22 Jul 2003 11:24:00 +0100 Subject: [ppml] Deadline for policy proposals Message-ID: It seems that the first week of September is the deadline for policy proposals to be submitted to ARIN in order to be discussed at the October meetings. Rather than wait until the last minute, it might be best to start discussing possible policy changes now so that we have a few weeks of preliminary discussion in public before we commit to the wording of a policy proposal. In my next message, I will suggest an area in which I think we need some changes. ------------------------------------------------------- Michael Dillon Capacity Planning, Prescot St., London, UK Mobile: +44 7900 823 672 Internet: michael.dillon at radianz.com Phone: +44 20 7650 9493 Fax: +44 20 7650 9030 From Michael.Dillon at radianz.com Tue Jul 22 06:44:15 2003 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Tue, 22 Jul 2003 11:44:15 +0100 Subject: [ppml] Increase the flexibility of IP allocations to facilitate planning Message-ID: I believe that the current policy for IPv4 allocations is too rigid and should be made more flexible in a number of areas. A 3-month allocation cycle is too short. This should be increased to allow organizations to receive a 6 month supply of IPv4 addresses. The 80% usage requirement before applying for more addresses is too rigid. This should be loosened up to allow organizations to apply for new addresses before they have reached 80% usage as long as they can supply usage trend data that shows they will surpass 80% within 6 months. There needs to be a clear appeal process. Currently the only appeal route is to a non-existent organization, namely IANA. I have tried to contact IANA on another matter and after 11 days and two attempts I still have no reply. If a telephone company is denied new phone number blocks by NANPA they can appeal to have that decision overturned by the PUC. We have no similar appeal possibility within ARIN. Organizations are penalized for using IPv4 addresses efficiently because if they do so, they have no internal buffer of hidden IPv4 addresses that they can use in the event that an allocation request is denied or delayed. The net effect is to encourage organizations to keep a secret stash of IP addresses that they could use if necessary. ------------------------------------------------------- Michael Dillon Capacity Planning, Prescot St., London, UK Mobile: +44 7900 823 672 Internet: michael.dillon at radianz.com Phone: +44 20 7650 9493 Fax: +44 20 7650 9030 From Scott.Whipple at cox.com Tue Jul 22 09:42:11 2003 From: Scott.Whipple at cox.com (Whipple, Scott (CCI-Atlanta)) Date: Tue, 22 Jul 2003 09:42:11 -0400 Subject: [ppml] Increase the flexibility of IP allocations to facilitate planning Message-ID: <4B8EA05057E49E4F940B74AC3AEC23F40BB804@CATL0MS03.corp.cox.com> > Organizations are penalized for using IPv4 addresses efficiently because > if they do so, they have no internal buffer of hidden IPv4 addresses that > they can use in the event that an allocation request is denied or delayed. > The net effect is to encourage organizations to keep a secret stash of IP > addresses that they could use if necessary. This paragraph makes no sense. If you are efficiently utilizing your space there would be no reason to be denied or delayed in getting additional space. Where as, if you were keeping a secret stash of IP space, that would be the perfect example to get delayed or denied. I would also disagree that the 80% usage requirement is to stringent. I think if you use your space wisely and submit your request as you reach 80% you should have no problem getting your request approved and your new block allocated before running out. I would however support a 6 month allocation cycle. -----Original Message----- From: Michael.Dillon at radianz.com [mailto:Michael.Dillon at radianz.com] Sent: Tuesday, July 22, 2003 6:44 AM To: ppml at arin.net Subject: [ppml] Increase the flexibility of IP allocations to facilitate planning I believe that the current policy for IPv4 allocations is too rigid and should be made more flexible in a number of areas. A 3-month allocation cycle is too short. This should be increased to allow organizations to receive a 6 month supply of IPv4 addresses. The 80% usage requirement before applying for more addresses is too rigid. This should be loosened up to allow organizations to apply for new addresses before they have reached 80% usage as long as they can supply usage trend data that shows they will surpass 80% within 6 months. There needs to be a clear appeal process. Currently the only appeal route is to a non-existent organization, namely IANA. I have tried to contact IANA on another matter and after 11 days and two attempts I still have no reply. If a telephone company is denied new phone number blocks by NANPA they can appeal to have that decision overturned by the PUC. We have no similar appeal possibility within ARIN. Organizations are penalized for using IPv4 addresses efficiently because if they do so, they have no internal buffer of hidden IPv4 addresses that they can use in the event that an allocation request is denied or delayed. The net effect is to encourage organizations to keep a secret stash of IP addresses that they could use if necessary. ------------------------------------------------------- Michael Dillon Capacity Planning, Prescot St., London, UK Mobile: +44 7900 823 672 Internet: michael.dillon at radianz.com Phone: +44 20 7650 9493 Fax: +44 20 7650 9030 From Michael.Dillon at radianz.com Tue Jul 22 10:28:48 2003 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Tue, 22 Jul 2003 15:28:48 +0100 Subject: [ppml] Increase the flexibility of IP allocations to facilitate planning Message-ID: >> Organizations are penalized for using IPv4 addresses efficiently because >> if they do so, they have no internal buffer of hidden IPv4 addresses that >> they can use in the event that an allocation request is denied or delayed. >> The net effect is to encourage organizations to keep a secret stash of IP >> addresses that they could use if necessary. >This paragraph makes no sense. If you are efficiently utilizing your space there would be no reason to be denied >or delayed in getting additional space. Where as, if you were keeping a secret stash of IP space, that would be >the perfect example to get delayed or denied. Here's what I mean. If your goal was to maximize the efficiency of address assignment, then you would eventually reach an upper limit for every netblock beyond which you can't improve efficiency. I'm assuming that is greater than 80% utilization. That means that when you reach 80% on your last netblock, you have already used up all possible addresses on previous netblocks so that you only have the last 20% of the most recent netblock to allocate. In fact, you probably have less than 20% because it is not possible to assign IPv4 addresses to 100% efficiency. Assuming that the allocation is based on 3 months of usage, i.e. 13 weeks, this means that you have no more than 2.6 weeks supply of addresses left when you submit your ARIN application. The .6 weeks will be used up by ARIN's 2-3 business days of turnaround time so you will only have 2 weeks to get these new addresses into your systems. The people who do this work also do other planned and break-fix operational work so they can't be expected to just drop everything and handle these new IP addresses every time. The solution to this problem is to keep a secret stash of IP addresses that ARIN doesn't know about so that you never have a crisis with address exhaustion due to the ARIN application process. There are lots of ways to do this, i.e. never assign more than 80% of a netblock or never reuse old addresses freed up by customer churn until after you have used 80% of your last ARIN netblock. The fact is that the existing ARIN policy encourages this sort of behaviour. Businesses need reasonable buffers and if the policy won't explicitly accomodate buffers then people find other ways to create the buffers they need. Of course, if you run a vanilla IP network, then the 2 weeks is probably enough time to handle an ARIN application even if it means you need to do a bit of re-allocation of addresses from one PoP to another and later renumbering things to free up older addresses for your buffer. But not everyone runs a vanilla IP network anymore. Also, network operators are becoming larger which means increased internal process which means increased time to get things done. A 2 week buffer is simply not a reasonable business practice. >I would also disagree that the 80% usage requirement is to stringent. I think if you use your space wisely and >submit your request as you reach 80% you should have no problem getting your request approved and your new block >allocated before running out. This is only true if your usage grows steadily without fits and starts and if your internal processes allow you to quickly deploy new addresses. While the ARIN membership may believe that it is reasonable to require an 80% utilization rate, I do not believe that it is reasonable to require this as a precondition for receiving new IP addresses because of the timing issues. Remember, we are talking about organizations that have a long term relationship with ARIN; it is not necessary to police each and every one of their interactions with the organization. What is wrong with requiring that you must show that your usage trend WILL hit 80% in the near future and that you did indeed exceed 80% utilization in your penultimate netblock? We still have the same utilization but we now have a much smoother allocation procedure that accomodates internal business processes of the members. --Michael Dillon From bicknell at ufp.org Tue Jul 22 11:41:04 2003 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 22 Jul 2003 11:41:04 -0400 Subject: [ppml] Increase the flexibility of IP allocations to facilitate planning In-Reply-To: <4B8EA05057E49E4F940B74AC3AEC23F40BB804@CATL0MS03.corp.cox.com> References: <4B8EA05057E49E4F940B74AC3AEC23F40BB804@CATL0MS03.corp.cox.com> Message-ID: <20030722154104.GA99370@ussenterprise.ufp.org> In a message written on Tue, Jul 22, 2003 at 09:42:11AM -0400, Whipple, Scott (CCI-Atlanta) wrote: > I would also disagree that the 80% usage requirement is to stringent. FWIW, attached is a data file. The first column is how many addresses your customer needs, the second is the smallest block you can give them if we assume they get a single block, obviously by giving them multiple blocks you could be more efficient, but I don't think anyone believes that is a good practice. The interesting thing about this is at the bottom, if you average the averages (total average usage) you get 75%. So, if you ask your customers "how many devices you have" and record that number, and they are randomly distributed, and you always assign the smallest possible block, you'll never get above 75% utilization on average. This is a problem for some, and not for others. For instance, if your a dial-up, dsl, or cable modem shop you can likely insure a close to subnet size number of people are on a subnet. However if you're selling T1's or business DSL, the reality is 75% is a _upper bound_ on how well you can do, if we assume a single subnet per customer. Now, I'm not suggesting this is a real problem. However depending on how pedantic you want to be about 80%, or what level of detail you want to see on allocations it is a very real issue. Add in needing to allow for growth on some customers (which may or may not happen in the original predicted time frame) and it can be somewhat difficult to meet the 80% rule, even if you're doing the right things. -- 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 -------------- IP's Needed Block Size Assigned Block Utilization 1 /32 100% 2 /31 100% 3 /29 62.5% 4 /29 75% 5 /29 87.5% 6 /29 100% 7 /28 56.2% 8 /28 62.5% 9 /28 68.7% 10 /28 75% 11 /28 81.2% 12 /28 87.5% 13 /28 93.7% 14 /28 100% 15 /27 53.1% 16 /27 56.2% 17 /27 59.3% 18 /27 62.5% 19 /27 65.6% 20 /27 68.7% 21 /27 71.8% 22 /27 75% 23 /27 78.1% 24 /27 81.2% 25 /27 84.3% 26 /27 87.5% 27 /27 90.6% 28 /27 93.7% 29 /27 96.8% 30 /27 100% 31 /26 51.5% 32 /26 53.1% 33 /26 54.6% 34 /26 56.2% 35 /26 57.8% 36 /26 59.3% 37 /26 60.9% 38 /26 62.5% 39 /26 64% 40 /26 65.6% 41 /26 67.1% 42 /26 68.7% 43 /26 70.3% 44 /26 71.8% 45 /26 73.4% 46 /26 75% 47 /26 76.5% 48 /26 78.1% 49 /26 79.6% 50 /26 81.2% 51 /26 82.8% 52 /26 84.3% 53 /26 85.9% 54 /26 87.5% 55 /26 89% 56 /26 90.6% 57 /26 92.1% 58 /26 93.7% 59 /26 95.3% 60 /26 96.8% 61 /26 98.4% 62 /26 100% 63 /25 50.7% 64 /25 51.5% 65 /25 52.3% 66 /25 53.1% 67 /25 53.9% 68 /25 54.6% 69 /25 55.4% 70 /25 56.2% 71 /25 57% 72 /25 57.8% 73 /25 58.5% 74 /25 59.3% 75 /25 60.1% 76 /25 60.9% 77 /25 61.7% 78 /25 62.5% 79 /25 63.2% 80 /25 64% 81 /25 64.8% 82 /25 65.6% 83 /25 66.4% 84 /25 67.1% 85 /25 67.9% 86 /25 68.7% 87 /25 69.5% 88 /25 70.3% 89 /25 71% 90 /25 71.8% 91 /25 72.6% 92 /25 73.4% 93 /25 74.2% 94 /25 75% 95 /25 75.7% 96 /25 76.5% 97 /25 77.3% 98 /25 78.1% 99 /25 78.9% 100 /25 79.6% 101 /25 80.4% 102 /25 81.2% 103 /25 82% 104 /25 82.8% 105 /25 83.5% 106 /25 84.3% 107 /25 85.1% 108 /25 85.9% 109 /25 86.7% 110 /25 87.5% 111 /25 88.2% 112 /25 89% 113 /25 89.8% 114 /25 90.6% 115 /25 91.4% 116 /25 92.1% 117 /25 92.9% 118 /25 93.7% 119 /25 94.5% 120 /25 95.3% 121 /25 96% 122 /25 96.8% 123 /25 97.6% 124 /25 98.4% 125 /25 99.2% 126 /25 100% 127 /24 50.3% 128 /24 50.7% 129 /24 51.1% 130 /24 51.5% 131 /24 51.9% 132 /24 52.3% 133 /24 52.7% 134 /24 53.1% 135 /24 53.5% 136 /24 53.9% 137 /24 54.2% 138 /24 54.6% 139 /24 55% 140 /24 55.4% 141 /24 55.8% 142 /24 56.2% 143 /24 56.6% 144 /24 57% 145 /24 57.4% 146 /24 57.8% 147 /24 58.2% 148 /24 58.5% 149 /24 58.9% 150 /24 59.3% 151 /24 59.7% 152 /24 60.1% 153 /24 60.5% 154 /24 60.9% 155 /24 61.3% 156 /24 61.7% 157 /24 62.1% 158 /24 62.5% 159 /24 62.8% 160 /24 63.2% 161 /24 63.6% 162 /24 64% 163 /24 64.4% 164 /24 64.8% 165 /24 65.2% 166 /24 65.6% 167 /24 66% 168 /24 66.4% 169 /24 66.7% 170 /24 67.1% 171 /24 67.5% 172 /24 67.9% 173 /24 68.3% 174 /24 68.7% 175 /24 69.1% 176 /24 69.5% 177 /24 69.9% 178 /24 70.3% 179 /24 70.7% 180 /24 71% 181 /24 71.4% 182 /24 71.8% 183 /24 72.2% 184 /24 72.6% 185 /24 73% 186 /24 73.4% 187 /24 73.8% 188 /24 74.2% 189 /24 74.6% 190 /24 75% 191 /24 75.3% 192 /24 75.7% 193 /24 76.1% 194 /24 76.5% 195 /24 76.9% 196 /24 77.3% 197 /24 77.7% 198 /24 78.1% 199 /24 78.5% 200 /24 78.9% 201 /24 79.2% 202 /24 79.6% 203 /24 80% 204 /24 80.4% 205 /24 80.8% 206 /24 81.2% 207 /24 81.6% 208 /24 82% 209 /24 82.4% 210 /24 82.8% 211 /24 83.2% 212 /24 83.5% 213 /24 83.9% 214 /24 84.3% 215 /24 84.7% 216 /24 85.1% 217 /24 85.5% 218 /24 85.9% 219 /24 86.3% 220 /24 86.7% 221 /24 87.1% 222 /24 87.5% 223 /24 87.8% 224 /24 88.2% 225 /24 88.6% 226 /24 89% 227 /24 89.4% 228 /24 89.8% 229 /24 90.2% 230 /24 90.6% 231 /24 91% 232 /24 91.4% 233 /24 91.7% 234 /24 92.1% 235 /24 92.5% 236 /24 92.9% 237 /24 93.3% 238 /24 93.7% 239 /24 94.1% 240 /24 94.5% 241 /24 94.9% 242 /24 95.3% 243 /24 95.7% 244 /24 96% 245 /24 96.4% 246 /24 96.8% 247 /24 97.2% 248 /24 97.6% 249 /24 98% 250 /24 98.4% 251 /24 98.8% 252 /24 99.2% 253 /24 99.6% 254 /24 100% Total Average Utilization 75% -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From jlewis at lewis.org Tue Jul 22 20:00:50 2003 From: jlewis at lewis.org (jlewis at lewis.org) Date: Tue, 22 Jul 2003 20:00:50 -0400 (EDT) Subject: [ppml] Increase the flexibility of IP allocations to facilitate planning In-Reply-To: <4B8EA05057E49E4F940B74AC3AEC23F40BB804@CATL0MS03.corp.cox.com> Message-ID: On Tue, 22 Jul 2003, Whipple, Scott (CCI-Atlanta) wrote: > > Organizations are penalized for using IPv4 addresses efficiently because > > if they do so, they have no internal buffer of hidden IPv4 addresses that > > they can use in the event that an allocation request is denied or delayed. > > The net effect is to encourage organizations to keep a secret stash of IP > > addresses that they could use if necessary. > > This paragraph makes no sense. If you are efficiently utilizing your > space there would be no reason to be denied or delayed in getting > additional space. Where as, if you were keeping a secret stash of IP > space, that would be the perfect example to get delayed or denied. Sure it does. If you're not terribly efficient or padded your utilization numbers a little, you can always trim the fat and clean things up if you run out of space before you get through the application process and game of 20 questions with ARIN. > I would also disagree that the 80% usage requirement is to stringent. > I think if you use your space wisely and submit your request as you > reach 80% you should have no problem getting your request approved and > your new block allocated before running out. Just guessing here...but I suspect the difficulty most networks have with dealing with ARIN is the "sloppy start" method that current and recent ARIN regulations facilitate. i.e. For your first allocation, ARIN will give you up to 2x as much space as you can justify. Depending on the type of network you run and how you grow, that initial allocation could take months, perhaps years to fully utilize. That gives you alot of time for your IP allocation records to get disorganized, outdated, and generally a mess. It's been my experience (with multiple networks) that once the initial allocation is used up and ARIN is sufficiently convinced that you have indeed used it up, they'll double your allocation. If you started with a /20, they give you a /20 to make it a /19. If you started with a /18, they give you the other half of the /17. This, again, gives you alot of time to make a mess of your records. It doesn't help that there seems to be no suitable tool for tracking IP utilization to the degree that ARIN applications require...at least none that I've seen, and I've installed and tested several of the free ones...and never got anywhere trying to get info or a test drive out of a commercial one. This means for the average ISP, ARIN application time is also IP utilization audit time. Not a fun time for whoever does it. If someone were to develop an affordable (to the average small ISP) tool for IP allocation tracking, and applying for more space was reduced to filling out a few text fields on the ARIN application and including a report from your allocation tracking system, I think there'd be alot less complaining about the 3-month's supply policy by ISPs when they get to their 3rd allocation and finally get slapped down by the 3-month policy. I know from experience that if you fill out the ARIN application properly, and include all the information they want (or explain why some of what they want doesn't make sense or doesn't apply and supply as much similar info as you can), they won't have 20 questions, and it won't take "forever" to get that next allocation you need. Or maybe some people would like to organize, lay claim to a bunch of IANA reserved space, and form ORIN (Open Registry for Internet Numbers) :) ---------------------------------------------------------------------- Jon Lewis *jlewis at lewis.org*| I route System Administrator | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jlewis at lewis.org Tue Jul 22 23:09:05 2003 From: jlewis at lewis.org (jlewis at lewis.org) Date: Tue, 22 Jul 2003 23:09:05 -0400 (EDT) Subject: [ppml] Increase the flexibility of IP allocations to facilitate planning In-Reply-To: <20030722154104.GA99370@ussenterprise.ufp.org> Message-ID: On Tue, 22 Jul 2003, Leo Bicknell wrote: > So, if you ask your customers "how many devices you have" and record > that number, and they are randomly distributed, and you always > assign the smallest possible block, you'll never get above 75% > utilization on average. Interesting example, but I question its relevance and completeness. First, for every leased line customer you hook up, (assuming Frame, T1, T3, etc.) you're likely to also burn up a /30, and though only 2 IPs are being used, I'd count all 4 as used since you can't do anything with the first and last IPs in the /30. That's going to skew the % utilization higher...but more importantly, AFAIK, ARIN only cares how much of your IP space you've used/assigned/allocated...not how much of the space is actually in use by devices, as long as you're being reasonable (following ARIN guidelines) with your assignment of space to customers...so in your example, the 75% average is irrelevant. If you've assigned >=80% of your IP space to customers or internal use and can justify the assignments, you qualify for another assignment. ---------------------------------------------------------------------- Jon Lewis *jlewis at lewis.org*| I route System Administrator | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jmcburnett at msmgmt.com Wed Jul 23 08:12:19 2003 From: jmcburnett at msmgmt.com (McBurnett, Jim) Date: Wed, 23 Jul 2003 08:12:19 -0400 Subject: [ppml] Increase the flexibility of IP allocations to facilitate planning Message-ID: <9BF6F06C4BC90746ADD6806746492A33487F@msmmail01.msmgmt.com> Can I throw this in: Many of us have complained about those not following the RFC- I forget the # at the moment- with concerns towards postmaster, abuse etc. and I personally have been told by an ISP, that "we do not SWIP" blocks. (Of course after giving their senior management the ARIN website links, called ARIN and asked for complete clarification and even gave them the name of who I spoke with and asking why are you..... they are changing....) If we are going to increase the flex here, should we not see if they are following the basic policies first? Maybe consider these thoughts: 1. Does the user have complaints about violation of ARIN IPv4 policies? 2. Can we do an actual spot check to see if the user is following the policies? 3. Is there whois data actually correct? Don't get me wrong I am all for being flexible when providing a service. But I am also seeing the ABUSE that may occur. If a user is so big they are requesting a second,3rd, 4th or 50th block, they should be amiable to correct their deficiencies..... I won't name him here, but there is a certain SPAMMER in Florida that has at least 3 /20s and several other blocks directly from ARIN. None of his whois data is right. And I very much doubt he is using 80% of those blocks. and I won't even mention # 1 above. I know we have to accept the good with the bad, but in some cases does that bad outweigh the good? FYI That Spammer says he sends over a Billion emails a day...... From Michael.Dillon at radianz.com Wed Jul 23 09:10:26 2003 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Wed, 23 Jul 2003 14:10:26 +0100 Subject: [ppml] Increase the flexibility of IP allocations to facilitate planning Message-ID: >Many of us have complained about those not following the RFC- >I forget the # at the moment- with concerns towards postmaster, abuse etc. >and I personally have been told by an ISP, that "we do not SWIP" blocks. >If we are going to increase the flex here, should we not see if they are >following the basic policies first? I don't agree. I think a major reason why people aren't following the existing rules is that they are too rigid. It would be a mistake to apply pressure to follow the existing policy because it could end up breaking the entire RIR structure. It is a significant benefit to the IP network operator industry to have this membership-based RIR structure instead of the webwork of government bureacracies (FCC, PUCs) that the telephone industry has to deal with. We need to make this structure work, not break it. A wiser course of action would be to rationalise the whole set of ARIN policies to make them into something that members can comply with. >1. Does the user have complaints about violation of ARIN IPv4 policies? As far as I know we have no policing functions in the RIRs, or IANA or ICANN. Also, IANA is barely functional at this point in time and that's the only point of appeal specified in policy. Instead of complaining about policy violators, people simply adopt the same behavior as the policy violators. >2. Can we do an actual spot check to see if the user is following the policies? If member organizations have such a hard time tracking their own IP address inventory, what hope do we have of imposing an external audit requirement? >3. Is there whois data actually correct? Let's go back one step further. Is there any reason at all for publishing whois data? What is the purpose of whois data? If the reason for doing this was clearer and there was a clearly identified purpose for each bit of whois data, then people would take more care to publish it correctly. I believe that we can best cleanse the whois data by getting rid of most of it because it serves no purpose. It originated as a list of people using the resources provided by the DARPA's "Internet" project back in the days before PC's when everyone used timesharing systems. From that time to this, nobody has really taken a hard look at what is the point of this whole thing. --Michael Dillon From bicknell at ufp.org Wed Jul 23 10:30:54 2003 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 23 Jul 2003 10:30:54 -0400 Subject: [ppml] Increase the flexibility of IP allocations to facilitate planning In-Reply-To: <20030722154104.GA99370@ussenterprise.ufp.org> References: <20030722154104.GA99370@ussenterprise.ufp.org> <4B8EA05057E49E4F940B74AC3AEC23F40BB804@CATL0MS03.corp.cox.com> <20030722154104.GA99370@ussenterprise.ufp.org> Message-ID: <20030723143054.GA42667@ussenterprise.ufp.org> In a message written on Tue, Jul 22, 2003 at 11:09:05PM -0400, jlewis at lewis.org wrote: > Interesting example, but I question its relevance and completeness. > First, for every leased line customer you hook up, (assuming Frame, T1, T3, > etc.) you're likely to also burn up a /30, and though only 2 IPs are being > used, I'd count all 4 as used since you can't do anything with the first and > last IPs in the /30. These are in fact counted. If you notice, 6 IP's in a /29 is 100%, the customer needs 6, you must have a network and broadcast IP, so that's all 8 in use, 100%. There are two oddball cases at the start, 1 IP and 2 IP's, the reality is if your customer needed either amount you'd probably assign a /30 and count it as 50% or 100%. Anyway, for anything > 3 I've counted the network and broadcast towards utilization, and the previous cases are 100% moving the average up, so I think I'm being as generous as possible. Now, since you do have all these /30's that are "100%" they will skew my assumed random distribution and push the average up slightly. However it really isn't going to move much. > That's going to skew the % utilization higher...but > more importantly, AFAIK, ARIN only cares how much of your IP space you've > used/assigned/allocated...not how much of the space is actually in use by > devices, as long as you're being reasonable (following ARIN guidelines) with > your assignment of space to customers...so in your example, the 75% average > is irrelevant. If you've assigned >=80% of your IP space to customers or > internal use and can justify the assignments, you qualify for another > assignment. Not quite. If you get a /23 (to make numbers easier) and allocate 4 customers /25's, but each customer only needed 4 IP's your not going to pass ARIN's muster, even though you've "assigned" > 80% of your IP space. The rules are transitive, and apply down stream as well. If you assign IP's to a customer, they must also meet the 80% rule. Problem is, if you have a customer with 7 devices (say, a small office) you have to assign them a /28 for their lan, at 56.2% utilization (7 + 2) / 16. Now, what happens if you get a /23, and end up with with 32 customers, each with 7 devices. You've "assigned" 100% of your IP space, but only 56% of your IP space is in use. By the letter of the rules I don't belive you meet the 80% rule, yet you can't do any better. Again, I'm not suggesting this is a major issue. For small allocations like these the company with 7 devices is quietly encouraged by the ISP to check off a box that says "14 IP's", since the block below it was "6 IP's." The ISP puts in the records submitted to ARIN customer wanted 14, gave them a /28, all is happy. I point this out only because people toss out that meeting 80% is "trivial", and while for most larger ISP's dealing with a diverse customer base this is true, there are definitely some corner cases that cause people trouble. I won't suggest they are lying, abusing the system, or otherwise cheating, but it's very much the case that they have to tell a particular version of the truth to pass the rules. -- 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 Jul 23 10:50:42 2003 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Wed, 23 Jul 2003 15:50:42 +0100 Subject: [ppml] How transitive is utilization? Message-ID: >> If you've assigned >=80% of your IP space to customers or >> internal use and can justify the assignments, you qualify for another >> assignment. >Not quite. If you get a /23 (to make numbers easier) and allocate >4 customers /25's, but each customer only needed 4 IP's your not >going to pass ARIN's muster, even though you've "assigned" > 80% >of your IP space. The rules are transitive, and apply down stream >as well. If you assign IP's to a customer, they must also meet the >80% rule. Does that mean that if you give those three /25s to a customer and they have them 80% utilized, you can now count these blocks as 100% utilized? Or do you have to audit customer utilization every time you do an ARIN application? >Again, I'm not suggesting this is a major issue. For small allocations >like these the company with 7 devices is quietly encouraged by the >ISP to check off a box that says "14 IP's", since the block below >it was "6 IP's." The ISP puts in the records submitted to ARIN >customer wanted 14, gave them a /28, all is happy. If this is acceptable then we should document it and put it in the policy. It shouldn't be necessary for ARIN members to sneak around and fiddle their IP address accounts in order to run their business. >I point this out only because people toss out that meeting 80% is >"trivial", and while for most larger ISP's dealing with a diverse >customer base this is true, Even large diverse ISPs are supposed to come back to ARIN several times per year for a 3 month supply of IP addresses so it is entirely possible that the analysis of the LAST ALLOCATED NETBLOCK could run into the same corner cases that other people struggle with. In any case, it is not ARIN's business to have policies which penalize smaller companies. That kind of thing would be anti-competitive and definitely would not be tenable in the courts. That's why we need to clean up ARIN's current policies. --Michael Dillon From jlewis at lewis.org Wed Jul 23 11:15:24 2003 From: jlewis at lewis.org (jlewis at lewis.org) Date: Wed, 23 Jul 2003 11:15:24 -0400 (EDT) Subject: [ppml] Increase the flexibility of IP allocations to facilitate planning In-Reply-To: <20030723143054.GA42667@ussenterprise.ufp.org> Message-ID: On Wed, 23 Jul 2003, Leo Bicknell wrote: > > used/assigned/allocated...not how much of the space is actually in use by > > devices, as long as you're being reasonable (following ARIN guidelines) with ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Not quite. If you get a /23 (to make numbers easier) and allocate > 4 customers /25's, but each customer only needed 4 IP's your not > going to pass ARIN's muster, even though you've "assigned" > 80% Yeah...that wouldn't be reasonable or inline with ARIN guidelines if you assign each customer many times more IPs than they think they may ever need. > of your IP space. The rules are transitive, and apply down stream > as well. If you assign IP's to a customer, they must also meet the > 80% rule. See RFC2050, sections 3.0 and 3.1. I'm beginning to suspect you've never actually personally dealt with ARIN for the purpose of obtaining an IP allocation. > Problem is, if you have a customer with 7 devices (say, a small > office) you have to assign them a /28 for their lan, at 56.2% > utilization (7 + 2) / 16. Now, what happens if you get a /23, and > end up with with 32 customers, each with 7 devices. You've "assigned" > 100% of your IP space, but only 56% of your IP space is in use. By > the letter of the rules I don't belive you meet the 80% rule, yet > you can't do any better. If you're assigning customers the smallest subnets the can fit into, the wasted IPs are irrelevant, and you've utilized the space in accordance with ARIN's rules. % actual usage does not matter. ---------------------------------------------------------------------- Jon Lewis *jlewis at lewis.org*| I route System Administrator | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From bicknell at ufp.org Wed Jul 23 11:15:53 2003 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 23 Jul 2003 11:15:53 -0400 Subject: [ppml] How transitive is utilization? In-Reply-To: References: Message-ID: <20030723151553.GA44314@ussenterprise.ufp.org> In a message written on Wed, Jul 23, 2003 at 03:50:42PM +0100, Michael.Dillon at radianz.com wrote: > Does that mean that if you give those three /25s to a customer and they > have them 80% utilized, you can now count these blocks as 100% utilized? > Or do you have to audit customer utilization every time you do an ARIN > application? http://www.arin.net/policy/ipv4.html ] Reassigning Address Space to Customers ] ] ISPs are required to apply a utilization efficiency criterion in ] providing address space to their customers. To this end, ISPs should ] have documented justification available for each reassignment. ARIN may ] request this justification at any time. If justification is not ] provided, future receipt of allocations may be impacted. In extreme ] cases, existing allocations may be affected. http://www.arin.net/library/rfc/rfc2050.txt ] 4. Operational Guidelines For Registries [snip] ] 2. Regardless of the source of its address space, sub-registries ] (Local IRs, ISPs, etc.) must adhere to the guidelines of its ] regional registry. In turn, it must also ensure that its ] customers follow those guidelines. -- 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 jmcburnett at msmgmt.com Wed Jul 23 11:21:24 2003 From: jmcburnett at msmgmt.com (McBurnett, Jim) Date: Wed, 23 Jul 2003 11:21:24 -0400 Subject: [ppml] Increase the flexibility of IP allocations to facilitate planning Message-ID: <9BF6F06C4BC90746ADD6806746492A332AEBD9@msmmail01.msmgmt.com> >From John Lewis: Yeah...that wouldn't be reasonable or inline with ARIN guidelines if you assign each customer many times more IPs than they think they may ever need. --- Isn't there 1 caveat to that? multi-homeing? I multihome- but I dont use 80%. And there is no way to multihome with a /26 We are growing.... but...... Jim From memsvcs at arin.net Wed Jul 23 16:59:52 2003 From: memsvcs at arin.net (Member Services) Date: Wed, 23 Jul 2003 16:59:52 -0400 (EDT) Subject: [ppml] RIR Comparative Policy Overview 2.0 Released Message-ID: ARIN is pleased to announce that version 2.0 of the "RIR Comparative Policy Overview" is now available at: http://www.arin.net/library/internet_info/rir_comp_matrix.html This version has been substantially revised and now includes policy information for LACNIC. This is a public document that is reviewed and revised through the coordinated efforts of the RIRs. The goal of this document is to provide a comparative overview of the policies in the RIR system. It is not a policy statement by the RIRs, but serves as a reference for the Internet community. Best Regards, Member Services American Registry for Internet Numbers (ARIN) From jlewis at lewis.org Wed Jul 23 21:29:19 2003 From: jlewis at lewis.org (jlewis at lewis.org) Date: Wed, 23 Jul 2003 21:29:19 -0400 (EDT) Subject: [ppml] Increase the flexibility of IP allocations to facilitate planning In-Reply-To: <9BF6F06C4BC90746ADD6806746492A332AEBD9@msmmail01.msmgmt.com> Message-ID: On Wed, 23 Jul 2003, McBurnett, Jim wrote: > Yeah...that wouldn't be reasonable or inline with ARIN guidelines if you > assign each customer many times more IPs than they think they may ever > need. > --- > > Isn't there 1 caveat to that? > multi-homeing? > I multihome- but I dont use 80%. That's a special case that's been handled. If you're mulihomed, that's justification enough for a /24. http://www.arin.net/policy/2001_2.html > And there is no way to multihome with a /26 Technically, there's nothing stopping you from announcing your /26 to multiple providers...but I suspect lots of networks would ignore the route (and use the less specific to get at least back to the provider that assigned it to you...and if they peer with your other provider, packets might still get to you if your primary link is down). ---------------------------------------------------------------------- Jon Lewis *jlewis at lewis.org*| I route System Administrator | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From baldwinL at mynetwatchman.com Thu Jul 24 06:49:32 2003 From: baldwinL at mynetwatchman.com (Lawrence Baldwin) Date: Thu, 24 Jul 2003 06:49:32 -0400 Subject: [ppml] Proposal: make Abuse Handle *REQUIRED* for AS Registration Message-ID: As some here may know I run the myNetWatchman system and spend much of my time identifying host on the Internet that have been compromised or are being used for nefarious purposes. One would assume that the detection of such issues is the complicated part of this process. In reality, detection is almost trivial, but the process of figuring out who to notify ends up being far more difficult because backtracing information (e.g. IP Whois) is extremely unreliable and quickly out of date, or doesn't explictly provide abuse handle info. I was very surprised that specifying an Abuse Handle is optional...even for new registration requests: [from AS Registration template] ##################### CONTACT SECTION (Optional) ##################### ## The person or role in this section serves as a supplemental ## contact to the organization POC(s). To specify multiple ## contacts, duplicate lines 9 and 10. 10. POC Type: ## Specify T for Technical, AB for Abuse, or N for Network ## Operations Center. 11. POC Handle: ## Provide a registered ARIN POC handle. Why shouldn't we make Abuse handles REQUIRED for new IP Registrations? Ok, at a bare minimum, why not at least make them required for new AS Registrations? Also, why not provide info in the template (or help guides) to encourage compliance with: http://www.ietf.org/rfc/rfc2142.txt If every AS and IP Whois record had an abuse@ or security@ mailbox the Internet would be a MUCH safer place. Regards, Lawrence Baldwin Chief Forensics Officer myNetWatchman.com Atlanta, GA +1.678.624.0924 From bmanning at karoshi.com Thu Jul 24 07:15:44 2003 From: bmanning at karoshi.com (bmanning at karoshi.com) Date: Thu, 24 Jul 2003 04:15:44 -0700 (PDT) Subject: [ppml] Proposal: make Abuse Handle *REQUIRED* for AS Registration In-Reply-To: from "Lawrence Baldwin" at Jul 24, 2003 06:49:32 AM Message-ID: <200307241115.h6OBFiI15108@karoshi.com> > If every AS and IP Whois record had an abuse@ or security@ mailbox the > Internet would be a MUCH safer place. why do you think that these contacts would be kept any more current/correct than the already -REQUIRED- contacts, e.g. root and postmaster contacts/accounts are -REQUIRED- so why not use those instead? your presumption that adding more required email role accounts will make things safer does not appear to me to be well grounded. > > Regards, > > Lawrence Baldwin > Chief Forensics Officer > myNetWatchman.com > Atlanta, GA > +1.678.624.0924 > From jlewis at lewis.org Thu Jul 24 08:36:10 2003 From: jlewis at lewis.org (jlewis at lewis.org) Date: Thu, 24 Jul 2003 08:36:10 -0400 (EDT) Subject: [ppml] Proposal: make Abuse Handle *REQUIRED* for AS Registration In-Reply-To: <200307241115.h6OBFiI15108@karoshi.com> Message-ID: On Thu, 24 Jul 2003 bmanning at karoshi.com wrote: > > If every AS and IP Whois record had an abuse@ or security@ mailbox the > > Internet would be a MUCH safer place. > > why do you think that these contacts would be kept any more > current/correct than the already -REQUIRED- contacts, e.g. Even if they're correct, who's to say anyone will actually read them? Incorrect email contacts are a problem though...both an annoyance when spam complaints sent to them bounce and in some cases a facilitator of network hijacking. Perhaps registries (not just ARIN) could consider sending monthly or quarterly ping messages to all contacts, and auto-remove the ones that bounce, while sending a notification of such action to the remaining functional contacts on the record. ---------------------------------------------------------------------- Jon Lewis *jlewis at lewis.org*| I route System Administrator | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From sigma at smx.pair.com Thu Jul 24 10:08:07 2003 From: sigma at smx.pair.com (sigma at smx.pair.com) Date: Thu, 24 Jul 2003 10:08:07 -0400 (EDT) Subject: [ppml] Proposal: make Abuse Handle *REQUIRED* for AS Registration In-Reply-To: from Lawrence Baldwin at "Jul 24, 3 06:49:32 am" Message-ID: <20030724140807.83497.qmail@smx.pair.com> > Why shouldn't we make Abuse handles REQUIRED for new IP Registrations? The AC discussed this issue in the context of policy proposals 2003-1 and 2003-2. The argument against not requiring the handle is the belief that it will be no better maintained or utilized than any existing data. Certainly any organization which staffs an abuse role separately from the tech role can use the abuse contact and benefit from the separation of tasks which that theoretically provides. For every other organization, the extra listing would just be redundant clutter. > If every AS and IP Whois record had an abuse@ or security@ mailbox the > Internet would be a MUCH safer place. No, it would be the same Internet we already have. If abuse@ goes to the same place as the tech contact, then nothing has been gained. In many organizations, there is no separate person or staff to handle an abuse/security function. Kevin From baldwinL at mynetwatchman.com Thu Jul 24 11:24:49 2003 From: baldwinL at mynetwatchman.com (Lawrence Baldwin) Date: Thu, 24 Jul 2003 11:24:49 -0400 Subject: [ppml] Proposal: make Abuse Handle *REQUIRED* for AS Registration In-Reply-To: <200307241115.h6OBFiI15108@karoshi.com> Message-ID: > why do you think that these contacts would be kept any more > current/correct than the already -REQUIRED- contacts, e.g. > root and postmaster contacts/accounts are -REQUIRED- > so why not use those instead? > your presumption that adding more required email role accounts > will make things safer does not appear to me to be well grounded. You are absolutely right, requiring abuse handles to be *specified* is just one component of changes that are sorely needed. I also believe that ALL specified email addresses, whether for Tech or Abuse handles MUST be *verified* by means of an acknowledgement email (this is standard procedures for most web registration systems...why not for ARIN?) AND (as jlewis suggests) contact emails should be re-validated (via email acknowledgement) periodically...e.g. once per quarter. I am less excited about the validation process as I expect there is no way to enforce any *consequence* of failing to keep a valid email in your handles. If there are no consquences, then there is no incentive and sadly that just means it will ultimately go stale. Its a very sad day when a 1MM user ISP (he who shall not be named) has an AS Tech handle who left the company 5 YEARS ago! However, it is very easy to enforce this requirement during the registration process...bottom-line, if you don't provide a abuse and tech contact AND both mailboxes are validated via acknowledgement email ... you don't get your assignment...simple as that. If there is some way to create consequences of not keeping this info up to date I'm all for that...within reason. IMHO, the inability to identify and contact the responsible party for a given network is a very serious security vulnerability. I don't pretend to have all the answers, and I expect this process will never approach perfection, however, if there are some simple and practical things we can do to *improve* the process, by all means. I expect that focusing on AS contact info first would be a vast improvement as it provides a very straightforward backtracing process. I currently *try* to identify appropriate abuse contacts for over 240,000 domains...I'd guess that only 50-60% of them are correct. I'd MUCH rather invest my time trying to identify/validate contacts for the < 30,000 AS #'s that are out there. Still not trivial, but an order of magnitude easier. I detect about 4 compromised hosts per MINUTE, sending over 5,000 security notices/day...plus another 10,000-15,000 secondary notices/day ... I would be very happy if I had some degree of confidence that these notices were actually being received and read by someone. An added bonus would be if they cared. ;) Lawrence Baldwin myNetWatchman.com From baldwinL at mynetwatchman.com Thu Jul 24 12:00:05 2003 From: baldwinL at mynetwatchman.com (Lawrence Baldwin) Date: Thu, 24 Jul 2003 12:00:05 -0400 Subject: [ppml] Proposal: make Abuse Handle *REQUIRED* for AS Registration In-Reply-To: <20030724140807.83497.qmail@smx.pair.com> Message-ID: > The AC discussed this issue in the context of policy proposals 2003-1 and > 2003-2. The argument against not requiring the handle is the belief that > it will be no better maintained or utilized than any existing data. > Certainly any organization which staffs an abuse role separately from the > tech role can use the abuse contact and benefit from the separation of > tasks which that theoretically provides. For every other organization, the > extra listing would just be redundant clutter. OK, perhaps I am mis-understanding something. You seem to be implying that if a registrant elects NOT to specify an abuse handle, then the Internet community should consider the Tech handle to be the abuse contact? I have NOT been operating under this assumption. I assume the tech handle for an AS registration is NOT the abuse contact, but rather a router engineer. I'm trying to be very, very careful about what contact I start sending notices to as maintaing my reputation in the security community is my primary concern. >No, it would be the same Internet we already have. If abuse@ goes to the >same place as the tech contact, then nothing has been gained. In many >organizations, there is no separate person or staff to handle an >abuse/security function. Again, I think this is a side affect of my potential mis-understanding above. If I can't identify a specific abuse contact, I do NOT send a notice...or I just default to postmaster@ ... which ultimately goes no where, or isn't monitored by a human. I retract my suggestion that an abuse handle should be mandatory, if it's considered acceptable to notify the tech handle in it's absence. Regards, Lawrence Baldwin myNetWatchman.com From Michael.Dillon at radianz.com Thu Jul 24 12:18:42 2003 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 24 Jul 2003 17:18:42 +0100 Subject: [ppml] Proposal: make Abuse Handle *REQUIRED* for AS Registration Message-ID: >You seem to be implying that if a registrant elects NOT to specify an abuse >handle, then the Internet community should consider the Tech handle to be >the abuse contact? >I have NOT been operating under this assumption. I assume the tech handle >for an AS registration is NOT the abuse contact, but rather a router >engineer. I'm trying to be very, very careful about what contact I start >sending notices to as maintaing my reputation in the security community is >my primary concern. You're doing the right thing. If you want to send a stream of abuse to a network operator then you should use the abuse contact and not the technical contact. Technical contacts should only be used when there are technical issues that require skilled technical intervention. Abuse contacts are used for mail which can be safely ignored (abuse) or which can be handled administratively such as cancelling an account. >If I can't identify a specific abuse contact, I do NOT send a notice...or I >just default to postmaster@ ... which ultimately goes no where, or isn't >monitored by a human. May I suggest that if you cannot identify an abuse contact to receive your messages, you should store all the info in a database-backed web server and send a single weekly message to the technical contact stating: In the week from July 14th 2003 to July 20th 2003 inclusive, your ip address range was the source of 7,893 separate incidents of network abuse. In order to assist you in tracking these incidents and reducing their impact, we have detailled reports on all incidents available at http://www.example.com/incidents/worldcom/20030720/ If you would like to receive these notices when the incidents are still fresh, please create an Abuse using the ARIN template at http://www.arin.net/library/templates/asnmod.txt Oh, and while you're at it, why not put all of this stuff into an LDAP server as well so that nobody gets the idea of using BGP peering sessions to distribute up to date abuse contact info. --Michael Dillon From baldwinL at mynetwatchman.com Thu Jul 24 12:53:22 2003 From: baldwinL at mynetwatchman.com (Lawrence Baldwin) Date: Thu, 24 Jul 2003 12:53:22 -0400 Subject: [ppml] Proposal: make Abuse Handle *REQUIRED* for AS Registration In-Reply-To: Message-ID: Michael Dillon wrote: >May I suggest that if you cannot identify an abuse contact to receive your >messages, you should store all the info in a database-backed web server >and send a single weekly message to the technical contact stating: > In the week from July 14th 2003 to July 20th 2003 inclusive, your ip > address range was the source of 7,893 separate incidents of network abuse. In Fantastic suggestion! I could do something like that for the first 30 day or so and then turn on the firehose if it get's ignored. I love it. >Oh, and while you're at it, why not put all of this stuff into an LDAP >server as well so that nobody gets the idea of using BGP peering sessions >to distribute up to date abuse contact info. I'm losing you here... Please explain? --Lawrence Baldwin From sigma at smx.pair.com Thu Jul 24 12:56:45 2003 From: sigma at smx.pair.com (sigma at smx.pair.com) Date: Thu, 24 Jul 2003 12:56:45 -0400 (EDT) Subject: [ppml] Proposal: make Abuse Handle *REQUIRED* for AS Registration In-Reply-To: from Lawrence Baldwin at "Jul 24, 3 12:00:05 pm" Message-ID: <20030724165645.2528.qmail@smx.pair.com> > OK, perhaps I am mis-understanding something. > > You seem to be implying that if a registrant elects NOT to specify an abuse > handle, then the Internet community should consider the Tech handle to be > the abuse contact? I'm fairly certain that almost everyone has been operating under this assumption, whether warranted or not. Particularly as there exists an optional abuse contact, if one isn't provided, the tech contact seems like an implicit fallback. The other assumption, that the netblock owner does not wish to be contacted regarding abuse, seems intractable. > I have NOT been operating under this assumption. I assume the tech handle > for an AS registration is NOT the abuse contact, but rather a router > engineer. I'm trying to be very, very careful about what contact I start > sending notices to as maintaing my reputation in the security community is > my primary concern. I understand that, certainly. Likely many tech contacts do not wish to receive abuse-related e-mails, whether from automated systems or not. Yet their remedy should be to register an abuse contact and handle the e-mail received there as appropriate. > If I can't identify a specific abuse contact, I do NOT send a notice...or I > just default to postmaster@ ... which ultimately goes no where, or isn't > monitored by a human. Well, postmaster@ should ultimately go somewhere, but it's even less likely to be the correct, recipient, I would believe. Kevin From bmanning at vacation.karoshi.com Thu Jul 24 13:06:19 2003 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 24 Jul 2003 10:06:19 -0700 Subject: [ppml] Proposal: make Abuse Handle *REQUIRED* for AS Registration In-Reply-To: <20030724165645.2528.qmail@smx.pair.com>; from sigma@smx.pair.com on Thu, Jul 24, 2003 at 12:56:45PM -0400 References: <20030724165645.2528.qmail@smx.pair.com> Message-ID: <20030724100619.C16740@vacation.karoshi.com> On Thu, Jul 24, 2003 at 12:56:45PM -0400, sigma at smx.pair.com wrote: > I understand that, certainly. Likely many tech contacts do not wish to > receive abuse-related e-mails, whether from automated systems or not. Yet > their remedy should be to register an abuse contact and handle the e-mail > received there as appropriate. and /dev/null abuse email... esp. if someone turns on a "firehose" that looks like DoS > > > If I can't identify a specific abuse contact, I do NOT send a notice...or I > > just default to postmaster@ ... which ultimately goes no where, or isn't > > monitored by a human. > > Well, postmaster@ should ultimately go somewhere, but it's even less likely > to be the correct, recipient, I would believe. > > Kevin From sigma at smx.pair.com Thu Jul 24 13:03:53 2003 From: sigma at smx.pair.com (sigma at smx.pair.com) Date: Thu, 24 Jul 2003 13:03:53 -0400 (EDT) Subject: [ppml] Proposal: make Abuse Handle *REQUIRED* for AS Registration In-Reply-To: <20030724165645.2528.qmail@smx.pair.com> from "sigma@smx.pair.com" at "Jul 24, 3 12:56:45 pm" Message-ID: <20030724170353.3385.qmail@smx.pair.com> > I'm fairly certain that almost everyone has been operating under this > assumption, whether warranted or not. Particularly as there exists an > optional abuse contact, if one isn't provided, the tech contact seems like > an implicit fallback. The other assumption, that the netblock owner does > not wish to be contacted regarding abuse, seems intractable. Replying to myself, I would like to say that Dillon-San's suggestion was much better - to fallback on the tech contact but at a very low volume so you're more likely to be received kindly. Kevin From andrew.dul at quark.net Thu Jul 24 13:09:05 2003 From: andrew.dul at quark.net (Andrew Dul) Date: Thu, 24 Jul 2003 10:09:05 -0700 Subject: [ppml] Proposal: make Abuse Handle *REQUIRED* for AS Registration Message-ID: <3.0.5.32.20030724100905.022c3138@pop3.quark.net> At 08:36 AM 7/24/2003 -0400, you wrote: > > >Perhaps registries (not just ARIN) could consider sending monthly or >quarterly ping messages to all contacts, and auto-remove the ones that >bounce, while sending a notification of such action to the remaining >functional contacts on the record. The AC is currently evaluating text which we are planning on presenting for comment shortly. This policy will provide a process for ARIN to evaluate the accuracy of POC data and publish the accuracy as part of a whois query. I hope to have this text posted soon for comment before the meeting in October. Andrew Dul ARIN AC From baldwinL at mynetwatchman.com Thu Jul 24 14:08:18 2003 From: baldwinL at mynetwatchman.com (Lawrence Baldwin) Date: Thu, 24 Jul 2003 14:08:18 -0400 Subject: [ppml] Proposal: make Abuse Handle *REQUIRED* for AS Registration In-Reply-To: <9BF6F06C4BC90746ADD6806746492A332AEC03@msmmail01.msmgmt.com> Message-ID: -- Jim McBurnett wrote: >I would like to have a clause that after 3 cycles of the failed attempt >that the assignments be pulled........ But we know that can't happen... >(3 cycles- 1 cycle per quarter--- so 9 months) >If a user can't have a mail server working in 9 months......... I am totally with you. I agree that in a practical sense you can't go round ripping peoples assignments immediately just because they failed to perform proper account maintenance. However that has to ultimately be a reprecussion...and frankly I really don't care how generous it is...4 weeks, 2 months, 6 months...doesn't much matter to me....I think any time limit would have a positve effect. People know that if they don't re-register their Domain, they'll ultimatley lose that domain. Though we have similar stale info problems in Domain Whois, I'm guessing it is MUCH less of a problem becaue of this (although with 10yr registrations it may well get worse again). We need something on the IP/AS side to encourage proper account maint. -- Lawrence. From memsvcs at arin.net Thu Jul 24 17:07:20 2003 From: memsvcs at arin.net (Member Services) Date: Thu, 24 Jul 2003 17:07:20 -0400 (EDT) Subject: [ppml] Policy Proposal 2003-3: Residential Customer Privacy Message-ID: <200307242107.RAA04027@ops.arin.net> This policy proposal was previously discussed on this mailing list and at the ARIN XI Public Policy Meeting. Based on the feedback received from those discussions, the language of this policy proposal has been modified. This proposal is open for discussion on this mailing list and will be discussed at the upcoming ARIN XII Public Policy Meeting scheduled for October, 2003. Member Services American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal 2003-3: Residential Customer Privacy ISPs with downstream residential customers may substitute that ISP's name for the customer's name, e.g. 'Private customer - XYZ Network', and the customer's street address may read 'Private Residence.' Each private downstream residential reassignment must have accurate upstream Abuse and Technical POCs visible on the WHOIS record for that block. From ppml at rsuc.gweep.net Thu Jul 24 19:43:11 2003 From: ppml at rsuc.gweep.net (Joe Provo) Date: Thu, 24 Jul 2003 19:43:11 -0400 Subject: [ppml] Proposal: make Abuse Handle *REQUIRED* for AS Registration In-Reply-To: <200307241115.h6OBFiI15108@karoshi.com> References: <200307241115.h6OBFiI15108@karoshi.com> Message-ID: <20030724234311.GA56307@gweep.net> On Thu, Jul 24, 2003 at 04:15:44AM -0700, bmanning at karoshi.com wrote: > > If every AS and IP Whois record had an abuse@ or security@ mailbox the > > Internet would be a MUCH safer place. > > why do you think that these contacts would be kept any more > current/correct than the already -REQUIRED- contacts, e.g. > > root and postmaster contacts/accounts are -REQUIRED- > so why not use those instead? > > your presumption that adding more required email role accounts > will make things safer does not appear to me to be well grounded. What's required is some form of enforcement process for outright bogus/stale data. Merely noting "goshg this is stale" Doesn't Cut It. At the very least, why are there not entries in the ARIN IRR registry for ALL the data over which they have responsibility? The base /8s, the as-yet unallocated blocks, and the known stale/bogus blocks could be trivially represnted iby the authoritative party in a way that can help stem the abuse. Yes, people who want to believe RobT's definition of bogon can use his server, but when the authoritative registry doesn't do all they can to note the abuse, what motivation is there for the rest of us paying and non-abusing members supposed to both continue to pay and not abuse the system? The registries must police that over which they have registration authority and when something is called into question flag it and jump up and down in *every* possible way such that it will be squashed. % whois -h whois.arin.net 146.20.36.0 OrgName: Erie Forge and Steel OrgID: EFS Address: 1341 West 16th Street Address: P.O. Box 180 Address: Erie, PA, 16512 City: StateProv: PostalCode: Country: US NetRange: 146.20.0.0 - 146.20.255.255 CIDR: 146.20.0.0/16 NetName: IWAVE NetHandle: NET-146-20-0-0-1 Parent: NET-146-0-0-0-0 NetType: Direct Allocation Comment: The information for this network has been reported to Comment: be invalid. ARIN has attempted to obtain updated data, but has Comment: been unsuccessful. To provide current contact information, Comment: please e-mail hostmaster at arin.net. RegDate: 1991-01-18 Updated: 2003-06-30 % whois -h whois.ra.net 146.20.0.0/16 % No entries found for the selected source(s). % whois -h rr.arin.net 146.20.0.0/16 % ARIN Internet Routing Registry Whois Interface % No entries found in ANS, ARCSTAR, ARIN, BCONNEX, % BELL, CANET, CW, FGC, KOREN, LEVEL3, POC, RADB, RIPE and VERIO database. % route-views.oregon-ix.net>sho ip bgp 146.20.0.0/16 lo | inc / * 146.20.36.0/22 217.75.96.60 0 16150 8434 3549 10910 10910 10910 20473 i * 146.20.40.0/21 217.75.96.60 0 16150 8434 3549 10910 10910 10910 20473 i * 146.20.48.0/20 217.75.96.60 0 16150 8434 3549 10910 10910 10910 20473 23131 i * 146.20.64.0/19 217.75.96.60 0 16150 8434 3257 8001 3638 12277 i * 146.20.80.0/21 204.42.253.253 2 0 267 2914 4474 3638 12277 i * 146.20.88.0/22 204.42.253.253 2 0 267 2914 4474 3638 12277 i route-views.oregon-ix.net> joe "forge and steal?" how many origin ASns for the single allocation (not deaggregated)? Hrmmmm..... -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From jrace at attglobal.net Thu Jul 24 08:54:16 2003 From: jrace at attglobal.net (Dr. Jeffrey Race) Date: Thu, 24 Jul 2003 19:54:16 +0700 Subject: [ppml] Proposal: make Abuse Handle *REQUIRED* for AS Registration Message-ID: On Thu, 24 Jul 2003 19:43:11 -0400, Joe Provo wrote: >What's required is some form of enforcement process for outright >bogus/stale data. Perhaps look for concepts at a draft of an idea Jeffrey Race From william at elan.net Thu Jul 24 19:23:52 2003 From: william at elan.net (william at elan.net) Date: Thu, 24 Jul 2003 16:23:52 -0700 (PDT) Subject: [ppml] Proposal: make Abuse Handle *REQUIRED* for AS Registration In-Reply-To: <20030724234311.GA56307@gweep.net> Message-ID: Erie Forge & Steel 146.20.0.0/16 is one of the hijacked ip blocks, so hijacker had previously swipped ips there to other companies and they have not yet stopped using it (their upstreams are all notified). As some of the people here know I've been keeping track of ip hijacking activities at http://www.completewhois.com/hijacked/ Most of the hijacked ip blocks end up being changed by ARIN to say its information is invalid (eventhough I have identified likely proper owners for over 90% of ip blocks and have made contacts with around 40% of them, very few have yet provided arin necessary documentation to delete ip block or transfer it. ARIN itself is not doing much to directly contact these companies based on the information I provide, though they may try to use their/internic original whois data and having failed to make contact based on that list ip block as invalid) In the future (likely by September 1st) I will also have list of these "invalid" ip blocks made available as part of bogons project (http://www.completewhois.com/bogons/ is where this will be available) and I'll most likely in the future provide this list in radb-like whois format as well. However I fully support having it done more officially directly by ARIN (I'm afraid some may consider it as having arin getting directly involved in routing and this idea will get blocked because of that, but we have to talk about this more though at the very least). On Thu, 24 Jul 2003, Joe Provo wrote: > On Thu, Jul 24, 2003 at 04:15:44AM -0700, bmanning at karoshi.com wrote: > > > If every AS and IP Whois record had an abuse@ or security@ mailbox the > > > Internet would be a MUCH safer place. > > > > why do you think that these contacts would be kept any more > > current/correct than the already -REQUIRED- contacts, e.g. > > > > root and postmaster contacts/accounts are -REQUIRED- > > so why not use those instead? > > > > your presumption that adding more required email role accounts > > will make things safer does not appear to me to be well grounded. > > What's required is some form of enforcement process for outright > bogus/stale data. Merely noting "goshg this is stale" Doesn't Cut > It. At the very least, why are there not entries in the ARIN IRR > registry for ALL the data over which they have responsibility? > The base /8s, the as-yet unallocated blocks, and the known > stale/bogus blocks could be trivially represnted iby the > authoritative party in a way that can help stem the abuse. > > Yes, people who want to believe RobT's definition of bogon can > use his server, but when the authoritative registry doesn't do > all they can to note the abuse, what motivation is there for the > rest of us paying and non-abusing members supposed to both > continue to pay and not abuse the system? The registries must > police that over which they have registration authority and when > something is called into question flag it and jump up and down > in *every* possible way such that it will be squashed. > > > % whois -h whois.arin.net 146.20.36.0 > OrgName: Erie Forge and Steel > OrgID: EFS > Address: 1341 West 16th Street > Address: P.O. Box 180 > Address: Erie, PA, 16512 > City: > StateProv: > PostalCode: > Country: US > > NetRange: 146.20.0.0 - 146.20.255.255 > CIDR: 146.20.0.0/16 > NetName: IWAVE > NetHandle: NET-146-20-0-0-1 > Parent: NET-146-0-0-0-0 > NetType: Direct Allocation > Comment: The information for this network has been reported to > Comment: be invalid. ARIN has attempted to obtain updated data, but > has > Comment: been unsuccessful. To provide current contact information, > Comment: please e-mail hostmaster at arin.net. > RegDate: 1991-01-18 > Updated: 2003-06-30 > > % whois -h whois.ra.net 146.20.0.0/16 > % No entries found for the selected source(s). > > % whois -h rr.arin.net 146.20.0.0/16 > > % ARIN Internet Routing Registry Whois Interface > > % No entries found in ANS, ARCSTAR, ARIN, BCONNEX, > % BELL, CANET, CW, FGC, KOREN, LEVEL3, POC, RADB, RIPE and VERIO database. > > % > > route-views.oregon-ix.net>sho ip bgp 146.20.0.0/16 lo | inc / > * 146.20.36.0/22 217.75.96.60 0 16150 8434 3549 10910 10910 10910 20473 i > * 146.20.40.0/21 217.75.96.60 0 16150 8434 3549 10910 10910 10910 20473 i > * 146.20.48.0/20 217.75.96.60 0 16150 8434 3549 10910 10910 10910 20473 23131 i > * 146.20.64.0/19 217.75.96.60 0 16150 8434 3257 8001 3638 12277 i > * 146.20.80.0/21 204.42.253.253 2 0 267 2914 4474 3638 12277 i > * 146.20.88.0/22 204.42.253.253 2 0 267 2914 4474 > 3638 12277 i > route-views.oregon-ix.net> > > > joe "forge and steal?" how many origin ASns for the single allocation (not > deaggregated)? Hrmmmm..... > > From Michael.Dillon at radianz.com Fri Jul 25 04:31:48 2003 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Fri, 25 Jul 2003 09:31:48 +0100 Subject: [ppml] LDAP? Why not? Message-ID: >>Oh, and while you're at it, why not put all of this stuff into an LDAP >>server as well so that nobody gets the idea of using BGP peering sessions >>to distribute up to date abuse contact info. >I'm losing you here... >Please explain? It's my pet theory. I believe that if everyone published their directory type information using LDAP the world would be a better place. Examples include the whois directory, the various BGP and DNS based spammer blacklists like ORBS and the DUL. Instead of hacking BGP and/or DNS to do something they weren't intended to we would just write an LDAP schema (kind of like a data description) and then use an LDAP server. The DNS would only be used as a locator mechanism to find the right LDAP server _lwhois._tcp.example.com SRV lwhois.example.com lwhois.example.com A 192.0.0.7 You could publish a directory of ASes originating abuse which you have detected and you could put all the reporting details into the directory instead of spewing out emails to abuse.example.com. Then, once a week, you could send a single email to a known good contact at example.com reporting the number of incidents in your directory and giving them the password needed to access the full details of their incidents. LDAP makes it easy to protect parts of the directory with passwords. The public would only be able to browse the high level stats on on incidents and the origin ASes could get at the details. But, since LDAP is a protocol, the origin ASes could plug their own applications into your directory and do things like poll for new incidents every 15 minutes. It is a lot harder to do stuff like this if you have to parse the text of email messages or web pages. Basically, I think the world should stop writing new text parsers and start using the existing standard data encapsulation protocols like LDAP, etc. If you decide to seriously do something like this, you might want to discuss it with Rob Thomas from Team Cymru because he has expressed some level of interest in publishing his directories using LDAP. You can find out more at the Bogon project http://www.cymru.com/BGP/bogon-rs.html --Michael Dillon From baldwinL at mynetwatchman.com Fri Jul 25 10:33:03 2003 From: baldwinL at mynetwatchman.com (Lawrence Baldwin) Date: Fri, 25 Jul 2003 10:33:03 -0400 Subject: [ppml] Proposal: make Abuse Handle *REQUIRED* for AS Registration In-Reply-To: Message-ID: There are definite cases where using AS contact info for directing abuse/securty issues is NOT appropriate. Case in point: http://www.cyberangels.nl These jokers had their own AS # and were probably the biggest source of open proxy scans for this year...once I ultimately figured that out we started going to their upstream AS's to get them yanked. Fortunately these situations are relatively rare. --Lawrence Baldwin myNetWatchman.com From leslie at thinkingcat.com Fri Jul 25 10:34:04 2003 From: leslie at thinkingcat.com (Leslie Daigle) Date: Fri, 25 Jul 2003 10:34:04 -0400 Subject: [ppml] LDAP? Why not? In-Reply-To: References: Message-ID: <3F213FDC.9070808@thinkingcat.com> FYI, for documentation of a project that put considerable effort into attempting to do just that for domain whois, see http://www.ietf.org/internet-drafts/draft-newton-ldap-whois-03.txt In particular, Section 6 ("Lessons Learned") describes pretty plainly the disappointments that LDAP could not be used "out of the box". E.g., in spite of having created a data model using only standard LDAP objects, etc, the expected benefit of client reuse simply wasn't there. Having made that effort, note that the author of the document (and main proponent of the project) is now behind the *non* LDAP proposal for domain whois replacement in the IETF CRISP working group. Leslie. Michael.Dillon at radianz.com wrote: >>>Oh, and while you're at it, why not put all of this stuff into an LDAP >>>server as well so that nobody gets the idea of using BGP peering > > sessions > >>>to distribute up to date abuse contact info. > > >>I'm losing you here... >>Please explain? > > > It's my pet theory. I believe that if everyone published their directory > type information using LDAP the world would be a better place. Examples > include the whois directory, the various BGP and DNS based spammer > blacklists like ORBS and the DUL. > > Instead of hacking BGP and/or DNS to do something they weren't intended to > we would just write an LDAP schema (kind of like a data description) and > then use an LDAP server. The DNS would only be used as a locator mechanism > to find the right LDAP server > > _lwhois._tcp.example.com SRV lwhois.example.com > lwhois.example.com A 192.0.0.7 > > You could publish a directory of ASes originating abuse which you have > detected and you could put all the reporting details into the directory > instead of spewing out emails to abuse.example.com. Then, once a week, you > could send a single email to a known good contact at example.com reporting > the number of incidents in your directory and giving them the password > needed to access the full details of their incidents. LDAP makes it easy > to protect parts of the directory with passwords. The public would only be > able to browse the high level stats on on incidents and the origin ASes > could get at the details. > > But, since LDAP is a protocol, the origin ASes could plug their own > applications into your directory and do things like poll for new incidents > every 15 minutes. It is a lot harder to do stuff like this if you have to > parse the text of email messages or web pages. Basically, I think the > world should stop writing new text parsers and start using the existing > standard data encapsulation protocols like LDAP, etc. > > If you decide to seriously do something like this, you might want to > discuss it with Rob Thomas from Team Cymru because he has expressed some > level of interest in publishing his directories using LDAP. You can find > out more at the Bogon project http://www.cymru.com/BGP/bogon-rs.html > > --Michael Dillon > > From Michael.Dillon at radianz.com Fri Jul 25 11:00:40 2003 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Fri, 25 Jul 2003 16:00:40 +0100 Subject: [ppml] LDAP? Why not? Message-ID: >FYI, for documentation of a project that put considerable >effort into attempting to do just that for domain whois, see >http://www.ietf.org/internet-drafts/draft-newton-ldap-whois-03.txt >In particular, Section 6 ("Lessons Learned") describes pretty >plainly the disappointments that LDAP could not be used "out >of the box". I've read this document and the lessons learned are not what you claim. In 6.1 they seem to be complaining that their original plan to map the hierarchical domain name structure onto a relational database caused problems. Perhaps that's because a relational database is not a good datastore for hierarchically structured data? In any case, there is more than one way to map an LDAP schema onto a relational database and not all of them suffer this problem. In 6.2 the author points out that the issue was not with LDAP but with a characteristic of the problem they were trying to solve. In 6.3 the author points out that they could have designed a better schema if they had considered the needs of their GUI search client. In 6.4 they discovered that there are no magic bullet solutions that will do everything for everybody. Just because SQL is a standard database access method doesn't mean that you can make a useful SQL client to access any SQL database. Same thing with LDAP. In 6.5 the author noted that they could have designed a more effective data model if they had used DNS SRV records to locate the appropriate LDAP server. In 6.6 they noted that some people really want a bulk data download capability and a directory service isn't a good way to do this. None of these lessons indicate a problem with LDAP. >Having made that effort, note that the author of the document >(and main proponent of the project) is now behind the *non* LDAP >proposal for domain whois replacement in the IETF CRISP working >group. The CRISP working group has defined two different methods for replacing a variety of directory services including domain whois and ip address whois. One of the two methods is based on LDAP and is called FIRS. The bulk of the work in defining FIRS has been to define the LDAP data schema. There is a second proposal called IRIS that is based on XML but that is more complex because XML is just a data format, not a protocol. It remains to be seen whether LDAP's advantage of having a working protocol with referral and replication will overcome the sexiness associated with XML. I'll just note that it is a straightforward mapping to take LDAP data and present it in XML format because the hard work of structuring the data has already been done. If people need to feed XML into other tools, this conversion could easily be done by an LDAP client. --Michael Dillon From leslie at thinkingcat.com Fri Jul 25 12:01:45 2003 From: leslie at thinkingcat.com (Leslie Daigle) Date: Fri, 25 Jul 2003 12:01:45 -0400 Subject: [ppml] LDAP? Why not? In-Reply-To: References: Message-ID: <3F215469.3020507@thinkingcat.com> Responding to your assertions that I have misspoken: Michael.Dillon at radianz.com wrote: >>FYI, for documentation of a project that put considerable >>effort into attempting to do just that for domain whois, see >>http://www.ietf.org/internet-drafts/draft-newton-ldap-whois-03.txt >>In particular, Section 6 ("Lessons Learned") describes pretty >>plainly the disappointments that LDAP could not be used "out >>of the box". > > > I've read this document and the lessons learned are not what you claim. > In 6.1 they seem to be complaining that their original plan to map > the hierarchical domain name structure onto a relational database > caused problems. Perhaps that's because a relational database is not > a good datastore for hierarchically structured data? In any case, there > is more than one way to map an LDAP schema onto a relational database > and not all of them suffer this problem. Really? My reading of 6.1 is that it describes how LDAP *implementations* did not consistently support the LDAP features that would have allowed the server to run with a generic database. To compensate for that, a special-purpose backend would have to be written. My point: LDAP (implementation reality, not protocol) is not as off-the-shelf as we all would have liked to believe. > > In 6.2 the author points out that the issue was not with LDAP but with > a characteristic of the problem they were trying to solve. Sure -- but I'm not picking on LDAP, I'm speaking to the applicability of LDAP as a tool for the problem you're trying to solve. To the extent that you're trying to solve an analogous problem, LDAP (and the referral model, which is what 6.2 is actually talking about) isn't the right tool. > > In 6.3 the author points out that they could have designed a better schema > > if they had considered the needs of their GUI search client. > > In 6.4 they discovered that there are no magic bullet solutions that will > do everything for everybody. Just because SQL is a standard database > access method doesn't mean that you can make a useful SQL client to access > any SQL database. Same thing with LDAP. But this is a key issue. Many (and I'm not saying *yours*, necessarily) arguments for using LDAP are based on the assumption that there exist software clients and servers that will be able to use it straightaway. 6.4 highlights that's a (critical) misconception. > > In 6.5 the author noted that they could have designed a more effective > data > model if they had used DNS SRV records to locate the appropriate LDAP > server. > > In 6.6 they noted that some people really want a bulk data download > capability > and a directory service isn't a good way to do this. > > None of these lessons indicate a problem with LDAP. Agreed on the last point -- the document was about an experience of applying LDAP to a particular problem set. As you have noted, some of the issues were with the particular model used. But some of them are *not*, and I believe the value in having them written down is to allow others to learn from the experience before embarking on the identical path. Your statement was that "if everyone published their directory type information using LDAP the world would be a better place." You called it a pet theory. For anyone on this list interested in reading about experience, not theory, the RLDAP document is worthwhile reading. Leslie. From Michael.Dillon at radianz.com Fri Jul 25 12:30:38 2003 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Fri, 25 Jul 2003 17:30:38 +0100 Subject: [ppml] Policy Proposal 2003-3: Residential Customer Privacy Message-ID: >ISPs with downstream residential customers may substitute >that ISP's name for the customer's name, e.g. 'Private >customer - XYZ Network', and the customer's street address >may read 'Private Residence.' Each private downstream residential >reassignment must have accurate upstream Abuse and Technical POCs >visible on the WHOIS record for that block. It's nice and short, it gets to the point and it is understandable. All good things. But it still is a waste of our time to deal with things like this. This proposal is picking nits, trying to solve a specific special case before we've dealt with the general problem. I suggest that we reject this proposal. What we really need is a proposal that gives us a workable whois policy. We need to clearly state what is the overall purpose of whois and "tradition" is not the right answer. We need to clearly state the data items that will be published in the whois directory and we need to clearly state the purpose of each item to be published. Having defined what the whois directory is, then we can clearly state when whois data should be published and when it should not. I believe that the whois directory is a public directory of contact information for organizations who have registered "objects" with ARIN and that it should provide data items that can be used to contact these organizations. The data items should include things like email addresses, phone numbers, IM userids, URLs and postal addresses but should not contain street addresses unless that is also the organization's postal address. The purpose of each of these data items should be to clearly identify a communication mechanism and an address that can be used to establish prompt two-way communication with a human being. There should be no mandatory email addresses tagged with labels like "abuse" which will likely lead to the email being /dev/nulled because that does not establish two-way communication with a human being. And this whois data should only be published when and if there are human beings at the other end who are ready, willing and able to do something about the communications that they may receive. The only organizations for which it shall be mandatory to publish whois data are those organizations who hold AS numbers. Any organization receiving IP addressed from ARIN who then delegates a portion of those addresses to another organization can choose to submit whois data for the recieving organization if the receiving organization is ready, willing and able to establish communications and take actions. If not, then the responsibility for establishing communications and taking actions remains with the delegator organization. In other words, whois is for publishing contact information for organizations that are ready, willing and able to talk and to act. Yes, it would be good to regularly poll these contacts and to flag the ones that appear to be getting stale and remove the ones that no longer connect. The end result of implementing such a policy will be a clean whois directory and some additional responsibility on the shoulders of the larger ISPs, i.e. they will have to deal with their downstream's abuse or pester their downstreams to provide working whois contact info. Let's try to fix this festering sore, not just stick a bandaid on it. --Michael Dillon P.S. in case you hadn't noticed, residential customers typically are not ready, willing and able to receive communications from random sources and act on them, therefore they just won't be in the directory. P.P.S. we are talking about the public whois directory here, not ARIN's internal databases which they collect from us under NDA. There will, of course, be a lot more detail about allocations and assignments in ARIN's internal systems. From sigma at smx.pair.com Fri Jul 25 12:35:36 2003 From: sigma at smx.pair.com (sigma at smx.pair.com) Date: Fri, 25 Jul 2003 12:35:36 -0400 (EDT) Subject: [ppml] Policy Proposal 2003-3: Residential Customer Privacy In-Reply-To: from "Michael.Dillon@radianz.com" at "Jul 25, 3 05:30:38 pm" Message-ID: <20030725163536.41376.qmail@smx.pair.com> > P.P.S. we are talking about the public whois directory here, not ARIN's > internal > databases which they collect from us under NDA. There will, of course, be > a lot more > detail about allocations and assignments in ARIN's internal systems. How does moving some WHOIS data into an internal database better serve ARIN's community? The details of allocations should be as transparent as reasonably possible, and the level of information in WHOIS at present is sufficient except that it lacks verification - which is a different issue. The idea that an organization should opt out of listing any contact addresses because they aren't willing to communicate regarding problems with their netblock seems quite counterproductive. Kevin From jb at jbacher.com Fri Jul 25 12:39:29 2003 From: jb at jbacher.com (J Bacher) Date: Fri, 25 Jul 2003 11:39:29 -0500 Subject: [ppml] Policy Proposal 2003-3: Residential Customer Privacy In-Reply-To: Message-ID: <5.1.0.14.2.20030725113246.02458950@localhost> At 05:30 PM 7/25/2003 +0100, Michael.Dillon at radianz.com wrote: > >ISPs with downstream residential customers may substitute > >that ISP's name for the customer's name, e.g. 'Private > >customer - XYZ Network', and the customer's street address > >may read 'Private Residence.' Each private downstream residential > >reassignment must have accurate upstream Abuse and Technical POCs > >visible on the WHOIS record for that block. > >It's nice and short, it gets to the point and it is understandable. >All good things. But it still is a waste of our time to deal with >things like this. This proposal is picking nits, trying to solve a >specific special case before we've dealt with the general problem. >I suggest that we reject this proposal. I disagree. If an upstream is willing to assume responsibility for an assignment, the customer is entitled to have non-published information just as it could in the telco world. This is not a nit -- it is a privacy issue that I consider to very important. I seriously doubt that my customers have an AUP let alone one that is published. If you have a problem with any of my residential customers, then I am the authority entitled to determine what action needs to be taken in event of abuse or general problem. If you want the name of the residential customer that is using that IP address(es), then get a subpeona. From Michael.Dillon at radianz.com Fri Jul 25 12:39:52 2003 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Fri, 25 Jul 2003 17:39:52 +0100 Subject: [ppml] LDAP? Why not? Message-ID: >My point: LDAP (implementation reality, not protocol) is not as >off-the-shelf as we all would have liked to believe. I'm not suggesting that LDAP is an off-the-shelf solution but that it is better to use LDAP to build a directory service than to hack up a new protocol or try and shoehorn it into BGP or DNS. >But this is a key issue. Many (and I'm not saying *yours*, necessarily) >arguments for using LDAP are based on the assumption that there exist >software clients and servers that will be able to use it straightaway. >6.4 highlights that's a (critical) misconception. Then we agree on that point. --Michael Dillon From Michael.Dillon at radianz.com Fri Jul 25 12:47:36 2003 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Fri, 25 Jul 2003 17:47:36 +0100 Subject: [ppml] Policy Proposal 2003-3: Residential Customer Privacy Message-ID: >The idea that an organization should opt out of listing any contact >addresses because they aren't willing to communicate regarding problems >with their netblock seems quite counterproductive. Huh!? If they won't communicate then what's the point of publishing any sort of address? At least if there is no address published, you will know right away that communication will be a problem and that you need to find some intermediary like an upstream AS, for instance. Now that is far more productive than a whois directory full of garbage. Down with whois steganography! No more haystack on our needles! --Michael Dillon From sigma at smx.pair.com Fri Jul 25 12:55:17 2003 From: sigma at smx.pair.com (sigma at smx.pair.com) Date: Fri, 25 Jul 2003 12:55:17 -0400 (EDT) Subject: [ppml] Policy Proposal 2003-3: Residential Customer Privacy In-Reply-To: from "Michael.Dillon@radianz.com" at "Jul 25, 3 05:47:36 pm" Message-ID: <20030725165517.42939.qmail@smx.pair.com> > If they won't communicate then what's the point of publishing any sort > of address? At least if there is no address published, you will know > right away that communication will be a problem and that you need to > find some intermediary like an upstream AS, for instance. > > Now that is far more productive than a whois directory full of garbage. Every organization *should* be willing to communicate. Allowing them to opt-out just rolls over and lets organizations "get away with" being non-responsive. That's a problem which would only be made worse by legitimizing non-responsiveness. I'd rather have non-responsive contact addresses, or even outdated contact addresses, than to just say "it's OK, you don't have to have any address, nobody will mind". At least with the former you have some chance of tracking something down. Saying that organizations should be allowed to have no listing seems like completely the wrong idea. Kevin From owen at delong.com Fri Jul 25 14:28:40 2003 From: owen at delong.com (Owen DeLong) Date: Fri, 25 Jul 2003 11:28:40 -0700 Subject: [ppml] Policy Proposal 2003-3: Residential Customer Privacy In-Reply-To: <20030725163536.41376.qmail@smx.pair.com> References: <20030725163536.41376.qmail@smx.pair.com> Message-ID: <2147483647.1059132520@imac-en0.delong.sj.ca.us> As someone who has IP allocations in my house, I must say I can see both sides to this issue. However, we aren't necessarily talking about ORGS in this case. It is not unusual today for end-user consumers to have multiple computers and receive a /28 or /29 from their provider for those computers to share an internet link. We're talking about a family with two working parents and a couple of high-school to college age kids all of whom have their own systems, for example. With the inexpensive availablity of DSL and 802.11, this is becoming less common. This is a good thing. However, I can see the desire of the average household to not publish their home address, names, and phone numbers in whois. I have chosen to publish mine, but I can understand many people choosing not to. In this case, their provider should still have to account for the space to ARIN, but, it is not unreasonable, if the provider chooses to, for the provider to take responsibility for handling abuse complaints and contact about problems with the network. If the provider can't contact the customer and get the issue resolved, they should turn off their access until it is. Owen --On Friday, July 25, 2003 12:35 PM -0400 sigma at smx.pair.com wrote: > >> P.P.S. we are talking about the public whois directory here, not ARIN's >> internal >> databases which they collect from us under NDA. There will, of course, >> be a lot more >> detail about allocations and assignments in ARIN's internal systems. > > How does moving some WHOIS data into an internal database better serve > ARIN's community? The details of allocations should be as transparent as > reasonably possible, and the level of information in WHOIS at present is > sufficient except that it lacks verification - which is a different issue. > > The idea that an organization should opt out of listing any contact > addresses because they aren't willing to communicate regarding problems > with their netblock seems quite counterproductive. > > Kevin > From jamoore2 at vt.edu Fri Jul 25 14:38:26 2003 From: jamoore2 at vt.edu (James T. Moore) Date: Fri, 25 Jul 2003 14:38:26 -0400 Subject: [ppml] Policy Proposal 2003-3: Residential Customer Privacy References: <5.1.0.14.2.20030725113246.02458950@localhost> Message-ID: <002401c352db$f0037620$0464a8c0@vmnet1.mogul.dyndns.org> ----- Original Message ----- From: "J Bacher" To: Sent: Friday, July 25, 2003 12:39 PM Subject: Re: [ppml] Policy Proposal 2003-3: Residential Customer Privacy > If you have a problem with any of my residential customers, then I am the > authority entitled to determine what action needs to be taken in event of > abuse or general problem. I think that this is most often the case. When I run across a problem where I need to contact an abuse contact I would much rather contact the upstream provider(s) and notify them of the problem for serveral reasons: 1. The abuse could be intentional by the abusing organization 2. The abusing organization may lack the technical knowledge and ability to correct the abusive action (i.e. open relays) 3. I am often limited in the action that I can take against the abusing organization if they choose not to take corrective action (outside of time and cost consuming legal action which is often unjustified by the situation, however, an upstream provider can discontinue service to the abusing organization for lack of corrective action) I propose that abuse contacts be required when requesting addresses directly from ARIN, but remain optional when addresses are assigned to a down stream customer. J.T. Moore From db6906 at sbc.com Fri Jul 25 14:44:02 2003 From: db6906 at sbc.com (BARGER, DAVE (SBIS)) Date: Fri, 25 Jul 2003 13:44:02 -0500 Subject: [ppml] Policy Proposal 2003-3: Residential Customer Privacy Message-ID: <6CE0DC2F2ED2B94F80357B939C5674010DE12336@sbis0.sbcis.sbc.com> This policy proposal is not intended to allow "organizations" to opt out of listing contact information. The proposal is expressly targeted at individuals, not organizations. The purpose is to protect the individual's privacy, specifically name and home address. Dave Barger Senior Technical Director Network Engineering IP Management SBC Internet Services 214-473-2098 (office) 877-514-7507 (pager) -----Original Message----- From: sigma at smx.pair.com [mailto:sigma at smx.pair.com] Sent: Friday, July 25, 2003 11:36 AM To: ppml at arin.net Subject: Re: [ppml] Policy Proposal 2003-3: Residential Customer Privacy > P.P.S. we are talking about the public whois directory here, not ARIN's > internal > databases which they collect from us under NDA. There will, of course, be > a lot more > detail about allocations and assignments in ARIN's internal systems. How does moving some WHOIS data into an internal database better serve ARIN's community? The details of allocations should be as transparent as reasonably possible, and the level of information in WHOIS at present is sufficient except that it lacks verification - which is a different issue. The idea that an organization should opt out of listing any contact addresses because they aren't willing to communicate regarding problems with their netblock seems quite counterproductive. Kevin From randy at psg.com Fri Jul 25 14:47:02 2003 From: randy at psg.com (Randy Bush) Date: Fri, 25 Jul 2003 11:47:02 -0700 Subject: [ppml] Policy Proposal 2003-3: Residential Customer Privacy References: <6CE0DC2F2ED2B94F80357B939C5674010DE12336@sbis0.sbcis.sbc.com> Message-ID: > This policy proposal is not intended to allow "organizations" to > opt out of listing contact information. The proposal is expressly > targeted at individuals, not organizations. The purpose is to > protect the individual's privacy, specifically name and home > address. why do organizations not have a valid need for privacy? for example consider socio-political ngos in oppressive regimes. randy From db6906 at sbc.com Fri Jul 25 14:59:53 2003 From: db6906 at sbc.com (BARGER, DAVE (SBIS)) Date: Fri, 25 Jul 2003 13:59:53 -0500 Subject: [ppml] Policy Proposal 2003-3: Residential Customer Privacy Message-ID: <6CE0DC2F2ED2B94F80357B939C5674010DE1239B@sbis0.sbcis.sbc.com> I don't disgree. But the intital focus was specific to residental customer privacy. I just wanted to clarify that point. Dave Barger Senior Technical Director Network Engineering IP Management SBC Internet Services 214-473-2098 (office) 877-514-7507 (pager) -----Original Message----- From: Randy Bush [mailto:randy at psg.com] Sent: Friday, July 25, 2003 1:47 PM To: BARGER, DAVE (SBIS) Cc: ppml at arin.net Subject: RE: [ppml] Policy Proposal 2003-3: Residential Customer Privacy > This policy proposal is not intended to allow "organizations" to > opt out of listing contact information. The proposal is expressly > targeted at individuals, not organizations. The purpose is to > protect the individual's privacy, specifically name and home > address. why do organizations not have a valid need for privacy? for example consider socio-political ngos in oppressive regimes. randy From william at elan.net Fri Jul 25 12:47:51 2003 From: william at elan.net (william at elan.net) Date: Fri, 25 Jul 2003 09:47:51 -0700 (PDT) Subject: [ppml] Policy Proposal 2003-3: Residential Customer Privacy In-Reply-To: <2147483647.1059132520@imac-en0.delong.sj.ca.us> Message-ID: Provider's abuse contacts can be entered in whois, in fact for "simple reassign" there is no new ORG created and no special contact there - just a record on who the ip block is swipped I'm against removing requirement of person's name for swips. It is essential to abuse investigations to have a good reference and in particular to be able to correspond two independent ip ranges (from different ip providers) to the same person or organization or even to just particular name. Address is nice tool, but I understand how it can be missused in public records such as whois, the situation is not the same with only the name. But I do understand privacy issues and will consider it to be acceptable compromise if provider hides real full name by entering something like "John D." instead of "John Doe" but I do not think it is necessary to change policy to allow for this. On Fri, 25 Jul 2003, Owen DeLong wrote: > As someone who has IP allocations in my house, I must say I can see both > sides to this issue. However, we aren't necessarily talking about ORGS > in this case. It is not unusual today for end-user consumers to have > multiple computers and receive a /28 or /29 from their provider for those > computers to share an internet link. We're talking about a family > with two working parents and a couple of high-school to college age kids > all of whom have their own systems, for example. With the inexpensive > availablity of DSL and 802.11, this is becoming less common. This is a > good thing. However, I can see the desire of the average household to > not publish their home address, names, and phone numbers in whois. I have > chosen to publish mine, but I can understand many people choosing not to. > > In this case, their provider should still have to account for the space > to ARIN, but, it is not unreasonable, if the provider chooses to, for the > provider to take responsibility for handling abuse complaints and contact > about problems with the network. If the provider can't contact the customer > and get the issue resolved, they should turn off their access until it is. > > Owen > > > --On Friday, July 25, 2003 12:35 PM -0400 sigma at smx.pair.com wrote: > > > > >> P.P.S. we are talking about the public whois directory here, not ARIN's > >> internal > >> databases which they collect from us under NDA. There will, of course, > >> be a lot more > >> detail about allocations and assignments in ARIN's internal systems. > > > > How does moving some WHOIS data into an internal database better serve > > ARIN's community? The details of allocations should be as transparent as > > reasonably possible, and the level of information in WHOIS at present is > > sufficient except that it lacks verification - which is a different issue. > > > > The idea that an organization should opt out of listing any contact > > addresses because they aren't willing to communicate regarding problems > > with their netblock seems quite counterproductive. > > > > Kevin > > > From john at chagres.net Fri Jul 25 15:15:54 2003 From: john at chagres.net (john at chagres.net) Date: Fri, 25 Jul 2003 13:15:54 -0600 Subject: [ppml] Policy Proposal 2003-3: Residential Customer Privacy In-Reply-To: ; from randy@psg.com on Fri, Jul 25, 2003 at 11:47:02AM -0700 References: <6CE0DC2F2ED2B94F80357B939C5674010DE12336@sbis0.sbcis.sbc.com> Message-ID: <20030725131554.A1609@alderaan.chagres.net> they do, but privacy is a dead horse these days :( and society is apathetic to the issue. On Fri, Jul 25, 2003 at 11:47:02AM -0700, Randy Bush wrote: > > This policy proposal is not intended to allow "organizations" to > > opt out of listing contact information. The proposal is expressly > > targeted at individuals, not organizations. The purpose is to > > protect the individual's privacy, specifically name and home > > address. > > why do organizations not have a valid need for privacy? for example > consider socio-political ngos in oppressive regimes. > > randy > From ppml at rsuc.gweep.net Fri Jul 25 15:16:27 2003 From: ppml at rsuc.gweep.net (Joe Provo) Date: Fri, 25 Jul 2003 15:16:27 -0400 Subject: [ppml] Policy Proposal 2003-3: Residential Customer Privacy In-Reply-To: <6CE0DC2F2ED2B94F80357B939C5674010DE1239B@sbis0.sbcis.sbc.com> References: <6CE0DC2F2ED2B94F80357B939C5674010DE1239B@sbis0.sbcis.sbc.com> Message-ID: <20030725191627.GA50619@gweep.net> On Fri, Jul 25, 2003 at 01:59:53PM -0500, BARGER, DAVE (SBIS) wrote: > I don't disgree. But the intital focus was specific to residental > customer privacy. I just wanted to clarify that point. Psudeo-anonymity/privacy lies in the land of dynamic and NAT'd addressing. If there's a *need* for consumption of finite resources, there's a *need* for accountability. If someone needs 'permanent'/ sizable allocations, why do they need to hide? Is there a theory that the lack of 'privacy' (psuedo-anonymity) is preventing adoption of IP technology? I question the premise that "small home-based businesses" desire to conceal their resource utilization is valid. The phone book analogy is not applicable; if the customer is getting semi-random segments of /32s, that is more like telephone number assignment. Many service providers *do* offer non-contiguous multiple addresses to their end users (and indeed with many technologies that is as easier if not easier to use and implement than 'proper' subnets). A more apt telco analogy for the desire of contiguous netblocks is an organization having an NPA/NXX - are there unlisted entries in the LERG? Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From john at chagres.net Fri Jul 25 15:30:05 2003 From: john at chagres.net (john at chagres.net) Date: Fri, 25 Jul 2003 13:30:05 -0600 Subject: [ppml] Policy Proposal 2003-3: Residential Customer Privacy In-Reply-To: <20030725191627.GA50619@gweep.net>; from ppml@rsuc.gweep.net on Fri, Jul 25, 2003 at 03:16:27PM -0400 References: <6CE0DC2F2ED2B94F80357B939C5674010DE1239B@sbis0.sbcis.sbc.com> <20030725191627.GA50619@gweep.net> Message-ID: <20030725133005.B1609@alderaan.chagres.net> I disagree with your LERG comparison. Having a NPA/NXX "allocation" is NOT the same as having 3 phone lines at home (otherwords an "assignment"). LERG is ALLOCATION Phone number is ASSIGNMENT. The end user is not required under RIR rules to justify usage to the RIR, only the LIR is required to support and justify their usage of the space received from the RIR. If the end user is able meet the LIR's requirements, then that is al they need to do. The telephone company doesn't question me about why I need 3 lines at home. I for one do not want my cable company listing my home address with the static IP I have. Its no ones business where I live, and its most certainly NOT the RIR's domain to require that my home address be listed because I received an assignment. People talk about NAT, some recent state laws could be read as making NAT illegal.... On Fri, Jul 25, 2003 at 03:16:27PM -0400, Joe Provo wrote: > On Fri, Jul 25, 2003 at 01:59:53PM -0500, BARGER, DAVE (SBIS) wrote: > > I don't disgree. But the intital focus was specific to residental > > customer privacy. I just wanted to clarify that point. > > Psudeo-anonymity/privacy lies in the land of dynamic and NAT'd > addressing. If there's a *need* for consumption of finite resources, > there's a *need* for accountability. If someone needs 'permanent'/ > sizable allocations, why do they need to hide? Is there a theory > that the lack of 'privacy' (psuedo-anonymity) is preventing adoption > of IP technology? > > I question the premise that "small home-based businesses" desire to > conceal their resource utilization is valid. The phone book analogy > is not applicable; if the customer is getting semi-random segments > of /32s, that is more like telephone number assignment. Many service > providers *do* offer non-contiguous multiple addresses to their end > users (and indeed with many technologies that is as easier if not > easier to use and implement than 'proper' subnets). A more apt > telco analogy for the desire of contiguous netblocks is an > organization having an NPA/NXX - are there unlisted entries in the > LERG? > > Joe > > -- > RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From bicknell at ufp.org Fri Jul 25 16:08:21 2003 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 25 Jul 2003 16:08:21 -0400 Subject: [ppml] Policy Proposal 2003-3: Residential Customer Privacy In-Reply-To: <6CE0DC2F2ED2B94F80357B939C5674010DE12336@sbis0.sbcis.sbc.com> References: <6CE0DC2F2ED2B94F80357B939C5674010DE12336@sbis0.sbcis.sbc.com> Message-ID: <20030725200821.GA40309@ussenterprise.ufp.org> In a message written on Fri, Jul 25, 2003 at 01:44:02PM -0500, BARGER, DAVE (SBIS) wrote: > This policy proposal is not intended to allow "organizations" to opt out of > listing > contact information. The proposal is expressly targeted at individuals, not > organizations. > The purpose is to protect the individual's privacy, specifically name and > home address. I think a change of terms is in order. This proposal does little to protect people's privacy. I suppose some may think of it as doing that, but that's not the real purpose here. There are two primary purposes to not list someone like a residential customer in whois: 1) To prevent data mineing. Customers don't want to get e-mail, phone calls, or junk snail mail because they signed up for internet service. ISP's also don't want to make their entire customer list, with contacts, available to other ISP's who now have all they need to call those people directly and sell them service. 2) To insure complaints go to the ISP. ISPs in genral want to filter complaints for end users. There are several motovations: A) Catch problems sooner, rather than waiting for someone to fail to contact the customer multiple times before escalating a complaint to the ISP. B) Divert incorrect complaints without bothering the customer. Sometimes the people who complain get it wrong, and the ISP would like thier customer not to have to bother. C) Ensure someone who understands the complaint gets it. Many home users would be completely confused by something like a SpamCop complaint, but the ISP can understand it, and "translate" it into something the customer can understand. IMHO, anyone who receives an allocation from ARIN should be in whois. Downstream of that, the only people in whois (or otherwise publically available) should be people who want to take responsibility for their own abuse complaints. If they aren't going to do that you're better off going to the ISP (via supernet) anyway, so getting a possibly bogus/ignored name/e-mail/phone number is actually just a waste of time. -- 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 randy at psg.com Fri Jul 25 17:18:14 2003 From: randy at psg.com (Randy Bush) Date: Fri, 25 Jul 2003 14:18:14 -0700 Subject: [ppml] Policy Proposal 2003-3: Residential Customer Privacy References: <6CE0DC2F2ED2B94F80357B939C5674010DE1239B@sbis0.sbcis.sbc.com> <20030725191627.GA50619@gweep.net> Message-ID: > If there's a *need* for consumption of finite resources, there's > a *need* for accountability. which is why the RIRs request justification, review engineering plans, etc. despite the current war paranoia and fatherland security, which has us back to putting people in concentration camps again, this does not imply relinquishing one's rights to privacy. > I question the premise that "small home-based businesses" desire > to conceal their resource utilization is valid. we're not discussing their concealing their resource utilization. we're discussing concealing their private contact information from those who really have no need to know it. randy From ppml at rsuc.gweep.net Fri Jul 25 17:59:32 2003 From: ppml at rsuc.gweep.net (Joe Provo) Date: Fri, 25 Jul 2003 17:59:32 -0400 Subject: [ppml] Policy Proposal 2003-3: Residential Customer Privacy In-Reply-To: References: <6CE0DC2F2ED2B94F80357B939C5674010DE1239B@sbis0.sbcis.sbc.com> <20030725191627.GA50619@gweep.net> Message-ID: <20030725215932.GA64530@gweep.net> On Fri, Jul 25, 2003 at 02:18:14PM -0700, Randy Bush wrote: > > If there's a *need* for consumption of finite resources, there's > > a *need* for accountability. > > which is why the RIRs request justification, review engineering > plans, etc. despite the current war paranoia and fatherland [snip] Please; there's nothing here relating to the ashcroft loons. This is just like not wanting bogus domain data. Accountability & responsibility do not equate to jackboots. [snip] > this does not imply relinquishing one's rights to privacy. Interesting to see the arguments used by the "everyone can have their own TLD" crowd pulled out. While there's some municipalities subsidizing connectivity, last I knew the issue of governmental rights of one country were utterly irrelevant to the matter of registration & resource accountability. If an inalienable right to (ip addresses|SLDs|TLDS) came to pass, I must have been pulling a rip van winkle. > > I question the premise that "small home-based businesses" desire > > to conceal their resource utilization is valid. > > we're not discussing their concealing their resource utilization. > we're discussing concealing their private contact information from > those who really have no need to know it. How does a business conduct business under a rock? How do I address the matter of their registered packets hitting my machines if they hide? If they aren't competant enough to handle management/security of the devices attached to their networks, what's wrong with pooled resources? What is to prevent any small enterprise from merely labelling themselves as 'private residence', regardless of the actual zoning regulations of their locality? The public listing criteria for small chunks of space is really the problem. The sole purpose seems to be to remove the responsibility of the ISP: "just contact this 4-node shop directly". It is ridiculous; differentiation between residential and commercial is saying that the residential customers are more valuable to the registry [?] and won't deter any black hats. As far as I know, there's never been an issue with, say, restricting an rwhois server to giving answeres to the ARIN queries and not Q random public ones. Rather than burning the time to split hairs (residential vs soho vs commercial vs ...) in policy and encumbering the registry [and isp] with more steps (checking zoning in N-fold localities), any implication that non-portable small-slice blocks need to be listed should be revoked. The services providers must not abdicate authority for policing their customers. Seriously, adding conditional branches will just bloat the process and beuaracracy further. The public-reporting-of-small-slices was interesting, but we [the membership] don't like the implications given the current network reality and trends. So push the responsibility back where it belongs, on the service provider and their relationship with the registry. Only blocks directly from the registry should be a worry within the registry's database; this would address the concerns covering multihomers/microallocations. Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From bicknell at ufp.org Fri Jul 25 19:01:36 2003 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 25 Jul 2003 19:01:36 -0400 Subject: [ppml] Policy Proposal 2003-3: Residential Customer Privacy In-Reply-To: <20030725215932.GA64530@gweep.net> References: <6CE0DC2F2ED2B94F80357B939C5674010DE1239B@sbis0.sbcis.sbc.com> <20030725191627.GA50619@gweep.net> <20030725215932.GA64530@gweep.net> Message-ID: <20030725230136.GA45974@ussenterprise.ufp.org> In a message written on Fri, Jul 25, 2003 at 05:59:32PM -0400, Joe Provo wrote: > Rather than burning the time to split hairs (residential vs soho vs > commercial vs ...) in policy and encumbering the registry [and isp] > with more steps (checking zoning in N-fold localities), any > implication that non-portable small-slice blocks need to be listed > should be revoked. The services providers must not abdicate authority > for policing their customers. I concur! -- 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 ibaker at codecutters.org Sat Jul 26 04:11:46 2003 From: ibaker at codecutters.org (Ian Baker) Date: Sat, 26 Jul 2003 09:11:46 +0100 Subject: [ppml] Policy Proposal 2003-3: Residential Customer Privacy References: <20030725163536.41376.qmail@smx.pair.com> <2147483647.1059132520@imac-en0.delong.sj.ca.us> Message-ID: <00d401c3534d$91289910$642fa8c0@codecutters.org> ----- Original Message ----- From: "Owen DeLong" To: ; Sent: Friday, July 25, 2003 7:28 PM Subject: Re: [ppml] Policy Proposal 2003-3: Residential Customer Privacy > As someone who has IP allocations in my house, I must say I can see both > sides to this issue. However, we aren't necessarily talking about ORGS > in this case. It is not unusual today for end-user consumers to have > multiple computers and receive a /28 or /29 from their provider for those > computers to share an internet link. We're talking about a family > with two working parents and a couple of high-school to college age kids > all of whom have their own systems, for example. With the inexpensive > availablity of DSL and 802.11, this is becoming less common. This is a > good thing. However, I can see the desire of the average household to > not publish their home address, names, and phone numbers in whois. I have > chosen to publish mine, but I can understand many people choosing not to. > > In this case, their provider should still have to account for the space > to ARIN, but, it is not unreasonable, if the provider chooses to, for the > provider to take responsibility for handling abuse complaints and contact > about problems with the network. If the provider can't contact the customer > and get the issue resolved, they should turn off their access until it is. An excellent point. As a few people have already stated, users of (e.g.) DSL/Cable Modem connections must abide by their provider's AUP. It is pointless to contact the residential customer directly, and would, in any event, have a lot less impact than contacting the organization with the facility to cut-off their 'net access. I would be happy to give a couple of genuine examples where this has done more good than simply e-mailing a private individual. On the privacy side, those people that (e.g.) post photographs of cars would appreciate not advertising their full home address to people that could then fake registration documents (just as one specific instance of fraud). There are also other legal implications, assuming that anyone else on the list have dealt with (e.g.) German companies or individuals that might get themselves registered on ARIN-allocated blocks. I'm [personally] happy to remain contactable (nothing to hide re: spam etc.), but it can be quite easy in these discussions to get too heavily focussed on a couple of specific technical points. It might be a nice idea to add a genuine AUP contact (i.e. that of your ISP, updated whenever one changes provider), but I can't see that happening in The Real World - spammers will simply omit the information or lie, while others would very often forget to update the information; it is also likely that a takeover of one ISP by another would also omit this update step.. All lead to a dilution of the data quality, probably to the extent where it's pointless to even attempt to store the information. If one is designing something to automatically assign AUP information, then simply place it into a database and, on a new occurrence, perform a simple text search on the "fresh" WHOIS data. AFAIK ARIN is a registrar, not an anti-spam organization! Regards, Ian From stephen at sprunk.org Fri Jul 25 14:32:38 2003 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 25 Jul 2003 13:32:38 -0500 Subject: [ppml] Policy Proposal 2003-3: Residential Customer Privacy References: Message-ID: <000201c354b6$168d5cd0$afb58742@ssprunk> Thus spake > >ISPs with downstream residential customers may substitute > >that ISP's name for the customer's name, e.g. 'Private > >customer - XYZ Network', and the customer's street address > >may read 'Private Residence.' Each private downstream residential > >reassignment must have accurate upstream Abuse and Technical POCs > >visible on the WHOIS record for that block. Aside: Is there any objection to still requiring the city, postal code, and country for "private residence" allocations? That data is useful for many things even without the street address. > It's nice and short, it gets to the point and it is understandable. > All good things. But it still is a waste of our time to deal with > things like this. This proposal is picking nits, trying to solve a > specific special case before we've dealt with the general problem. > I suggest that we reject this proposal. Privacy isn't a nit. A serious debate about defining and restructuring the overall whois service will take many months, if not years, and IMHO it's productive for ARIN to make an affirmative policy regarding personal privacy in the meantime. > There should be no mandatory email addresses tagged with labels like > "abuse" which will likely lead to the email being /dev/nulled because that > does not establish two-way communication with a human being. > > And this whois data should only be published when and if there are human > beings at the other end who are ready, willing and able to do something > about the communications that they may receive. It is no more acceptable for objects to lack contact information than it is for said information to be incorrect or useless. This tangent is moot anyways because it's already common practice for ISPs to list their own contacts for residential customers; the only question at hand is whether the customer's name and address must be publicly attached to the assignment itself. > Yes, it would be good to regularly poll these contacts and to flag the > ones that appear to be getting stale and remove the ones that no longer > connect. Per Andrew Dul, the AC is already working on a data-validation proposal. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From Michael.Dillon at radianz.com Mon Jul 28 05:48:28 2003 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Mon, 28 Jul 2003 10:48:28 +0100 Subject: [ppml] Policy Proposal 2003-3: Residential Customer Privacy Message-ID: >Psudeo-anonymity/privacy lies in the land of dynamic and NAT'd >addressing. If there's a *need* for consumption of finite resources, >there's a *need* for accountability. If someone needs 'permanent'/ >sizable allocations, why do they need to hide? Is there a theory >that the lack of 'privacy' (psuedo-anonymity) is preventing adoption >of IP technology? The focus on privacy and anonymity is why we should reject this policy proposal. It is looking at the problem from the wrong direction. Instead of assuming that the whois directory should include everyone's contact info unless they desire or need privacy, we should be asking ourselves what information needs to go into the whois directory. What is the purpose of the whois directory? Is it to allow anyone and everyone to compile lists of contact information for any purpose whatsoever? I say no it is not and that is why we need to scrap the existing whois directory. Who should be in a whois directory? I say that only people and organizations who wish to be contacted should be in the directory. What is the purpose of a listing in the whois directory? To enable anyone to contact a person who is ready, willing and able to communicate about specific network abuse issues and who has the ability to take action. Sometimes the action will take the form of relaying a message to a downstream provider who is not able to operate their own 24 x 7 abuse desk and that is perfectly valid. If you agree, then I'd like suggestions on some wording for a policy proposal to be submitted before the 1st week of September. --Michael Dillon From cscott at gaslightmedia.com Mon Jul 28 11:44:36 2003 From: cscott at gaslightmedia.com (Charles Scott) Date: Mon, 28 Jul 2003 11:44:36 -0400 (EDT) Subject: [ppml] Policy Proposal 2003-3: Residential Customer Privacy In-Reply-To: Message-ID: Michael: As a practical matter, I think it's important to be able to get in touch with at least someone who will take responsibility for any particular address, whether that's the end-user, their local ISP, or the ISP's backbone provider. Personally, I'd prefer that the higher-level provider be the one listed as they are the one who's ultimately responsible for their downstream customer. If more detailed customer data in the whois database gives the higher-level provider some excuse to pass the responsibility on to someone who's less able or likely to be helpful, then the data is counter-productive. Also, more whois data attracts more abuse. As such, perhaps the whois database should only offer information on the organization who directly received the allocation from ARIN, and who would be the one who's ultimately responsible for the use of that address space. This would significanly reduce whois workload, would virtually eliminate abuse of the database, and would still provide information for a responsible contact. It would also make it much easier to establish and implement standards regarding the listed contacts. Chuck Scott On Mon, 28 Jul 2003 Michael.Dillon at radianz.com wrote: > The focus on privacy and anonymity is why we should reject this > policy proposal. It is looking at the problem from the wrong > direction. Instead of assuming that the whois directory should > include everyone's contact info unless they desire or need > privacy, we should be asking ourselves what information needs to > go into the whois directory. > If you agree, then I'd like suggestions on some wording for a policy > proposal to be submitted before the 1st week of September. > > --Michael Dillon > From einarb at arin.net Tue Jul 29 14:14:55 2003 From: einarb at arin.net (Einar Bohlin) Date: Tue, 29 Jul 2003 14:14:55 -0400 Subject: [ppml] Policy Proposal 2003-3: Residential Customer Privacy In-Reply-To: <000201c354b6$168d5cd0$afb58742@ssprunk> Message-ID: <004a01c355fd$50365250$3d8888c0@arin.net> Hi Stephen, RE: 2003-3 Residential Customer Privacy > Aside: Is there any objection to still requiring the city, postal code, > and > country for "private residence" allocations? That data is useful for many > things even without the street address. I believe the intent of the authors is that "private residence" will fill in the line, 'Customer Address:', that is, the piece of data that identifies the number and street. City, state, zip, and country will still be required. If this is not the case I'm certain the authors will correct me. Regards, Einar Bohlin - Policy Analyst, ARIN einarb at arin.net 703 227-9867 > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On Behalf Of > Stephen Sprunk > Sent: Friday, July 25, 2003 2:33 PM > To: Michael.Dillon at radianz.com > Cc: ARIN Policy > Subject: Re: [ppml] Policy Proposal 2003-3: Residential Customer Privacy > > Thus spake > > >ISPs with downstream residential customers may substitute > > >that ISP's name for the customer's name, e.g. 'Private > > >customer - XYZ Network', and the customer's street address > > >may read 'Private Residence.' Each private downstream residential > > >reassignment must have accurate upstream Abuse and Technical POCs > > >visible on the WHOIS record for that block. > > Aside: Is there any objection to still requiring the city, postal code, > and > country for "private residence" allocations? That data is useful for many > things even without the street address. > > > It's nice and short, it gets to the point and it is understandable. > > All good things. But it still is a waste of our time to deal with > > things like this. This proposal is picking nits, trying to solve a > > specific special case before we've dealt with the general problem. > > I suggest that we reject this proposal. > > Privacy isn't a nit. > > A serious debate about defining and restructuring the overall whois > service > will take many months, if not years, and IMHO it's productive for ARIN to > make an affirmative policy regarding personal privacy in the meantime. > > > There should be no mandatory email addresses tagged with labels like > > "abuse" which will likely lead to the email being /dev/nulled because > that > > does not establish two-way communication with a human being. > > > > And this whois data should only be published when and if there are human > > beings at the other end who are ready, willing and able to do something > > about the communications that they may receive. > > It is no more acceptable for objects to lack contact information than it > is > for said information to be incorrect or useless. > > This tangent is moot anyways because it's already common practice for ISPs > to list their own contacts for residential customers; the only question at > hand is whether the customer's name and address must be publicly attached > to > the assignment itself. > > > Yes, it would be good to regularly poll these contacts and to flag the > > ones that appear to be getting stale and remove the ones that no longer > > connect. > > Per Andrew Dul, the AC is already working on a data-validation proposal. > > S > > Stephen Sprunk "God does not play dice." --Albert Einstein > CCIE #3723 "God is an inveterate gambler, and He throws the > K5SSS dice at every possible opportunity." --Stephen Hawking