[ppml] Abstract of proposed Internet Draft for Best Current Practice (please comment)

[Owen DeLong]

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
enforcement.

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
issue.

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
the following...

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
	attacks.

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
	protocol.

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
		maintainer.

	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
		occurs:

		1.	The time for appeal has lapsed, and no appeal has been
			filed.

		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?

Owen

--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
>> service
>> for that domain stops working at the root or TLD level.  When ARIN
> revokes
>> 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
>