- Test - lists.nanog.org

ARIN Advisory Council recommendations I have made
by Karl Denninger 29 May '98

29 May '98

As promised, here is my list of agenda items I believe are important for ARIN to "fix" within the immediate timeframe. All of these have been previously posted to the Advisory Council mailing list by myself. This is on the general topic of governance and transparency. My next message will be my repost on the topics of operational policy (ie: who can get PI address space, what justification is required, etc). I am expanding the discussion list to NANOG and the ARIN Members mailing lists. Please post comments PUBLICALLY, or if you feel you cannot do so without "cloaking" yourself, through someone else (who you trust to strip the attribution). High Level TOPIC #1 - Governance of ARIN ======================================== 1. Modification of the bylaws to provide for removal of trustees and officers by vote of the membership (currently lacking). I would like to recommend that the AC be required to carry a motion to be put to the membership for such an action, which then requires a vote by the membership within 30 days. Majority consent of the membership constitutes removal. (The "AC filter" is there to prevent someone from "buying" the membership - by getting 50 memberships, for example, and then using that to "take over" the board). 2. Modification of the bylaws to provide for the removal of AC members by direct membership vote. Procedure to be a majority consensus of the membership, initiated by the members directly. A simple majority of all members may remove an AC member by vote through this procedure. 3. The motion currently on the table from the last BoT meeting to give Kim Hubbard a vote as a Trustee should be, IMHO, defeated. This repairs the complete lack of accountability currently present in the bylaws. It is currently impossible for the members or the AC to remove a trustee or officer of the corporation; this is contrary to any other corporation I have ever worked for; the shareholders (who are, in this case, the membership - since the members fund the operation) always have the right to remove the board and, indirectly, the officers (by firing the board and replacing it). High Level Topic #2 - Accountability of Decisions made by ARIN ============================================================== 1. Modification of the bylaws to provide that the following acts are reportable to the public via web dissemination: a. All "executive decisions" made by ARIN's President and Board of Trustees outside of a regular meeting which affect one or more person(s) or organization(s). Exempt are statuatory privileged decisions (ie: employment related issues) ONLY. b. All "ex officio" actions taken by the Board of Trustees, including Board approval of any action taken or contemplated by a corporate officer. c. All ARIN Board and AC meeting minutes must be published within 7 days of the meeting or other administrative action which took place. d. (a) through (c) are retroactive to the formation of ARIN, and all documentation related to same are to be produced within 7 days following passage. 2. Modification of the bylaws to provide that the following items are considered to be publically reportable in the performance of ARIN's duties as a public trustee: a. All incoming address allocation requests. b. All document production requests made by ARIN persuant to (a), identifying the type of request, the time given for response, the scope and purpose of the request. c. The outcome of the allocation request, whether granted or turned down. d. An accounting of the amount of manpower used in processing the request (calculated in man/hours). (a) through (d) are to be reported within 7 days of closure of each request, and ARIN should produce a report weekly showing the number of requests currently in queue, new arrivals during that period, and dispositions. e. All actions taken by ARIN, its officers, staff members, or any individual under color of authority of ARIN in an attempt to reclaim, repossess, or interfere in any way with the peaceful enjoyment of address space held by entities which were granted prior to the adoption of RFC2008 (October 1996). These changes will fix the transparency problems which I believe exist today within the structure of ARIN. You have the other two (the address allocation policy changes and pricing changes) as well. Would you like me to write these up formally? -- -- Karl Denninger (karl(a)MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost

2 1

First proposal - all who need space get it (fwd)
by Karl Denninger 29 May '98

29 May '98

This was proposal number one for OPERATIONAL changes to ARIN's functional allocation policies. Note that this gets us to an objective, neutrally-verified criteria that allows, IMHO, all organizations with a legitimate use for PI space to have it. I am expanding the discussion list to NANOG and the ARIN Members mailing lists. Please post comments PUBLICALLY, or if you feel you cannot do so without "cloaking" yourself, through someone else (who you trust to strip the attribution). FIRST PROPOSAL: 1) The allocation policy of ARIN should be changed to reflect that any organization which can demonstrate that it can constructively use PI space should be able to receive it. "Constructively demonstrate" is stated to mean: a) The organization is multi-homed, possesses an ASN, and two or more independant T1-or-above rate connections to more than one backbone or other carrier (ie: to an exchange, to a NSP, to other ISPs). Documentation in the form of a signed connectivity agreement for a period of at least one year, or connectivity provable via existing network tools (ie: treno) is sufficient to satisfy this requirement. b) The ASN is visible at industry-accepted peering points and shows multiple paths available (ie: "nitrous.digex.net") c) The organization is EITHER: 1) Engaged in the business of selling connectivity to the general public, or can otherwise document a REASONABLE expectation that at least 75% of the /19 will be fully utilized at some point in the future during the expected lifetime of the IPv4 space (defined as 10 years). The firm must be able to prove this without resorting to a claim of confidentiality; in other words, you must be able to show that you're in the business of doing this from your public, visible, documentable actions. OR 2) The firm contains enough employees, staff members, and EXTERNALLY ADDRESSABLE infrastructure equipment within its boundaries to qualify for efficient use of a /19 on its own (ie: more than 5,000 staff members). 2) To receive MORE space, regardless of the size of the organization, the requestor must document that more than <X>% of the existing space allocated to it is either; a) In use internally; OR b) Delegated to actively visible customers who actually use said IP address space. An IP address shall be deemed to be "constuctively used" if any of the following apply to it at the /32 level: a) It responds to a PING or other network packet addressed to it when queried. b) It is properly referenced in both forward and reverse DNS files, and the hostname is traceable and billable to a customer who has ongoing revenue associated with same. (ie: an ISDN connectivity provider sells a class of service which has a /29 associated with it; they generate hostnames for all 8 addresses, and the customer is routed behind those addresses). c) It is a member of a operational DCHP or other dynamic pool, and is properly referenced in both forward and reverse DNS maps. d) It is delegated to a dedicated circuit or other routed business customer, and is part of a block of no more than 64 addresses assigned to that customer. Network broadcast addresses (defined as "all ones" host components) are excluded from these requirements, as are "all zeros", since some equipment demands that the "zeros" address remain). The value for "X%" shall be set by discussion within the AC and ratified by vote. All organizations must prove up use in all blocks delegated to or through them in order to receive any further delegation of space. I recommend that the value of "X" be set somewhere between 50 and 70%. This provides for some "slop", particularly in dedicated circuit customer situations (which are going to have some slop). However, it also prevents the practice of assigning a /24 to a customer who has five computers in their office - a practice which is extremely common! 3) A delegate producing documentation for classes of service (a - c) above may not claim privilege for these classes of information, as such is discernable from an external connection. 4) A delegate producing documentation for classes of service (d) may claim privilege as to the identities of the organizations involved, and may redact that information from their submissions, however, the actual allocations themselves must be documented. 5) All submitted documentation and prove-up performed under these policies are public information and subject to challenge by any member of the Internet community. -- -- Karl Denninger (karl(a)MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost

1 0

None
by John Fraizer 28 May '98

28 May '98

------- John Fraizer (root) | __ _ | The System Administrator | / / (_)__ __ ____ __ | The choice mailto:root@EnterZone.Net | / /__/ / _ \/ // /\ \/ / | of a GNU http://www.EnterZone.Net/ | /____/_/_//_/\_,_/ /_/\_\ | Generation A 486 is a terrible thing to waste...

1 0

Re: ingress filtering
by prue＠ISI.EDU 28 May '98

28 May '98

>Who *does* do ingress filtering? I have it on our border routers >and customer connect ports. We have transit from MCI and UUNET. >Neither has ingress filters -- see below message from MCI on >this. I have dealt with this in a different way. I have been figuring out interesting things to do with netflow data for a while now. I recently debugged a program which uses a file which has what looks like access lists associated with particular ports on my 7500's. The program then looks at the netflow data and dumps any record which is explicily denyed or implicitely denyed (implied deny any at end, like Cisco). It looks at the source addresses, uses the supplied mask and applies it only to the interface(s) in question. So I look at data from our backbone providers and see if there is any data being sent with my networks source address ranges. I look for packets from the backbones destined for x.x.x.255 to look for smurf type attacks. I have it looking at my customers data to make sure that they are only sending from address ranges that I expect and they aren't spoofing data against someone else. The nice thing about this is that it doesn't slow down the router by causing it to do compares on potentially long access lists real time while the data is comming in. I have netflow turned on and I dump the data to my unix host for the analysis. My sun workstation seems to have no problem keeping up with the traffic load. Since most data is legitimate, the workstation doesn't need to dump that much data. For interfaces on my router I have no concern for spoofed data I build no access lists for the netflow analysis program and it just ignores data comming in those interfaces. If I see something particularly henious I can put in an explicit filter to clobber it, in the router when it hits the router. Netflow records are still cut even if I do filter the stuff too. I can then complain to my service provider saying kill that spoof attack comming from your network. Or to my customers I can tell them cut out that spoof attack or I'll have to turn your line down. I can then monitor the progress to see if it has stopped yet. Great stuff and all at no extra work to the router. If there is enough interest I can write up some documentation on it and make it available via ftp. It again is based on the example tools Cisco built to demonstrate netflow capablities like the last tool I posted. Walt Prue Los Nettos

1 0

Xylan??
by kbrown＠primelink.com 28 May '98

28 May '98

I know this is off topic, but had someone in the office today trying to sell us on some Xylan switches? Anyone have any prior experience with these products? Please respond in private email only.

1 0

Re: 165.138.0.0
by Sean Donelan 28 May '98

28 May '98

>So is your rant about Sprint's filtering a macro by now? > >Or are you hoping that sheer repetition will somehow "fix" what >you perceive to be an evil conspiracy? Never attribute to duplicity what can be explained by stupidity. I'm perfectly willing to take Sprint at its corporate word. But if so, the same reasoning why sprint filters non-customer routes would apply to other ISPs filtering sprint customer routes. If sprint doesn't want to change its policy, its up to the sprint NOC to assist its customers to meet identical terms and conditions "Addresses not meeting the addressing filters, must either qualify for a larger chunk fo non-provider-assigned address space or get aggregatable address space from their immediate provider(s) and renumber their hosts into it." Renumbering is easy, everyone has to do it, even Sprint customers. Unless you are advocating that Sprint be treated to special conditions. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Re: Transit Routing
by Ehab Hadi 28 May '98

28 May '98

There is a very valable book dedicated for BGP4: Internet Routing Architectures By Halabi, Bassam; Softcover; 477 Pages Published by Cisco Press; 04/1997; ISBN: 1562056522 On-line Ordering: http://www.cbooks.com/sqlnut/SP/search/gtsumt?isbn=1562056522 Ehab Hadi ehabh(a)nortel.ca >From owner-nanog(a)merit.edu Thu May 28 11:21:32 1998 >Received: from localhost (daemon@localhost) > by merit.edu (8.8.7/8.8.5) with SMTP id NAA24073; > Thu, 28 May 1998 13:48:47 -0400 (EDT) >Received: by merit.edu (bulk_mailer v1.5); Thu, 28 May 1998 13:47:44 -0400 >Received: (from majordom@localhost) > by merit.edu (8.8.7/8.8.5) id NAA23921 > for nanog-outgoing; Thu, 28 May 1998 13:47:43 -0400 (EDT) >Received: from home.merit.edu (home.merit.edu [198.108.60.42]) > by merit.edu (8.8.7/8.8.5) with ESMTP id NAA23917 > for <nanog(a)merit.edu>; Thu, 28 May 1998 13:47:36 -0400 (EDT) >Received: (from ljb@localhost) by home.merit.edu (8.8.8/merit-2.0) id NAA16557 for nanog(a)merit.edu; Thu, 28 May 1998 13:47:35 -0400 (EDT) >Received: from fstop.shutter.net (root(a)fstop.shutter.net [209.14.1.1]) > by merit.edu (8.8.7/8.8.5) with ESMTP id JAA16061 > for <nanog(a)merit.org>; Thu, 28 May 1998 09:33:23 -0400 (EDT) >Received: from root (root.unixnet.org [209.14.1.6]) > by fstop.shutter.net (8.8.5/8.8.5) with SMTP id JAA30034 > for <nanog(a)merit.org>; Thu, 28 May 1998 09:33:19 -0400 >Message-Id: <199805281333.JAA30034(a)fstop.shutter.net> >From: "John Golovich" <john(a)shutter.net> >Organization: ShutterNet >To: nanog(a)merit.org >Date: Thu, 28 May 1998 09:36:54 +0000 >MIME-Version: 1.0 >Content-type: text/plain; charset=US-ASCII >Content-transfer-encoding: 7BIT >Subject: Transit Routing >Reply-to: john(a)shutter.net >References: <Pine.BSF.3.96.980527224232.2395B-100000(a)iago.nac.net> >In-reply-to: <Pine.BSF.3.95q.980528070230.2972A-100000(a)thuule.pair.com> >Sender: owner-nanog(a)merit.edu > >Can someone point me in the direction of some good white papers where >I could pick up some knowledge on BGP specifically in regards to >transit routing. > >I am working with 3 local ISPs here all connected to different >backbones. We are all going to be peering at one central office with >T-1 lines running between each location. > >Our intention is to allow each others traffic to flow through whoever >is the closest route. However I have only recently gotten into BGP. > >Any help is appreciated. > > ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

2 1

Re: 165.138.0.0
by Sean M. Doran 28 May '98

28 May '98

So is your rant about Sprint's filtering a macro by now? Or are you hoping that sheer repetition will somehow "fix" what you perceive to be an evil conspiracy? Sean.

1 0

Re: Why does Sprint have address filters again?
by Sean M. Doran 28 May '98

28 May '98

| If someone is asking now, the answer is that the | registries (ARIN didn't even exist at the time Sprint began filtering) | had no involvement other than to request that Sprint lower their filters | from a /18 to a /19. That is also my recollection. Sean.

1 0

Re: 165.138.0.0
by Aaron Branham 28 May '98

28 May '98

I got two nice replies from Sprint. They won't change their filtering policy overnight but they are at least considering it. I think they're interested in listening to customers on the issue, but please don't spamm or rant......hey if they do change it I might resubscribe to nanog :) I removed their email addresses because they didn't post it to nanog. Date: Thu, 28 May 1998 16:08:46 -0400 From: -removed- @sprint.net To: Aaron Branham <abranham(a)ind.net> Subject: Re: 165.138.0.0 Aaron, We have been talking internally about changing the policy for some time now. We are trying hard to figure out what really makes sense. With our entire core network made up of GSRs, we are capable of handling very large routing tables. I think the original intent of the policy was valid, even though it was unpopular. You are right, times have changed, and it may be the time to change the policy. Rational feedback from customers, such as you, as well as others in the industry will play heavily in our decision. However, don't look for it to happen over night as the result of some thread on nanog. Thanks again for your comments. ------------------------------------------------------- Date: Thu, 28 May 1998 16:01:48 -0400 (EDT) From: -removed- @sprint.net To: Aaron Branham <abranham(a)ind.net> Cc: SEAN(a)SDG.DRA.COM Subject: Re: 165.138.0.0 I don't want to get into a religious war over filters and our policy in that respect (especially on email :-). I just wanted to say that I did clean up the 129.122/16 as much as possible. The reason we don't just have one route in there is that the customer has multiple circuits with static routes. - - Aaron Branham [AKB8] (a(a)ind.net) <Phone# 317.263.8976>

1 0