[ppml] Policy Proposal 2007-6 - Staff Assessment

Thu Apr 19 17:11:16 EDT 2007

Dave thanks for keeping discussion going.

I oppose this policy for the following reasons.  

1. From experience with spammers, I feel this could actually make things easier on them as pointed out in an earlier string or just simply give them another avenue.

2. I tend to believe that a rush of some size will be brought on if this were to pass and that could lead to other negative effects such as depletion and maybe more aggregation than what was already needed, just because they can. 

3.One of the rationale from this proposal is "In addition, by keeping the PI allocation size for multi-homed
organizations at /22, organizations seeking PI space that don't meet the requirements may be encouraged to exaggerate their address usage. This is something that should clearly not be encouraged."  I disagree with this rationale and here is why:

I don't see proof of the exaggeration scam working or that it is done alot.  For example, just this week I had a customer who tried to do this with ARIN and they were told no and to get IP addresses from me.  When I reviewed what they had, they could only justify the use of a /23 and the rest of it was obvious "exaggeration".  So I don't see the exaggeration thing working out so much.  They may try it, but that doesn't mean they get away with it.  And another point, if they were exaggerating /22's or let say /21's then what is to stop others from exaggerating /24's?  And honestly, it would be allot easier to exaggerate your way through a /24 justification than it would be a /22.  Also, I like to think that the number of people willing to "exaggerate" is smaller than those who are honest (yes I know, fire away, rose colored glasses).  

So in a quick summary, I don't think the reasons for this proposal outweigh potential spam issues or a run on IPv4 space and its related issues and just may lead to an increase of those willing to exaggerate justification because it is suddenly easier. 

Cheers!
Marla Azinger
Frontier Communications 

-----Original Message-----
From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
David Williamson
Sent: Thursday, April 19, 2007 12:49 PM
To: Stacy Taylor
Cc: ppml at arin.net
Subject: Re: [ppml] Policy Proposal 2007-6 - Staff Assessment

I wanted to allow some time to see if this started any further
discussion.  Regrettably, it did not.

I think your first point is inaccurate.  Similar policies already exist
in several of the other RIRs, and that hasn't led a run on space.
Additionally, organizations that need IP space will get it one way or
another.  This policy simply provides another method for them.  Indeed,
ARIN's requirements are more strenuous than most provider's, so some
organizations that need a multi-homed /24 may still go for PA space.

Here's the key point: this only changes the minimum allocation size -
all of the other requirements (multi-homing, utilization, et.c) still
stand.

On your second point...I'm not in the anti-spam community, so I don't
have any real data on how much of a threat this is.  Perhaps someone
from another RIR could chime in on this, since APNIC, for example,
already hands out PI /24s.  Has there been any sort of known abuse
involving spammers?  Like I said, I'm not in the anti-spam community
enough to know, but it seems unlikely that spammers would take the time
to meet the utilization and multi-homing requirements and then turn
around and make that space mostly unusuable.  (Lather, rinse, repeat.)
It just doesn't seem to me like a profitable business method.  As I
have mentioned before, additional information from someone with actual
data on this point would be great.  The general apparent lack of data
actually gives me some confidence that this isn't as big of a threat
as it may seem.

Thanks for the feedback and the opinion!

-David

On Mon, Apr 16, 2007 at 03:39:06PM -0700, Stacy Taylor wrote:
> Hello PPML,
> I oppose this policy.
> First, I believe there is no better way to chew through the remainder
> of the v4 space faster than to pass this policy.
> Second, I support staff comments about spammers using this policy for
> abuse of networks.  In my experience, miscreants of this sort prefer
> multiple /24s for their 'businesses' to force spam hunters to play
> whack a mole with the blacklisting of space.  A _former_ customer of
> mine had more than 30 different business names, all with different
> points of contact and physical addresses.  Because we were the
> upstream, we were notified of his violations of our AUP.  If the only
> contact were the miscreant himself, he would not have been held
> accountable.  Spammers would adore directly assigned space for this
> very reason.
> For the good of the Internet, this policy must not be passed.
> Stacy
> 
> On 4/13/07, David Williamson <dlw+arin at tellme.com> wrote:
> > I'll second the comment that it's great to get these assessments in
> > advance of the meeting.  Thanks!
> >
> > I wanted to take a moment to respond to the staff comments on this
> > one.  Comments inline.
> >
> > On Fri, Apr 13, 2007 at 02:21:49PM -0400, Member Services wrote:
> > >      1.       There is very little qualification criteria which could lead to
> > > policy abuse by spammers.  These entities could create many different
> > > accounts over time as their existing space gets blacklisted or becomes
> > > otherwise unusable.
> >
> > Do spammers take the time to become multihomed and then apply for IP
> > space?  If they do, I'm sure they can find a way to qualify under the
> > existing policy for a /22.  I'm not sure I understand the actual risk
> > here.  It seems to me that this could already be a problem, actually.
> > Perhaps a process to identify or report spammers would help this
> > problem, but I'm not convinced that spammers actually try to get valid
> > IP space from RIRs.  Do we (staff and or community) have any data on
> > this possibility?
> >
> > >      2.       This could significantly increase the number of requests for
> > > ARIN services thereby requiring additional Registration Services
> > > Department and Financial Services Department staff.
> >
> > This is true.  It is likely that a small multi-homed enterprise would apply
> > for space under this policy rather than applying for space via an ISP.
> >
> > >      3.       Policy applies only to end users which could be perceived as
> > > unfair to ISPs.  This could also lead to potential abuse of the policy
> > > if ISPs apply as end users for single /24 IPv4 address block.
> >
> > I respectfully disagree with the first sentence entirely.  Existing
> > policy is heavily biased towards ISPs, and is rather unfair for smaller
> > entities that have a critical business need to be multi-homed, but wish
> > to avoid being semi-permanently attached to a single ISP due to the
> > need for address space.  Indeed, the current lack of fairness is part of
> > the desire to change the policy.
> >
> > On the second point - I agree that this could be an issue.  I suspect
> > it could be an issue now...there's nothing to stop an ISP from applying
> > for a /22 as an end user, outside of the risk of getting caught by staff.
> >
> > >      4.       It is unclear exactly how an organization can qualify for a /24
> > > IPv4 address block under this policy.  It appears that NRPM section
> > > 4.3.3, Utilization rate, requires 25% immediate, 50% within 1 year,
> > > would be the justification criteria.  However, NRPM section 4.2.3.6,
> > > Reassignments to multihomed downstream customers, indicates that an ISP
> > > can reassign a /24 IPv4 address block without regard to planned host
> > > counts as long as the customer is multi-homed.  The question here is
> > > does this policy allow ARIN to qualify a requestor for a /24 IPv4
> > > address block based solely on multi-homing or should host counts also be
> > > taken into account?
> >
> > Existing policy, as written, refers to section 4.3.3.  That doesn't
> > change with the proposed policy.  ISPs can feel free to reassign a PA
> > /24 via whatever policy they choose, but direct (PI) assignments should
> > still be under the guidelines listed in 4.3.3, regardless of the
> > minimum assignment size.  There is explicitly no change in that.
> >
> > >      5.       The policy does not address requests for more than one /24 IPv4
> > > address block for multiple sites.
> >
> > My intention for this issue is that this is handled in the same way
> > that multiple /22 requests are handled now.  Is the request justified?
> > There's no change in how this would be handled, outside of the
> > differences in minimum assignement size.
> >
> > >      6.       NRPM Section 4.4, Micro-allocation, should remain as is since it
> > > is a policy section essential for micro-allocation for critical
> > > infrastructure related requests.
> >
> > I'm happy to concede this point, and change the policy appropriately.
> > I'd like more (as in any) community input on this point.  To some
> > extent, the IPv4 micro-allocation section is irrelevant if this policy
> > is approved.  On the other hand, it may be useful to explicitly call
> > out the allocation policy for critical infrastructure.  What that
> > infrastructure is defined to be is an interesting question, but beyond
> > the scope of the current proposal.  More opinions solicted!
> >
> >
> > Thanks again for the opportunity to get some of this discussed in
> > advance of the meeting!
> >
> > -David
> >
> > _______________________________________________
> > This message sent to you through the ARIN Public Policy Mailing List
> > (PPML at arin.net).
> > Manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/ppml
> >
> 
> 
> -- 
> :):)
> /S
> _______________________________________________
> This message sent to you through the ARIN Public Policy Mailing List
> (PPML at arin.net).
> Manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml
_______________________________________________
This message sent to you through the ARIN Public Policy Mailing List
(PPML at arin.net).
Manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/ppml