- Test - lists.nanog.org

Re: FW: your mail
by Alex P. Rudnev 20 Oct '99

20 Oct '99

Yes, about _just another etc_... But I am very sceptical about the PIX, in contra to IOS FW FS, because: - if you need L3 level firewaii (smart filtering), PIX have not enougph network capabilities, and is too expansive. In our (KIAE, not RELCOM) case, PIX can't work on the trunk (ISL), can't work by the ATM, and so on... On the other hand, if wee need next level firewall, it should be context level firewall, which work as proxy and prevent mail bombs, macro viruses, .EXE trojans ets. AS I know, PIX can't do it. And we have not _soft_ firewall features which can protect against the scattered scanning, simple intrusions etc withouth (almost) complex configuration and access restriction for the internal users... > Date: Tue, 19 Oct 1999 13:08:49 -0700 > From: Glen Shok <gshok(a)cisco.com> > To: Alex P. Rudnev <alex(a)Relcom.EU.net>, Robert E. Seastrom <rs(a)seastrom.com> > Cc: Alex "Mr. Worf" Yuriev <alex(a)netaxs.com>, Rubens Kuhl Jr. <rkuhljr(a)uol.com.br>, nanog(a)merit.edu, Stephen Sprunk <ssprunk(a)cisco.com>, rs(a)valhalla.seastrom.com > Subject: Re: FW: your mail > > Guess I am a little late in replying... > > Where do you guys get your rumors about hardware??? > Anyway... > > The FW feature set on the 7500 is just another layer of protection and shouldn't be compared to the > performance of, say, using a PIX in front of your Internet Connection(s). > > Glen > > The preceding information is provided by "Glen" and not by "Cisco Systems", blah blah blah...insert legal stuff here.... > > > At 03:15 PM 9/27/1999 +0400, Alex P. Rudnev wrote: > > >Folks, why all you are saying about the Gigabit traffic for the firewall? > > > >Usially, firewall stand between intranet and internet, and it should > >proceed your upstream traffic, not more... And than, it's important to > >measure the throughput in packets/per_second, not in the gigabits... > > > >Everything other is true - I suggess no one good firewall can proceed > >gigabit traffic at all, and only a few specially designed boxes can > >proceed 100Mbit traffic. But just again - it's a rare case when you does > >have 100Mbit upstream link. > > > >Alex. > > > >On 25 Sep 1999, Robert E. Seastrom wrote: > > > > > Date: 25 Sep 1999 21:26:59 -0400 > > > From: Robert E. Seastrom <rs(a)seastrom.com> > > > To: "Alex \"Mr. Worf\" Yuriev" <alex(a)netaxs.com> > > > Cc: "Rubens Kuhl Jr." <rkuhljr(a)uol.com.br>, nanog(a)merit.edu, > > > Stephen Sprunk <ssprunk(a)cisco.com>, rs(a)valhalla.seastrom.com > > > Subject: Re: FW: your mail > > > > > > > > > > > > > > > I have listened to their seminar about this... As the simple L5 firewall > > > > > > it's not bad, through it realise the fixed set of ruls and defends your > > > > > > from the simple SMTP attacks only. But anyway, IOS FW is just what 90% of > > > > > > the customers need... > > > > > > > > > > How would IOS FW perform on Cisco 7x00-class equipment with 100M-to-Gigabit > > > > > traffic ? > > > > > > > > Umm... Very poorly. > > > > > > At the low end it's acceptable. Gigabit traffic sucks on 7500 series > > > routers even without any kind of filtering. > > > > > > The 7000-series routers, if they have an SSE, will do standard and > > > extended access lists in the switch engine. Now, given the > > > limitations of CX-FEIP-2TX boards (the only faste boards that will > > > work in a non-RSP 7000), you are lucky to get 70 mbit/sec through > > > that. If you have fddi, you can get most of the way to 100 mbit/sec > > > one way (the CX-FIP cards, which are the only FDDIs that work in a > > > 7000, won't do full-duplex). > > > > > > The 7500-series routers, you really want to get a VIP2-50 rather than > > > a 2-40 or lower if you're going to be doing filtering on the linecard. > > > You can load the fast ethernets up just fine there. > > > > > > 400 mbit/sec seems to be the upper limit of the currently shipping > > > generation of gigE cards for the 7500 series. > > > > > > Hope this helps (and standing by for corrections from the #cisco IRC mafia...) > > > > > > ---Rob > > > > > > > > > > > > >Aleksei Roudnev, Network Operations Center, Relcom, Moscow > >(+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N 13729 (pager) > >(+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax) > > > > > > > ------------------------------------------------------------------------------------------- > Glen Shok Phone: 1.650.404.3594 > Systems Engineer Cell: 1.415.215.7279 > NSP Norcal Operation Pager: 1.800.365.4578 > > Jack thought it twice, and thought that that that made it true. > > Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)

1 0

Re: NSI again removes services
by Dean Anderson 20 Oct '99

20 Oct '99

Hmm. I always thought the unix tip command was a reference to tip and ring of phone line pairs. This sounds more likely... Something for Peter Salus... --Dean Around 12:36 PM 10/19/1999 -0700, rumor has it that hardie(a)equinix.com said: >> TAC as in tacacs? > >Yep. The original TACACS specification was in a BBN technical >memo, CC-0045; RFC 1492 contains an informal specification >of the extended version that Cisco implemented. The background >section of RFC 1492 gives a bit of the history: > >Background > > There used to be a network called ARPANET. This network consisted of > end nodes (hosts), routing nodes (IMPs) and links. There were (at > least) two types of IMPs: those that connected dedicated lines only > and those that could accept dial up lines. The latter were called > "TIPs." > > People being what they were, there was a desire to control who could > use the dial up lines. Someone invented a protocol, called "TACACS" > (Terminal Access Controller Access Control System?), which allowed a > TIP to accept a username and password and send a query to a TACACS > authentication server, sometimes called a TACACS daemon or simply > TACACSD. This server was normally a program running on a host. The > host would determine whether to accept or deny the request and sent a > response back. The TIP would then allow access or not, based upon > the response. > > While TIPs are -- shall we say? -- no longer a major presence on the > Internet, terminal servers are. Cisco Systems terminal servers > implement an extended version of this TACACS protocol. Thus, the > access control decision is delegated to a host. In this way, the > process of making the decision is "opened up" and the algorithms and > data used to make the decision are under the complete control of > whoever is running the TACACS daemon. For example, "anyone with a > first name of Joe can only login after 10:00 PM Mon-Fri, unless his > last name is Smith or there is a Susan already logged in." > > The extensions to the protocol provide for more types of > authentication requests and more types of response codes than were in > the original specification. > > The original TACACS protocol specification does exist. However, due > to copyright issues, I was not able to obtain a copy of this document > and this lack of access is the main reason for the writing of this > document. This version of the specification was developed with the > assistance of Cisco Systems, who has an implementation of the TACACS > protocol that is believed to be compatible with the original > specification. To be precise, the Cisco Systems implementation > supports both the simple (non-extended) and extended versions. It is > the simple version that would be compatible with the original. > > Please keep in mind that this is an informational RFC and does not > specify a standard, and that more information may be uncovered in the > future (i.e., the original specification may become available) that > could cause parts of this document to be known to be incorrect. > > This RFC documents the extended TACACS protocol use by the Cisco > Systems terminal servers. This same protocol is used by the > University of Minnesota's distributed authentication system. > > > regards, > Ted Hardie > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

3 2

Re: TACACS or Radius daemon on Linux
by Dean Anderson 19 Oct '99

19 Oct '99

I'm not currently running Radius on linux, but I expect there are several possibilities that will run fine under linux. A good list was just posted here several days ago. You certainly don't want to be putting accounts on each box, especially if you have more than one. Your cisco's will do both tacacs and radius. Somehow, Radius seems to have beaten out tacacs in popularity though. Also, you might want to consider using RADIUS for accounting instead of syslog or none at all. --Dean Around 03:49 PM 10/19/1999, rumor has it that mnolan(a)southshore.com said: > >Hi, > >We are an ISP running several Cisco 2500s, 5200s, and 5300s as access >servers. Currently we are entering each user into each box. > >We are looking to set up a Red Hat Linux machine as either a TACACS or >Radius server to centrally validate all our users. > >Does anyone have any experience running a TACACS or Radius daemon >on Linux? Where is a good place to find a Linux TACACS or Radius >daemon? > >I heard that although TACACS is a Cisco product, Radius has more >accounting and statistics capability, runs well on Linux, and will >validate for Ciscos. > >Any help would appreciated. > >Thanks, >Mike > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1 0

Voluntary trial recommended to the FCC
by Sean Donelan 19 Oct '99

19 Oct '99

NRIC IV held their final meeting of 1999 on October 14. A couple of topics related to the Internet and ISPs were discussed. Am I still allowed to make fun of phone companies? Focus Group #1 - Finding #1 ISP interoperability with Internet Backbone Networks - Gather and analyze information on interoperability testing plans. This "gap" was identified by the NRIC testing subcomittee and reported to the President's council on Y2K at the NSTAC meeting in June. The President's Council will pursue ISP interoperability with the NSF and other agencies. Status: interoperability testing now planned between a large ISP and a major Internet backbone provider. Has anyone heard about this, or who the ISP and backbone provider involved are? There are several Y2K interoperability projects going on between NSPs, ISPs, IAPs, WHPs, and the rest of the TLA alphabet. However most are being down under NDA's. So, unlike phone power banking etc, not much about the Internet testing has been reported publically. Focus Group #3 A voluntary trial is recommended with the participation by service providers of [...] and ISPs to alert NCS/NCC of "widespread outages" that have significant public impact. The reporting criteria for ISPs: A failure that would cause a loss of service to a large number of customers for 30 minutes or more. Example: A Domain Name Server (DNS) failure Schedule Nov 23 Report posted on FCC site for comments Nov 23-Dec 7 Public comment period Dec 7 Comment period closed Dec 15 Revisions completed Dec 16 Final Report by the FCC Just in time for Dec 31/Jan 1, as if you didn't already have enough to worry about. Will you be ready for "voluntary" reporting to the NCS/NCC?

1 0

Re: NSI again removes services
by Dean Anderson 19 Oct '99

19 Oct '99

TAC as in tacacs? Around 09:43 AM 10/19/1999 -0700, rumor has it that hardie(a)equinix.com said: > >Wow, this looks like the SRI-era VOID database query result. The >impname and tacreq, in particular, look like they did back in the days >when SRI was still doing tac cards out of the same database as whois. >(TAC cards had user names and passwords which gave dial-up access to a >pool of terminal access controllers run by DCA) > >Ken Harrenstein wrote VOID to serve as the whois database for the >SRI-NIC and it had some useful bits that never made it in to later >implementations. I've always suspected that this was the influence of >augment, one of Doug Engelbart's data storage brainstorms (for the >TOPS 2065 platform). One of the useful bits was that you could >specify query type by sort algorithm as well as by key. So you got >wierd search commands like "li fi boo htype=h and netname=sri-net". >(That specified a last in, first out boolean query, which was the most >common type.) > >Sorry if the nostalgia break is off topic for you, > > Ted Hardie > > >John wrote: >> (0) htype: D | >> (1) handle: SERVICES5-DOM| >> (2) name: Network Services Clearinghouse| >> (3) hostname: | >> (4) netname: | >> (5) domainame: SERVICES.NET| >> (6) netaddress: | >> (7) address: c/o I.E.C.C. >> PO Box 640 >> Trumansburg, NY 14886 >> US| >> (8) admincontact: HOS228-ORG| >> (9) alternatepoc: | >> (10) activation_date: 21-Jan-1997| >> (11) billcontact: HOS228-ORG| >> (12) comments: | >> (13) connectype: | >> (14) coordinator: | >> (15) cputype: | >> (16) groups: | >> (17) hostadmin: | >> (18) host: | >> (19) impname: | >> (20) impnetnumber: | >> (21) impnumber: | >> (22) inaddrserver: | >> (23) usgpolicy: | >> (24) mailbox: | >> (25) netnumber: | >> (26) netblock: | >> (27) nicknames: | >> (28) opsys: | >> (29) parentdom: NET | >> (30) phone: | >> (31) protocols: | >> (32) servercontact: IVAN-HST LIGHT3-HST| >> (33) tacid: | >> (34) mctacnumber: | >> (35) techcontact: HOS228-ORG| >> (36) tissuedate: | >> (37) updated: 19970121-111213 dawnf=| >> (38) user_name: | >> (39) validcard: | >> (40) tacreq: | >> (41) zonecontact: HOS228-ORG| >> (42) registrar: | >> (43) asn_name: | >> (44) asn_number: | >> (45) asn_block: | >> -- >> John R. Levine, IECC, POB 727, Trumansburg NY 14886 +1 607 387 6869 >> johnl(a)iecc.com, Village Trustee and Sewer Commissioner, http://iecc.com/johnl, >> Member, Provisional board, Coalition Against Unsolicited Commercial E-mail >> > > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

3 2

NANOG 17 Peering BOF Meeting Notes
by William B. Norton 19 Oct '99

19 Oct '99

Hi all - I want to thank all of you who participated in the Peering BOF Monday night at the last NANOG meeting in Montreal. It was lively and very productive. To document the BOF, and for the benefit of those who could not attend NANOG, I am sending out my BOF meeting notes. Comments/Corrections welcome. As an aside, I'd like to thank my old colleagues at Merit for inviting me to return to the stage and MC the Montreal NANOG. It was a lot of fun - Thanks! Hope these notes help. Cheers - Bill ============================================================================ ==== Peering BOF - NANOG 17 - Montreal Monday October 4, 1999 7:30 PM EST Moderator: William B. Norton, Equinix, <wbn(a)umich.edu> Attendees: About 150? from NANOG meeting The agenda consisted of three items: 1) Ground Rules, 2) Presentation and Discussion of the Peering Decision Tree white paper, and 3) Populating the initial Peering Contact Database to facilitate peering 1) The Ground Rules were ------------------------ A) Not focus on about Peering politics, who gains, etc. B) Not about settlement, nor valuation of peering, etc. C) Instead, Focus on positive things we can do to facilitate peering Capture (document) the essence of peering process 2) Peering Contact Database --------------------------- The Peering Decision Tree interviews (about a dozen) turned up a key challenge ISP Peering Coordinators face: identifying the right staff to speak with at the other ISP. To this end, we helped with this process by having participating Peering Coordinators toss their business cards into the hat. Information they *did not* want in the peering contact database was crossed out. I assembled the cards and e-mailed an excel spreadsheet of all the Peering Coordinators to all the Peering Coordinators that tossed in their cards. <Note: About 50 ISPs tossed in their card and received a copy of the Peering Contact Database. I'm updating the database : if you are a involved in peering and would like to be listed in the Peering Contact Database (and receive a copy of the current Peering Contact Database), please send the relevant contact information (Contact Name & Title, Company Name, address, AS #, peering@<ispdomain>.net address for peering, phone numbers, etc.) to wbn(a)umich.edu. I will not send the database to those who do not contribute info to the database, nor folks who are not peering coordinators. I'll send out periodic updates as appropriate.> Naturally, the value of the Peering Contact Database to the community is proportional to the number and type of peering coordinators listed. To help maximize this, I'll try to grow the population of this database by repeating the peering BOF at a variety of forums domestic and international. Suggestions welcome. 3) The Peering Decision Tree Discussion --------------------------------------- The majority of the meeting was focused on the Peering Decision Tree. I interviewed about a dozen ISPs and documented the peering process in the Peering Decision Tree white paper. We walked through the paper in the BOF and validated the decision model; this roughly matches the peering coordinator logic. I started to write up a summary of this part of the meeting and found myself rewriting the paper! To save time, I'm simply including a raw text draft of the peering white paper. (Prettier version (pictures, etc.) available as a word document for those who participate in the Peering Contact Database or are willing to be interviewed/add to the document.) Please consider this a work in progress and send me comments! I'll try and incorporate those comments back into the document for the community. ------------------------------- snip ----------------------------------- Peering Decision Tree William B. Norton <wbn(a)umich.edu> DRAFT v 0.7 Abstract -------- Internet Service Provider (ISP) peering is an interconnection business relationship that decreases the cost and reliance on purchased Internet transit. As the single greatest operating expense, ISPs seek to minimize these telecommunications costs. Interviews with Internet Service Providers have highlighted three distinct decision phases of the peering process: Identification (Traffic Engineering Data Collection and Analysis), Contact & Qualification (Initial Peering Negotiation), and Implementation Discussion (Peering Methodology). The first phases identifies the who and the why, while the last phase focuses on the how. The appendix includes a diagram highlighting key questions asked when identifying peering candidates and determining methods of peering. I. Phase 1: Identification of Potential Peer: Traffic Engineering Data Collection and Analysis ---------------------------------------------------------------------------- ---- Choices made by Internet Service Providers (ISP) are often dominated by telecommunications cost issues. Highest among these costs are Internet transit costs that provide the ISP with connectivity to the global Internet. Transit Prices for DS-3 transit for example vary by circuit mile but can be as high as $50,000/month, and OC-3 transit can cost up to $150,000/month . To reduce these costs, ISPs seek peering (-zero or reduced cost) relationships with other ISPs that provide more direct traffic exchange and reduce the load on these expensive transit services (as shown below). To identify potential peers, ISPs use a variety of criteria. There may be existing business relationships that can be leveraged to include peering. Quantities of traffic distributed between networks often set the pace of the negotiation; to quantify this, ISPs may systematically sample inbound and outbound traffic flows. Flows then are mapped to originating AS, and calculations are made to determine where peering (direct interconnections) would most reduce the load on the expensive transit paths. There is substantial work involved here, as this traffic sampling results in a large number of data. The end result of this first phase is list of the top ISP candidates for peering. The greatly simplified peer qualification decision tree looks something like this: Once the measurements have been made and analyzed, and it appears to be of benefit to peer,, the ISP enters into Phase 2, Contact & Qualification, Initial Peering Negotiation. II. Phase 2: Contact & Qualification, Initial Peering Negotiation ---------------------------------------------------------------------------- ---- Internet Service Providers typically have a person or group specifically tasked with peering and traffic engineering issues. For example, UUNet has a "Peering Steering Committee" to evaluate peering requests. Some variations of the following steps lead to the parties either leaving the negotiation or proceeding to peering methodology discussions. The first step is for one of the parties to initiate contact with the potential peer. Today, discussion starts in one of the following ways: a) as part of a larger business transaction, b) via electronic mail, using the pseudo standard peering@<ispdomain>.net or a personal contact, c) from contacts listed on an exchange point participant list, d) with tech-c or admin-c from DNS or ASN registries, e) informal meeting in an engineering forum like NANOG, IETF, RIPE, etc., f) at trade shows from introductions among speakers, or with booth staff, g) from the target ISP sales force, h) from the target ISP NOC. The interviews to date have highlight a key challenge for ISPs: finding the right person to speak with is a difficult and time intensive process. Mergers and acquisitions further cloud lines of communication. This is where "people networking" helps a great deal, and hiring experience for their contacts speeds this initial contact process up quite a bit. Second, mutual non-disclosures may be negotiated and signed, and a discussion of peering policy and prerequisites follow. Traffic engineering discussions and data disclosure may be used to justify the peering relationship. Each ISP typically has a set of requirements for peering that include peering at some number of geographically distributed locations, sometimes at public exchange points. Traffic volume is usually a key determining factor. The decision rule hinges upon whether or not there is sufficient savings from peering to justify spending capital on a port on a router and/or a portion of the interconnection costs or augmenting existing capacity into an exchange point. A Bilateral Peering Agreement (BLPA) is the legal form that details each parties understanding of acceptable behavior, and defines the arms length interactions that each would agreed to. Another motivation for peering to factor in includes lower latency and/or more regional distribution of traffic than existing connections allow. This process is diagrammed below. After this initial discussion, either party may decide to walk away from peering discussions until certain criteria are met . If both parties agree that their requirements are met sufficiently to discuss methodology, and they both benefit from the peering relationship, they move onto Phase 3: Implementation Discussions. III. Phase 3: Implementation Discussions: Peering Methodology ---------------------------------------------------------------------------- ---- Since peering is of mutual benefit, both parties next explore the interconnection method(s) that most effectively exchange traffic to and from each other's customers. The primary goal is to establish mutual point(s) of interconnection, and secondarily detail optimal traffic exchange behavior (MEDs). For interconnections, ISPs face three options: Direct Circuit Interconnection, Exchange-Based Interconnection or some global combination thereof. The "Interconnection Strategies for ISPs" white paper quantifies the economics and technical tradeoffs between the first two options. To summarize this report, the preferred methodology depends on the number of peers participating in the region and bandwidth required for its regional interconnections. ISPs that expect to interconnect at high or rapidly increasing bandwidth within the region, or expect interconnections with more than five parties in the region often prefer the exchange-based solution. Those that do not anticipate a large number of regional interconnects prefer direct-circuits and typically decide to split the costs of interconnection with the peer by region. On occasion the costs are covered in whole by one peer. For direct-circuit interconnects, key issues center upon interconnection location(s) and who pays for and manages the interconnection. This becomes a material cost issue as traffic grows and circuits increase in size and cost. In either case, ISPs generally have the following goals for establishing peering: 1. fulfill obligations of larger business agreement, 2. get peering set up as soon as possible, 3. minimize the cost of the interconnection and their transit costs, 4. maximize the benefits of a systematic approach to peering, and 5. execute the regional operations plan as strategy dictates (may be architecture/network development group goal). Exchange Environment Selection Criteria ======================================= >From this point on the focus will be on the more scalable of the two approaches (the exchange-based interconnection method) and describe the selection criteria an ISP typically uses when selecting an exchange. Note that these issues are listed in no particular order. Telecommunications Access Issues -------------------------------- How fast can circuits be bought into the interconnection environment? How many carriers compete for my business for circuits back to my local Point of Presence (POP)? For facilities-based ISPs, what is the cost of trenching into the exchange (how far away and what obstacles present themselves)? Are there nearby fiber providers that lease strands? These answers will answer the most important question to ISPs: How fast can my peer and I get connectivity into the exchange? Multiple carriers lead to speed and cost efficiencies. Some ISPs have volume deals with certain carriers or otherwise preferred carriers so prefer exchanges where these carriers can quickly provision circuits. These answers strongly impact the desirability of the exchange environment. Deployment Issues ----------------- How do I get my equipment into the exchange (assuming it supports collocation)? Do I ship equipment in or do I have to bring it with me as I fly in? Will someone act as remote hands and eyes to get the equipment into the racks or do I do the installation myself? What are the costs associated with deployment (travel, staff time, etc.)? Does the exchange have sufficient space, power. The answers to these questions impact the deployment schedule for the ISP engineers and the costs of the interconnection method. ISP Current Presences --------------------- The most inexpensive (and expedient) peering arrangements are the ones made between ISPs that are already located in the same exchange with sufficient capacity to interconnect. Cross-connects or switching fabrics can easily establish peering within hours or at most days. ISPs will prefer to interact where one of both ISP already has a presence. Somewhat related, is the exchange in the right geographic location? Operations Issues ----------------- Once the ISP equipment and/or circuit into the exchange is installed, these issues focus on the ongoing operations activities allowed within the exchange. Does the exchange allow private network interconnections? Are there requirements to connect to a central switch? How secure is the facility? Is there sufficient power, HVAC, capacity at the switch, space for additional racks, real time staff support? Is it easy to upgrade my presence over time? Upgrading in this context means the ability to increase the speed of circuits into the exchange, the ability to purchase dark fiber, the ability to increase the number of racks and cross connects in the exchange, the ease of increasing the speed of interconnection. ISPs will prefer bandwidth-rich, ISP-friendly exchanges over those with restrictions over future operations. Business Issues --------------- Perhaps the most far-reaching issue is strategic: do we want to support this exchange operator, and do their interests enhance or conflict with ours? According to Lauren Nowlin, Peering Coordinator at PGExpress, "Bandwidth, strategic partner alliances, and corporate ties often override the technical justification ." Will using this exchange support a competitor (contribute to their net income, their credibility, their positioning)? Does the exchange have requirements (require use of their carrier or ISP services) that limit the market for services within the exchange? Since it is difficult and disruptive to move equipment out of an exchange, ISPs will prefer a neutrally operated exchange environment that doesn't suffer from market distortions and limitations due to business conflicts of interest. Cost Issues ----------- What is the cost of using this exchange? What are the rack fees, cross connect fees, port fees, installation fees? What are the future operating fees going to be? What are the motivations and parameters surrounding these fees? Cost issues shadow most of the other issues listed in this paper. All else being equal, ISPs will seek to minimize the costs, particularly upfront costs, associated with the interconnection for peering. Credibility Issue ----------------- Does the exchange exist today and will it exist tomorrow? Who will be there in the future? The benefit to the ISP grows (as pictured below) as the number of interconnection possibilities grow, as the number of transit customers grows, and as the bandwidth between the exchange participants grow. During the early stages of the exchange, ISPs are asked to make a leap of faith when committing, and therefore prefer an exchange with strong backing and the credibility to ensure the ISP obtains value. Does the exchange operator have the backing and credibility to attract the more valuable peering candidates? Who is managing the exchange and what technology is in use signals the credibility and survivability of the exchange. ISPs will prefer an exchange with credibility - one that is financially and technically well backed and likely to attract the most desirably peering candidates. Exchange Population ------------------- Are there other side benefits to using this exchange? Are there other ISPs there that are peering candidates? Are there transit sales possible at the exchange? In the context of the credibility issue discussed above, who will likely be at the exchange in the future, and when will the cost of participation equal the value of the interconnection (also known as the Critical Mass Point)? ISPs will prefer established and well-populated exchanges, particularly those with potential customers that can generate revenue for the ISP. Existing Exchange vs. New Exchange? ----------------------------------- There are many regional "meet me" exchange points in each region of the U.S. There are also emerging exchanges that may be considered. However, given the pace of ISP expansion, it is unlikely that emerging exchange offerings are differentiated or compelling enough to be preferred over existing exchanges. Chronic traffic congestion can influence the decision to plan to peer in an existing exchange or wait until a better exchange opens. Customers with heavy flows of regional traffic can also influence the decision. Long term benefits (scalability) may lead to preferring a next generation exchange. However, all else considered equal, ISPs generally prefer an existing exchange to an emerging one. This third discussion phase can be summed up by the following graph. IV. Summary =========== The paper provides a rough description of the decision process ISPs follow to obtain peering relationships and reduce their transit costs. It focuses on the elements of the decision that lead to the selection of a specific exchange environment for peering. The results of the interviews with ISP Peering Coordinators can be summarized with the following observations: 1) To reduce transit costs, peering goals for ISPs include a) to get peering set up as soon as possible, b) to minimize the cost of peering, c) to maximize the benefits of whatever architecture is selected, and d) to leverage the architecture to accomplish their strategic regional goals. 2) The selection of an exchange is made relatively late in the peering process, and the selection of a soon-to-be-available exchange is a very difficult sell. This is particularly true when there are existing exchanges in the region that meet the ISPs requirements. 3) Most critical to the ISP are issues surrounding business opportunities presented at an exchange, telecommunications access, deployment, population, operations, cost, and credibility. ISPs will prefer and exchange environment that best suit these needs. 4) One major challenge facing Peering Coordinators is the identification of potential peers and initiating discussions. Acknowledgements ---------------- This paper was the result of interviews with key Internet peering coordinators, interactions with ISP support staff, and side conversations at various meetings and forums. Special thanks to a few folks who contributed their time and ideas to help create this early draft report: Ren Nowlin (PGExpress/Onyx), Joe Payne (IXC), Dave Diaz (Netrail), Jake Khuon and Alan Hannan (Frontier GlobalCenter), Dan Gisi and Jeff Rizzo (Equinix), Patricia Taylor-Dolan (Level 3 Communications), Sean Donelan (AT&T Labs). As interviews continue, this list will expand to identify other key contributors to this paper. References ---------- [1] "Maturation in a Free Market: The Changing Dynamics of Peering in the ISP Market" by Jennifer DePalma [2] "NAPs, Exchange Points, and Interconnection of Internet Service Providers: Recent Trends, Part I: 1997 Survey of Worldwide NAPs and Exchange Points", Mark Knopper Appendix A: Peering Decision Tree Appendix B: Detail Peering Decision Tree Some interesting side notes from the BOF ------------------------------------------- +At least two countries including Israel have regulators that forced ISPs to peer. +Formal legal documents are not required for peering, although commonplace +Keith Mitchel (LINX) has a prototype Bi_Lateral Peering Agreement (BLPA) on-line: http://www.linx.net/joininfo/peering-template/agreement-v4.html +The group wanted the Peering Contact Database NOT to be public, but rather limited to the folks participating. +Non-U.S. ISPs seem to have greater difficulty establishing peering here in North America. Language, culture issues are mixed with technical issues. ---------------------------------------------------------------- William B. Norton <wbn(a)equinix.com> +1 650.298.0400 x2225 Equinix Co-Founder, Director of Business Development

6 6

Re: ISP and NAT (question and some thoughts)
by Alex P. Rudnev 19 Oct '99

19 Oct '99

Hmm, there is some interesting idea in this message - to keep some track of the initial (pre-NAT) address/port somewhere in the packet (may be in the start packets, at least)... > > I think this has merit. If I understand RSIP correctly (which is meant to > replace NAT), you need an RSIP enabled client and an RSIP enabled router. > Therefore, people are considering doing deployment changes. Problem is > that once the pkt leaves the RSIP enabled router destined to the Internet, > one has no idea that the IP address and port number (auto-generated by the > RSIP router) are really masking a NAT address. By tweaking a bit in the > IPv4 header (that is transitive and won't harm anyone by looking at it) as > you suggested might make more sense and thereby give downstream users an > idea that the pkt they are seeing is really an RSIP modified packet. > > Basically - a merge of RSIP and your idea. Any IETF RSIP people want to > pick up on this? > > -Hank > > > > > >There are a couple of unused bits in the IPv4 header that one could use. > I thought of this during the last "paper" to expand address space that > circulated this summer on nanog. > > > >Unfortunately, the real problem is deployment. Once you decide to change > the protocol in any way that is not completely downward compatible, > everyone has to deploy the modification. I'm going to hazard a guess that > IPv6 will really be widely deployed by tunneling it in IPv4. And I'll > hazard that much of the IPv6 traffic will just contain tunnelled "private" > IPv4 traffic. Tunnel inside tunnel. So much for header compression. > > > > --Dean > > > >Around 01:13 PM 10/18/1999 -0400, rumor has it that > jeanlou.dupont(a)na.marconicomms.com said: > >> > >> > >> > >>just a thought... > >> > >>why not expand the IPv4 address field using the 'Fragment offset' and > >>'Identification' fields? > >>Use those fields to mark packets at the edge with the destination AS > number, for > >>example. > >>Customer equipment could use private address space and not bother with > the edge > >>remarking process. > >>(I know that the fragmentation function would be lost due to this > 'extension'.) > >>(I am also aware of transitioning problems related to what I am > proposing; the > >>routers in the network cannot be upgrade all at once...) > >> > >>thoughts/comments? > >> > >>jld. > >> > >> > >> > >> > >> > >>"Alex P. Rudnev" <alex(a)virgin.relcom.eu.net> on 10/18/99 12:46:50 PM > >> > >>To: nanog(a)merit.edu > >>cc: (bcc: Jeanlou Dupont/RMQ/RELTECCORP) > >> > >>Subject: ISP and NAT (question and some thoughts) > >> > >> > >> > >> > >> > >> > >>Today we see the classical schema ISP/customer; this means > >>- the customer have his own address space, requested by him (directly or > >>undirectly) > >>- due to the lack of public addresses, the customers are forced to use > >>NAT; just NAT provide some extra security > >>- ISP do not provide NAT themself; NAT configuration is not easy task and > >>cause a lot of headache for the customers (just as a lot of money they pay > >>to the network admins). > >> > >>First question - is this picture right or it is wrong? > >> > >>The second question. What prevent the _future ISP_ from some another > >>schema, when: > >>- the customer always use the private address space, for example, > >>10.0.0.0/8; > >>- the provider bother about address translation, just as about name > >>translation (DNS re-writing), just as about the address allocation (not > >>the customer but the provider - if existing address space is not enough); > >>- the providers's software learn about _open, or public_ services which > >>must be translated statically, from the customer using (for example) DNS. > >> > >>Don't answer _it's too slow_. > >> > >>This is my attempt to predict where we are going this days. Today the > >>_know-how_ the customer should know is too huge - if (if I am the admin of > >>the company, not ISP!) I open electronic > >>market or want to get Internet for the companies employees, I must > >>allocate space (why? What for? It's not my concern, if we think a little), > >>I must prove I need this addresses (why? This is my business how much > >>addresses I need internally; and let's software decide how much addresses > >>I need externally), and I should configure firewalls and NAT's. We used to > >>think about it as about the normal admin's knowledge; but why we are sure > >>it's normal. If you got a car (in USA, not in the Russia), you don't > >>bother about the oil stations or about the roads - you just use it. > >> > >>This is not really a dump question. If it is possible to build such > >>Internet service when every customer should be free to use any address > >>space in the hidden way, and ISP (not the customer) bother about the > >>global address and name translation, we should have just this hierarchical > >>address schema IPv6 offer to us. On the other hand, it means a great > >>increase in the NAT engine. > >> > >> > >>Aleksei Roudnev, Network Operations Center, Relcom, Moscow > >>(+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) > 230-41-41, N > >>13729 (pager) > >>(+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax) > >> > >> > >> > >> > >> > >> > >> > >> > >> > >++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > Plain Aviation, Inc dean(a)av8.com > > LAN/WAN/UNIX/NT/TCPIP http://www.av8.com > >++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > > > Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)

1 0

Re: ISP and NAT (question and some thoughts)
by Vadim Antonov 19 Oct '99

19 Oct '99

O, wow. Take two broken-as-designed technologies, mix together... :) --vadim > I guess going to IPv6 would be simpler in this case. > Or, we can maybe dream of some 'service locator' function tied to inter-domain > MPLS tunnels... > again, just food-for-thoughts. > jld.

2 1

ISP and NAT (question and some thoughts)
by Alex P. Rudnev 19 Oct '99

19 Oct '99

Today we see the classical schema ISP/customer; this means - the customer have his own address space, requested by him (directly or undirectly) - due to the lack of public addresses, the customers are forced to use NAT; just NAT provide some extra security - ISP do not provide NAT themself; NAT configuration is not easy task and cause a lot of headache for the customers (just as a lot of money they pay to the network admins). First question - is this picture right or it is wrong? The second question. What prevent the _future ISP_ from some another schema, when: - the customer always use the private address space, for example, 10.0.0.0/8; - the provider bother about address translation, just as about name translation (DNS re-writing), just as about the address allocation (not the customer but the provider - if existing address space is not enough); - the providers's software learn about _open, or public_ services which must be translated statically, from the customer using (for example) DNS. Don't answer _it's too slow_. This is my attempt to predict where we are going this days. Today the _know-how_ the customer should know is too huge - if (if I am the admin of the company, not ISP!) I open electronic market or want to get Internet for the companies employees, I must allocate space (why? What for? It's not my concern, if we think a little), I must prove I need this addresses (why? This is my business how much addresses I need internally; and let's software decide how much addresses I need externally), and I should configure firewalls and NAT's. We used to think about it as about the normal admin's knowledge; but why we are sure it's normal. If you got a car (in USA, not in the Russia), you don't bother about the oil stations or about the roads - you just use it. This is not really a dump question. If it is possible to build such Internet service when every customer should be free to use any address space in the hidden way, and ISP (not the customer) bother about the global address and name translation, we should have just this hierarchical address schema IPv6 offer to us. On the other hand, it means a great increase in the NAT engine. Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)

2 1

Offtopic: VERIO --> BGP/Routing problem? (fwd)
by Tim Wolfe 18 Oct '99

18 Oct '99

I e-mailed this to noc(a)verio.net as per their contact information on the page at puck.nether.net I also attempted to contact their 800 "noc" number but it dumps me into a queue for customer support (hold queues suck BTW). Can someone with a clue from Verio please contact me off list ASAP? (If they didn't invite all of those people to go elsewhere that is) -- Tim -------------------------------------------------- * Timothy M. Wolfe, Chief Network Engineer * * ClipperNet Corporation / It's a wireless world * * tim(a)clipper.net 800.338.2629 x 402 * * Sufficient for today = Inadequate for tomorrow * -------------------------------------------------- ---------- Forwarded message ---------- Date: Mon, 18 Oct 1999 11:41:22 -0700 (PDT) From: Tim Wolfe <tim(a)clipper.net> To: noc(a)verio.net Cc: support(a)clipper.net Subject: BGP/Routing problem? I'm getting extremely irate customers all with complaints about sites/networks on Verio's network. Traceroutes to multiple locations all die as shown below, any ideas? [root@net-admin /root]# traceroute www.continet.com traceroute to hansolo.continet.com (206.58.168.253), 30 hops max, 40 byte packets 1 gateway.hq.eug.clipper.net (216.116.45.190) 0.532 ms 0.425 ms 0.398 ms 2 coburg04.router04.clipper.net (209.180.239.254) 19.263 ms 38.812 ms 38.601 ms 3 noc.coburg06.eug.clipper.net (216.116.32.53) 123.452 ms noc.co02.eug.clipper.net (216.116.32.1) 112.872 ms noc.co04.eug.clipper.net (216.116.32.5) 77.812 ms 4 cisco.core.eug.clipper.net (216.116.32.65) 83.984 ms 29.316 ms 248.527 ms 5 border02.usw04.clipper.net (207.109.242.45) 544.418 ms 243.517 ms 101.522 ms 6 router.usw.clipper.net (207.109.240.250) 234.573 ms 158.146 ms 92.305 ms 7 500.Serial5-1-0.GW1.POR2.ALTER.NET (157.130.177.201) 272.617 ms 140.342 ms 192.853 ms 8 121.ATM3-0.XR2.SEA1.ALTER.NET (146.188.200.182) 63.554 ms 97.295 ms 87.504 ms 9 194.ATM8-0-0.BR1.SEA1.ALTER.NET (146.188.200.77) 38.719 ms 85.008 ms 67.806 ms 10 uunet.sea3.verio.net (129.250.9.53) 132.312 ms 77.157 ms 187.899 ms 11 sea3.sea2.verio.net (129.250.2.229) 104.399 ms 51.872 ms 47.942 ms 12 * * * [root@net-admin rc.d]# traceroute 205.162.201.235 traceroute to 205.162.201.235 (205.162.201.235), 30 hops max, 40 byte packets 1 gateway.hq.eug.clipper.net (216.116.45.190) 0.536 ms 0.410 ms 0.387 ms 2 coburg04.router04.clipper.net (209.180.239.254) 14.443 ms 9.093 ms 10.161 ms 3 noc.co04.eug.clipper.net (216.116.32.5) 21.815 ms noc.coburg06.eug.clipper.net (216.116.32.53) 18.024 ms 20.605 ms 4 cisco.core.eug.clipper.net (216.116.32.65) 69.319 ms 19.117 ms 19.315 ms 5 border02.usw04.clipper.net (207.109.242.45) 27.940 ms 39.711 ms 54.538 ms 6 router.usw.clipper.net (207.109.240.250) 83.400 ms 48.314 ms 74.778 ms 7 500.Serial5-1-0.GW1.POR2.ALTER.NET (157.130.177.201) 123.655 ms 60.980 ms 56.282 ms 8 121.ATM3-0.XR2.SEA1.ALTER.NET (146.188.200.182) 58.828 ms 86.353 ms 82.602 ms 9 194.ATM11-0-0.BR1.SEA1.ALTER.NET (146.188.200.69) 70.771 ms 169.238 ms 58.317 ms 10 uunet.sea3.verio.net (129.250.9.53) 35.361 ms 30.677 ms 57.102 ms 11 sea3.sea2.verio.net (129.250.2.229) 71.382 ms 60.869 ms 54.746 ms 12 * * * -- Tim -------------------------------------------------- * Timothy M. Wolfe, Chief Network Engineer * * ClipperNet Corporation / It's a wireless world * * tim(a)clipper.net 800.338.2629 x 402 * * Sufficient for today = Inadequate for tomorrow * --------------------------------------------------

1 1