[arin-ppml] Policy requests

Sat Oct 16 00:41:26 EDT 2010

Comments (lots!) in line..

On Fri, Oct 15, 2010 at 8:10 PM, Alex Lanstein <ALanstein at fireeye.com> wrote:
> First off, apologies if any of these have been brought up before, but I've spoken with a number of ARIN members and have each time been encouraged to post some thoughts to PPML.  I understand all new policies must come from the community, but I don't doubt I'll be showing my naiveté with how things work at ARIN.
>
> 1) ICANN has a policy for certain TLDs that WHOIS details must be accurate.  There are many issues with this, such as enforceability and the use of privacy proxies, but enforcement is impossible without a clear policy to begin with.  Is there a reason ARIN does not have a policy against fraudulent SWIPing and fake PTR records?  I was told to look at Paragraph 8 of the RSA, but it really doesn't address my concern --- https://www.arin.net/resources/agreements/rsa.pdf.
>
> I think it makes sense that ARIN have the same policies on accuracy of SWIPing, and that there should be some language that prevents someone from creating fraudulent reverse records.
>

Try section 5 of the RSA for the reassigning bit: "(b) Responsibility
for Directory Services Data. Applicant is responsible for the timely
and accurate maintenance of directory services data (WHOIS), as well
as data concerning any organization to which it further sub-delegates
number resources."

and section 3 of the RSA for the rest: "If, at any point, including
during the application process and/or the pendency of this Agreement,
Applicant actively misrepresents, falsifies, or otherwise fraudulently
provides information, ARIN may immediately terminate this Agreement."

There is an ARIN policy that requires staff do POC validation - the
data about which resources have invalid POC data is available through
the bulk whois process.  In theory one could obtain the list of
prefixes with invalid POC data and use it in a variety of ways,
examples: not announce the prefix, not accept the prefix, filter
traffic from the prefix, not accept mail from the prefix, call your
customer and ask them to update the data, update your own invalid POC
records, etc.

Poc Validation policy: https://www.arin.net/policy/nrpm.html#three6
Bulk Whois process: https://www.arin.net/resources/request/bulkwhois.html

Take a look at this proposed text:
https://www.arin.net/policy/proposals/2010_14.html
This text will probably be broken up and reworked, for the spring
meeting.  You may want to provide some feedback to Chris G or one of
the AC shepherds - Providing specific examples of changes you propose
- even providing text - would go a long way.   For example, you
mention preventing someone from creating fraudulent SWIP records -
would you propose that staff take some step to verify the contact
information is valid when a reassign/reallocate template is submitted?

ARIN has a fraud reporting process:  https://www.arin.net/resources/fraud/
Which you can use if you believe that someone has, amongst other
things, submitted false utilization or organization information.

Unfortunately, ARIN has a little bit less control over the data that
is submitted to them via SWIP for reassignment records.  They don't
have a direct relationship with the organization that an ISP delegates
a resource to, making it harder for ARIN to know/verify that the
reassignment information is correct.

For what it's worth - I think that the majority of the data that goes
into SWIP reassignment records, is accurate to the best of the
submitter's knowledge at the time - but a lot of it has gotten stale
over the years.  The POC validation process aims to help that.  I
think that the intentionally submitted fraudulent SWIP reassignment
records are a fraction of the SWIP reassignments - but the problem is
exacerbated by the bad actors using the space.

> 2) I believe I should be able to review the network diagrams for requests of IP allocations that are not flagged as confidential.  I understand there needs to be a mechanism to protect trade secrets, but at the same time, it would make sense to be as open as possible.  I wouldn't expect to see the blueprints for a new CIA building, but I would for a new road in my town.
>

I strongly disagree.  Many companies only provide copies of their
network diagrams under NDA - be it to ARIN, their ISP or any other
vendor.  For many companies, their network architecture *is* their
product, it is their 'trade secret'

I even disagree with publicly disclosing the non- network diagram
details of a request - such as subnetting plans and existing and
projected utilization.  In a request for space you may need to detail
your deployment and business plans for the next 6 months or in the
case of IPv6, for the next 1, 2 and 5 years.  Publicly disclosing this
information can give your competitors a road map of your business plan
for the next 5 years.

How would you propose to draw the line (in policy text) between CIA
building and new road in your town?

I'm not sure I understand what it will buy you anyway - If the bad
guys are lying to get space, they are probably lying about their
network architecture.   Are you wanting this as a check on ARIN?  or
to be able to uncover some helpful clue about the bad guys?

>
> 3) I think there should be a mechanism to allow researchers to advertise IP space that has been abandoned by criminals.  There are lots of corner cases of course, but this sort of thing is already happening, with 1/8 being advertised recently as a research project.  Perhaps the easiest way to accommodate this would be to wait until the IP allocation expires due to non-payment, then assign that to a researcher.  For instance, it would be very nice to be able to advertise ex-mccolo space, sinkhole the data to Shadowserver, then provide telemetry back into the ISP community about infections.

1/8 is NOT a research project!  It was allocated to APNIC!  They have
allocated significant portions of it.  I believe they have not
allocated the portions that were deemed to generate too much
background noise.  They did do some test announcements when they first
received it, in order to determine how polluted it was.

I don't disagree with the idea.. I'm not sure it's an issue for the
NRPM (policy manual) but more an ARIN operational practice.  You might
try submitting it to the ARIN Consultation and Suggestion process:
https://www.arin.net/participate/acsp/index.html

>
> Thanks,
>
> Alex Lanstein
> (not speaking for my employer)
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>