[arin-ppml] Re-allocations (was: Revised/Retitled: Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements)

Thu Aug 31 10:58:51 EDT 2017

David,

My thoughts, please take with a grain of salt.

1. Problem statement is fine, but really is just one of many examples
    of why this data is needed

2. I'd be careful with the use of the word ISP,
     -  I recommend it is better just to drop it
     -  I'd drop the timing part, and leverage pre-existing text instead
        (as this is simple, convenient, and keeping them in sync makes
sense)

-------------

1. Problem statement is fine, but really is just one of many examples
    of why this data is needed

I'm not sure this NEEDS to be separated from the other proposal,
but it certainly could be separated. (What I would optimize for
is getting both changes through as quickly as possible.)

I think your problem statement is good, but is only a sub-set,
there are many things that require good contact info.

Certainly LEA is a big one, even more critical than a subpoena
is suicide threats, death threats, and abductions with timely
access is even more critical.

The info is also used for technical reasons to determine who is
the party best suited to resolve some technical issue.  E.g. the
IPs are being blackholed by a third party, a machine in the
address range is infected with malware, a machine in the address
range is misconfigured in a way that leaves it vulnerable to reflection
attacks, abuse or hacking attempts for an address in the range, etc.

----------

2. I'd be careful with the use of the word ISP

I would caution the use of the word ISP.  I think it reads just fine
without it.

By definition any time there is a re-allocation, the address space is going
to be used by an organization that intends to re-use some of their address
space to their own down stream customers.  In ARIN terms this makes
them and ISP and not an end-user, but I fear people will get wrapped up in
the term "ISP" and claim they are not one and need not SWIP.

If you think there is enough organizational separation to treat your
downstream (B) like a customer...

And they (B) think there is enough organizational separation to treat
their (B's) downstream (C) like a customer, and therefor request a
re-allocation (and not a reassignment)...

Then B needs to be registered in whois because they have a
re-allocation, and intend to make downstream subdeligations.

Now Imagine this is ISP "A" with a customer of University of "B"
who has a customer of The "C" department, who has a customer
of computer Lab "D".   A. B, and C need to be registered because
they are all registering sub-delegations.  This is regardless of if
The "C" department considered themselves an "ISP".

 X. Re-allocations
Each IPv4 re-allocation, regardless of size, must be registered.

Y. Re-allocations to other ISPs

Each IPv6 re-allocation, regardless of size, must be registered.

Also, if you organize this under the same section as (re-)assignments,
you share the same 7 day requirement, which makes sense.

Also, also it is now a lot less words.

___Jason

On Wed, Aug 30, 2017 at 3:22 PM, David Farmer <farmer at umn.edu> wrote:

>
> On Wed, Aug 30, 2017 at 12:27 PM, Jason Schiller <jschiller at google.com>
> wrote:
> ...
>
>> I recall there being a third class, any re-allocation.
>>
>> A re-allocation is when I ISP provides addresses to their down stream
>> ISP customer who then in turn will further sub-delegate address space
>> to their customer (who may also be an ISP with customers... and so on).
>>
>>
> Jason,
>
> I've been working on a separate proposal regarding re-allocations. It
> really needs a bit of a different problem statement, and there is text
> needed for both IPv4 and IPv6.  Here, is what I have so far;
>
> Any comments would be appreciated;
>
> Thanks.
>
> --------
> Policy Proposal Name:
>
> Require Registration for Re-allocations to Downstream ISPs
>
> Problem Statement:
>
> It is critical that the best source for information about the end user
> associated with any IP address is publicly known.  That is not to say that
> the information about the end user associated with each IP address needs to
> be publicly known, but that the entity that has a direct customer
> relationship with, or otherwise knows, the end user for any IP address
> needs to be publicly known.
>
> Frequently civil and criminal litigation today involves electronic
> evidence of some kind, this evidence is regularly associated with an IP
> addresses. In such cases, the customer records associated with an IP
> address may need to be subpoenaed as part of civil or criminal legal
> proceedings, therefore the proper entity to issue a subpoena to needs to be
> readily known.  When ARIN allocates address space to an ISP this
> information is provided in it's registration database, and is publicly
> accessible via Whois. When addresses are re-allocated from an ISP to
> another downstream ISP, and if this re-allocation is not properly and
> publicly documented the wrong ISP could be subpoenaed for the customer
> records associated with an IP address. This wastes the time of judges and
> other court officials, but even worse it could cause a delays in
> time-sensitive situations, for instance the kidnapping of a child.
>
> For these reasons, the re-allocation of address space to a downstream ISP
> must be registered in ARIN's WHOIS directory via SWIP before the downstream
> ISP uses the re-allocated addresses to provide any services to it's
> customers.
>
> Policy statement:
>
> Add new subsections X for IPv4 and Y for IPv6 as follows, 4.2.3.7.4 and
> 6.5.5.5 are recommended respectively;
>
> X. Re-allocations to other ISPs
>
> Each IPv4 re-allocation to a downstream ISP, regardless of size, must be
> registered to the downstream ISP in the WHOIS directory via SWIP before the
> re-allocation is used to provide any services to the downstream ISP's
> customers.
>
> Y. Re-allocations to other ISPs
>
> Each IPv6 re-allocation to a downstream ISP, regardless of size, must be
> registered to the downstream ISP in the WHOIS directory via SWIP before the
> re-allocation is used to provide any services to the downstream ISP's
> customers.
>
> Comments:
> a. Timetable for implementation: Immediate
> b. Anything else
>
> The use of RWHOIS, or other distributed Distributed Information Server as
> described in NRPM section 3.2, for this registration information is not
> sufficient, the ARIN WHOIS directory needs direct knowledge of each
> re-allocation to ensure the correct information is provided without needing
> to access other services.
>
> Processes and procedures should be developed for the reporting of
> incorrect or unregistered re-allocations that result in official legal
> process going to the wrong entity. ARIN Staff should investigate such
> reports and work with upstream ISPs to ensure the reported registrations
> are correct. The imposition of penalties, financial or otherwise, for
> incorrect or unregistered re-allocations are not directly a policy
> question, but are more a question of business practice, and should be
> considered separately by the ARIN Board of Trustees assuming this policy
> proposal is adopted.
>
> Previously in IPv4, slow-start essentially required new ISPs to use a
> re-allocation from an upstream ISP to develop an allocation history before
> they could receive a direct allocation from ARIN, even though the term
> re-allocation wasn't specified in the NRPM.  In IPv6 this should not be
> necessary, most new ISPs should be able to qualify for an initial
> allocation directly from ARIN. However, there are other reasons for
> re-allocations in both IPv4 and IPv6 generally, either on a permanent basis
> or temporarily during a transition, such as the change in ownership of a
> customer territory or the sale of only part of a network, etc...
>
> --
> ===============================================
> David Farmer               Email:farmer at umn.edu
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE
> <https://maps.google.com/?q=2218+University+Ave+SE&entry=gmail&source=g>
>       Phone: 612-626-0815 <(612)%20626-0815>
> Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>
> ===============================================
>

-- 
_______________________________________________________
Jason Schiller|NetOps|jschiller at google.com|571-266-0006
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20170831/6ac21005/attachment.htm>