[ppml] Last Call for Comment: Policy Proposal 2002-6

Bill Darte billd at cait.wustl.edu
Fri Nov 15 09:23:03 EST 2002

I think Mury's suggestions are near the mark on this issue.
RIRs maintain a list of returned space
RIRs defer allocating from list until needed) then allocate from list First
In/First Out
RIRs employ tests (if possible?) to determine suitability - worst stuff goes
to top of list
RIRs would make an effort to publicize service to Blacklisters

Other thoughts? 

Obviously there is a 'cost' to this service. Is the reclamation for
aggregation worth the cost?

Bill Darte

> -----Original Message-----
> From: Mury [mailto:mury at goldengate.net]
> Sent: Thursday, November 14, 2002 9:30 PM
> To: Dr. Jeffrey Race
> Cc: Jill Kulpinski; ppml at arin.net
> Subject: RE: [ppml] Last Call for Comment: Policy Proposal 2002-6
> I'm not sure I should comment because I did not read all of the posts
> regarding this.  However, I'll take a chance at being flamed 
> for repeating
> someone else or being off-topic.
> Didn't this start with someone not wanting used space, 
> because used space
> can have legacy consequences?  Those consequences being 
> black-listed IPs,
> existing servers outside the IP block still thinking they 
> need to talk to
> those IPs for a service long gone, etc.
> It seems to me like it is very similiar to getting a recycled 1-800
> number.  It sucks.
> I really don't see how the RIRs can effectively revoke the IP space of
> spammers.  That is going to take a lot of effort and probably 
> result in a
> lot of days sitting in court.  That's not to say that I 
> wouldn't like to
> see it happen, but I don't think that is a viable answer.
> Why can't the RIR maintain a list of returned IP space?  Blacklisting
> services that are worth using could easily cross check their 
> blacklisted
> IPs against that list.
> The RIRs should also recycle the IPs on a first in first out basis to
> minimize any legacy traffic going to those IPs.  It's not perfect, but
> statistically it makes sense.  Of course they could also advertise all
> unallocated IPs to themselves or an outside service to check 
> for abnormal
> amounts of legacy traffic and not assign blocks that are 
> being hit hard.
> It's hard for me to imagine that if IP space is returned and it is not
> recycled for a year or two that a blacklisting service 
> couldn't find the
> resources to remove that IP space from their lists and for a very high
> percentage of the legacy traffic to have vanished.
> Anyone using a blacklisting service that can't keep something 
> like that up
> to date can't possibly trust their accuracy anyway.  And in 
> my experience
> most blacklisters are savvy enough to appreciate and utilize 
> a list that
> the RIR's could easily maintain.
> Mury
> On Fri, 15 Nov 2002, Dr. Jeffrey Race wrote:
> > On Thu, 14 Nov 2002 12:28:53 -0800, Jill Kulpinski wrote:
> > >This whole issue regarding blacklists seems to be growing 
> each day and more
> > >rapidly in the past few months.  I would love to know what 
> to tell Customers who
> > >are assigned space that was once used by some other 
> Customer who got it
> > >blacklisted on one of the thousands of lists out there.  I 
> can not control who
> > >creates a blacklist, nor who uses it to set up filters, so 
> is there really any
> > >means of providing a Customer address space that will 
> never be blacklisted?  No.
> > >But they want temporary fixes in the meantime which is an 
> impractical solution.
> > >I would love to hear other people's thoughts on this but I 
> realize I may be
> > >getting off of the topic a bit.
> >
> >
> > It is completely on topic for the reasons you state.
> >
> > In general,  announcement on Spam-L and NANAE that the 
> ownership of IP address
> > space has been taken over by new non-spammer user will 
> cause many or most of
> > the blocklists to remove the previously offending 
> addresses.   However some
> > blocklist managers don't follow these groups assiduously, 
> some blocklist
> > managers have a several-month waiting period, and some 
> blocklist managers have
> > a policy NEVER to admit traffic from any once-polluted 
> address space, possibly
> > because they have been lied to so many times.
> >
> > So there is NO universal retrospective solution.
> >
> > Therefore, and this is the simple point I have been trying 
> to make here,
> > there remains only a prospective solution.    That is what 
> you have to face,
> > and face now, because the use of blocklists is growing 
> rapidly and possibly
> > exponentially.  It is the only defense we victims have 
> against the present
> > irresponsible management of IP address space and domain names.
> >
> > The RIRs are responsible for the proper management, express and
> > implied, of the IP address space allocated to them.  Since 
> recycling of
> > IP address space obviously will occur over the years, decades and
> > centuries, the RIRs have a duty to prevent pollution of the 
> resources
> > they manage.  The pollution comes from spamming.   This 
> means the RIRs
> > have to have a clear policy that IP address users must not 
> spam, must
> > not allow spammers on their networks, and must have 
> hair-trigger management
> > systems in place to identify incipient spammers and 
> penalize them (because
> > blocklist additions can occur in days).  (All this is 
> eminently doable now
> > by presently existing technical measures, and many ISPs do 
> indeed use such
> > measures.)  Any user who violates this rule must have his 
> IP address space
> > withdrawn. That is the only sanction that anyone will pay 
> attention to.
> >
> > In short, the RIRs have to take on a role to act, probably 
> agggressively
> > and violently, against abuse of the resources they manage, 
> by the people
> > to whom they entrust these resources.   If you list members 
> are not willing
> > to rise up and force them to prevent spammers from pissing 
> in the pool,
> > then don't complain about how the water tastes when you 
> swim in it.  It
> > is the result of your own (in)action.
> >
> > Jeffrey Race
> >

More information about the ARIN-PPML mailing list