[ppml] Abstract of proposed Internet Draft for Best Current Practice (please comment)
owen at delong.com
Wed Feb 19 14:01:46 EST 2003
The problem is that, even according to ARIN, there are a number of issues
with identifying this. Several prefixes appear to be legitimately in the
routing table, but ARIN has lost the records of their allocation. Heck,
some of them seem to belong to Bill Manning. Somehow, I don't think Bill
has been pirating address space.
Any enforcement action taken based on the contents of the ARIN database
before these issues are resolved would be folly. Especially automated
Additionally, the internet depends on rough consensus. It always has,
and, I believe it will stop functioning if it doesn't continue to. This
means that the people running the routers need to develop consensus on
what to route. The RIRs can provide tools towards that end, but I don't
believe it is their role to control the configuration or operation of
the routers. I'm all for the RIRs providing a centralized "Valid Prefixes"
list. Heck, I'd even support a database of "Valid Prefixes and the
origin AS that maintains them." However, the use of such databases
is a matter for RFC, BCP, and/or IETF. It is _NOT_ an ARIN policy
As such, I think your 2002-7 proposal needs to be separated into two
parts. The RFC/BCP/IETF track part (things that should be done by
the people that operate the routers), and the ARIN policy part.
Also, unlike the DNS situation, ARIN has a tentative hold on address
issuance based entirely on the support of the community. If enough
people oppose ARIN policy, they can just as easily create their own
address registry. ISPs would be free to choose which registry they
wanted to believe about addresses. The conflict could be very ugly.
Heck, this has already happened with DNS, but none of the oppositions
were able to come together to a large enough cohesive group to tackle
the basic suffixes, so in self-preservation, they avoided existing
namespaces in favor of new ones. This isn't as easily done when the
namespace is limited to 32 bit integers, most of which are already
issued at one level or another.
So.... Enforcement will depend on the BCP being something the default
free zone is largely willing to follow. The BCP will have to drive
this, and not ARIN policy.
ARIN policy should be an enabler for the BCP, and should, IMHO, accomplish
1. Each maintainer must provide at least one contact point which
reaches an actual human being. Not an autoresponder, not a voice
mail box, a live human being. (Not necessarily 24x7x365, but
at least during business hours).
It may be desirable for access to this contact information to be
visible only to other maintainers, ARIN, and paid ARIN members.
This would hopefully reduce the number of irrate and irrational
2. Each RIR should publish a list of valid prefixes and the ASN to which
they were Allocated or Assigned. Ideally, this list should be available
in a machine-readable format and published by means of a well known
3. ARIN should have the ability to revoke an allocation or assignment
as a result of verified abuse. It should become part of the ARIN
contract for registration services that the ASSIGNEE/ALLOCEE is
responsible for the prevention of abuse within the resources
allocated/assigned, and that they must revoke sub-assignments
they have made in cases of verified abuse or risk their allocation
being revoked by ARIN.
4. ARIN should have the responsibility to revoke any allocation or
assignment which fails to meet the requirements of (1) above.
5. ARIN should set up a revocation review committee made up of
representatives from ARIN members with allocations and nominated
by the ASO AC. The members should be elected for a 2 year
term by the community at large (similar to the ASO AC election
at the ARIN/NANOG meeting). The committee should consist
of 7 members.
6. The revocation process should look something like the following:
A. ARIN staff receives report of or identifies abuse.
B. ARIN staff investigates and confirms abuse. If abuse is
not confirmed, the process ends here.
C. If abuse is confirmed, ARIN staff sends a cease-and-desist
letter to the required human contact of the maintainer
in question via a confirmed-delivery mechanism.
D. If, 15 days after the message is received by the maintainer,
the abuse has not been resolved, ARIN should immediately
revoke the applicable allocations and/or assignments,
and refer the matter to the committee.
E. If the maintainer wishes to appeal the decision, he should
notify the committee of his desire to appeal within 30
days. The maintainer should submit his appeal in written
form (preferably via electronic means). The committee has
60 days to review the information before it must render a
decision. The committee's decision is final.
F. Absent an appeal by the maintainer, no action is required from
the committee, however, any member of the committee may
also start the appeal process absent request from the
G. Any revocations should be published by ARIN on a specified
place on the ARIN web site, as well as their removal from
the valid prefixes list as soon as they take effect.
H. Revocations should be effective when the first of the following
1. The time for appeal has lapsed, and no appeal has been
2. The comittee has ruled in support of the revocation.
3. The time for the committee to rule has elapsed and
no ruling has been made.
Further, I think it would be desirable for ARIN to issue a single ASN
to ARIN as BOGON-ASN. ARIN should publish a BGP feed (peered to any
ARIN member with an ASN with no more than two peering sessions)
which will contain all currently known BOGON prefixes. This would
include IANA-RESERVED, RFC-1918, and any revoked prefixes.
Revoked prefixes should not be reallocated for a period of one (1)
year from the date of final revocation.
Whatcha all think?
--On Wednesday, February 19, 2003 4:06 PM +0700 "Dr. Jeffrey Race"
<jrace at attglobal.net> wrote:
> On Tue, 18 Feb 2003 16:58:13 -0800, Owen DeLong wrote:
>> Here's the real problem, as I see it. When a domain is revoked, name
>> for that domain stops working at the root or TLD level. When ARIN
>> an IP, nothing happens until an ISP stops routing it.
> I am interested in learning more about the technical measures which
> the RIRs can employ to prevent fraudulent use of IP address space
> (which is now occasionally reported on Spam-L already). But at
> the level of the draft BCP, I am considering to add a new type
> of abuse:
> - announcing a non-delegated route or other fraudulent use of
> IP address space.
> Comments invited on
> * wording (correctness, inclusiveness)
> * practical effectiveness.
> Those following the draft BCP would blocklist the offending ISP.
> These things would get around pretty quickly.
> Jeffrey Race
More information about the ARIN-PPML