June 1998 - Test - lists.nanog.org

Re: Sprint's New ION products
by Kent W. England 04 Jun '98

04 Jun '98

Scott Brim <swb(a)newbridge.com> writes: >I believe it's IP/PPP/ATM/DSL to the home, and IP/Tag/ATM/Sonet in the backbone. That is about as succinctly put as can be, but I didn't get the impression that all apps would run over one stack. There seems to be room for an ATM API in the announcement, but no explicit mention. The most radical change for an established telco like Sprint is that Sprint has seen the light from the Great Crossover ahead and decided it is best and cheapest to run voice calls over packet or cell than over separate switched networks. It's getting to be a no-brainer decision, unless the guys in the domed building in WDC eliminate switched network access charges to the incumbents, which is apparently unlikely. So all voice moves to packet/cell ASAP to avoid switched network call termination charges as much as possible. Really a forced migration in terms of business costs, since the termination charges in the one to three cent/minute range are enormous compared to the cost of a packet voice call. >Are there any expected dates for deployment? Given the timeframe to get multi-megabit copper or DSL from the incumbents and the fact that within that timeframe qos-IP/DWDM/fiber equipment will cost about 10% of IP/ATM/SONET/DWDM/fiber, I would say "never" is most likely. Of course, they can deliver this to "big corporate customers" on bypass right now, so perhaps the answer is "now". But "never" to the small business and residential market. --Kent

4 3

Re: PPP over Ethernet?
by Richard Parker 04 Jun '98

04 Jun '98

woody wrote: >The standard for PPP over Ethernet is L2TP. The pre-standard proprietary >implementations were L2F and PPTP, from Cisco and Microsoft, respectively. >I believe you'll find Internet Drafts on all three. L2TP is currently an Internet Draft: <http://www.ietf.org/internet-drafts/draft-ietf-pppext-l2tp-11.txt> L2F was an Internet Draft, but has since been published as an RFC: <ftp://ftp.isi.edu/in-notes/rfc2341.txt> PPTP was an Internet Draft but has since been deleted (see note): <http://www.ietf.org/internet-drafts/draft-ietf-pppext-pptp-06.txt> -Richard

1 0

Re: different thinking on exchanging traffic
by Sean Donelan 04 Jun '98

04 Jun '98

>> Currently about 5%-15% of my traffic gets routed over the UtahREP. > >please describe measurement technique. I think there are actually a couple of different traffic measurements of interest. traffic volume, traffic elasticity, and traffic usability. Traffic volume is fairly simple, but also mostly useless. Measure the total traffic exchange through the local exchange point (e.g. peak 2Mbps in St. Louis) and that is a definition of traffic exchanged by the local ISPs that isn't going across transit lines to upstream providers. Harder to measure is how 'local' any of the ISPs actually are. In the st. louis case, all of the ISPs operate in at least two states, and two of them operate in more than two states. None of them, as far as I know, have tried to break up their routing into geographic regions. Traffic elasticity is an interesting issue. How much traffic is being exchanged, which wouldn't otherwise be exchanged? In other words is the existance of the local exchange point actually causing more traffic to be generated. This is a what if question. If you didn't have the local exchange, would you still haul highly elastic traffic like USENET across your long-haul links? Or is it highly elastic traffic like at-home students or employees who use a local ISP modem pool for access instead of dialing directly into the remote institution. And finally, usability. The I know it when I see it issue. The right combination of adequate speed, low latency, and little congestion that gives the end-user a 'good' connection. Since we still have a hard time defining what is 'good' this is the hardest one to measure. I can really only measure this indirectly, such as the number of customer compliants or through surveys of non-customers. In general, customers of ISPs connected to the local exchange point report better connections to resources on ISPs also attached to the local exchange point than to those same ISPs before the exchange point. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

5 5

Attack/DoS
by Todd R. Stroup 03 Jun '98

03 Jun '98

Don't know if it is just me. But over the last 10 hours we have been seeing attacks on port 0 from port 0 (both tcp and udp) on several clients networks. I have also seen the same attack on port udp 53(DNS). Anyone have any information on this? Todd R. Stroup Fiber Network Solutions, Inc. > ---------- Forwarded message ---------- > Date: Mon, 1 Jun 1998 21:58:17 -0500 > From: "J.A. Terranson" <sysadmin(a)MFN.ORG> > To: BUGTRAQ(a)NETSPACE.ORG > Subject: (Admittedly Premature) Exploit (?) Warning. > > While I realize that this issue may not yet be "ripe", as I the folks involved > (myself and at least three other sites) have not yet firmly established just > *exactly* what is going on here, but... > > There appears to be some kind of exploit making the rounds that utilizes > TCP packets from port "0" (yes, that's *zero*) to the IMAP port, 143. These > packet traces are right now available only as historical log entries that are > *loosely* associated with 2 successful "root" attacks against IMAP enabled > servers, an unsuccessful attack against another (ours), and the possible > compromise of another. > > In short, I dont know a lot, other than in the course of reviewing my > daily logs, I saw a couple of freaky packets (above) addressed to my > nameservers (both of them). They were rejected and logged at the routers, > however, as a common courtesy, we notified the admin of the "sending" > machine that they had a sick box. As it developed, this person had > recieved other emails regarding this from other admins, 2 of which had > suffered the successful attacks mentioned above - all of us seeing the > originating machine as the same box. It is unknown if the source address was spoofed. > > Basically, I think this is just a "common-cause" warning to look out > for weird packets of this nature, and to take notice if you see any. > > Rather than keep a running blow-by-blow going on the various lists, > please address anything regarding this to me directly... > > Thanks > J.A. Terranson > sysadmin(a)mfn.org > > >

2 1

RE: Attack/DoS
by Todd R. Stroup 03 Jun '98

03 Jun '98

Thanks for all of your responses... but 1) I don't really need the consultants replys saying that you will fix my problems for $100/hour. 2) This isn't the BIND 8.x.x problem for getting root. For this reason : interface Loopback10 ip address 209.115.17.65 255.255.255.224 ip access-group 113 out Its rather difficult to get BIND to run on a Cisco 7507, although some people probably have tried to get it to work. We are viewing this from a cisco router with an access-list that basically looks like this : access-list 113 permit ip any any log Example of the udp port 0 attack : list 113 permitted udp 38.9.202.2(0) -> 209.115.17.67(0), 1 packet list 113 permitted udp 194.66.96.2(0) -> 209.115.17.67(0), 1 packet list 113 permitted udp 199.191.128.106(0) -> 209.115.17.67(0), 1 packet list 113 permitted udp 194.62.44.10(0) -> 209.115.17.66(0), 1 packet Example of the DNS (53) attack : list 113 permitted udp 207.150.3.11(53) -> 209.115.17.66(53), 121 packets list 113 permitted udp 203.77.1.1(53) -> 209.115.17.67(53), 1 packet list 113 permitted udp 194.62.44.10(53) -> 209.115.17.67(53), 2 packets list 113 permitted udp 194.66.96.2(53) -> 209.115.17.67(53), 91 packets An interesting thing to note is who ever programed this attack used the same IP addresses in a round robin type fashion for both (or maybe it is just selectable in the DoS, who knows). Todd R. Stroup Fiber Network Solutions, Inc. > From: Todd R. Stroup [mailto:tstroup@FNSI.NET] > Sent: Wednesday, June 03, 1998 3:53 PM > To: BUGTRAQ(a)NETSPACE.ORG > Subject: Attack/DoS > > Don't know if it is just me. But over the last 10 hours we have been > seeing attacks on port 0 from port 0 (both tcp and udp) on several clients > networks. I have also seen the same attack on port udp 53(DNS). > > Anyone have any information on this? > > > Todd R. Stroup > Fiber Network Solutions, Inc. > > > > ---------- Forwarded message ---------- > > Date: Mon, 1 Jun 1998 21:58:17 -0500 > > From: "J.A. Terranson" <sysadmin(a)MFN.ORG> > > To: BUGTRAQ(a)NETSPACE.ORG > > Subject: (Admittedly Premature) Exploit (?) Warning. > > > > While I realize that this issue may not yet be "ripe", as I the folks involved > > (myself and at least three other sites) have not yet firmly established just > > *exactly* what is going on here, but... > > > > There appears to be some kind of exploit making the rounds that utilizes > > TCP packets from port "0" (yes, that's *zero*) to the IMAP port, 143. These > > packet traces are right now available only as historical log entries that are > > *loosely* associated with 2 successful "root" attacks against IMAP enabled > > servers, an unsuccessful attack against another (ours), and the possible > > compromise of another. > > > > In short, I dont know a lot, other than in the course of reviewing my > > daily logs, I saw a couple of freaky packets (above) addressed to my > > nameservers (both of them). They were rejected and logged at the routers, > > however, as a common courtesy, we notified the admin of the "sending" > > machine that they had a sick box. As it developed, this person had > > recieved other emails regarding this from other admins, 2 of which had > > suffered the successful attacks mentioned above - all of us seeing the > > originating machine as the same box. It is unknown if the source address was spoofed. > > > > Basically, I think this is just a "common-cause" warning to look out > > for weird packets of this nature, and to take notice if you see any. > > > > Rather than keep a running blow-by-blow going on the various lists, > > please address anything regarding this to me directly... > > > > Thanks > > J.A. Terranson > > sysadmin(a)mfn.org > > > > > > >

1 0

history of peering arrangements
by incoming-nanog＠hooked.net 03 Jun '98

03 Jun '98

Forwarded from a non-subscriber. Replies to her, please. >From jdepalma(a)cato.org Wed Jun 3 10:09:02 1998 >Date: Wed, 03 Jun 1998 13:23:03 -0400 >From: Jennifer DePalma <jdepalma(a)cato.org> >To: zorch(a)hooked.net >Subject: history of peering arrangements > > >I'm attempting to compile a history of peering agreements between >ISPs from the beginning, through UUNet's decision to charge small >providers, and up to the implications of the WorldCom merger. If you >know of any valuable sources (articles, persons I might speak with), >please let me know. I'd appreciate any guidance you might offer. > >Thanks, >Jennifer > > >***************************** >Jennifer A. DePalma >202.789.5226 >202.842.3490 (fax) > >Research Analyst >Telecommunications and Technology Studies >Cato Institute >1000 Massachusetts Ave., NW >Washington, DC 20001 >

2 1

NANOG 13 Final Logistics
by William B. Norton 03 Jun '98

03 Jun '98

Hi all - Just a few announcements regarding next week's NANOG. Pre-registration for pre-paid attendees --------------------------------------- Pre-registration will be held from Noon until 3PM Sunday in the Hubbard Foyer for those who have pre-paid. The NANOG 13 T-shirts won't be available until Monday morning though. Setup Volunteers Welcome ------------------------ We will be setting up the Hubbard Ballroom Sunday morning around 8AM. Several folks have volunteered in the past to help with setting up equipment, running and taping down wires, etc. If you would like to help, come on down Sunday morning; the folks wearing the blue NANOG Staff shirts will be glad to put you to work. Lunch Tickets ------------- As most hosts have done in the past, Merit Network is graciously providing lunch tickets for 300 attendees both Monday and Tuesday. Tickets will be available on a first-come first-serve basis at the registration desk Monday morning for Monday lunch and Tuesday morning for Tuesday lunch. In the 300 lunches, we specified 100 vegetarian and a bunch of Kosher as well. Bring your Laptops ------------------ As suggested on the survey forms, we have increased the number of laptop tables for this meeting. The terminal room (located in the Stutz-Bearcat Room) has a minimal # of PCs (about 20) running Unix. Another reason to bring your laptops is that many of the presentations will be on-line linked off the NANOG agenda web page so you can view the slides on your laptop while the presenter walks through them. (My ultimate goal is to be able to queue questions electronically so you can ask questions during Q&A through your laptop microphone, but we're not quite there yet.) Thanks to DEC for providing a half dozen or so wireless access points. Jake Khuon (Merit) will be working with Jeff Rizzo (DEC) and Jeff Schwartz (Cabletron/DEC) to loan a few wireless PCMCIA units as well. Thank to the many that have contributed to this NANOG ----------------------------------------------------- The NANOG counts on the support of the community for everything from agenda topics to loaner equipment and event sponsorship. We would like to again thank the following companies for their commitments to NANOG: +Bay Networks for providing the room connectivity. We will have dozens of hubs for over 400 wired ethernet ports for this meeting! +RBN for casting the meeting and providing storage and reply facilities +Cisco for providing the hardware and staff to cast the meeting on the MBone +University of Michigan Information technology Division for providing PCs for the terminal room +Aptis, Bay, and Cisco for providing the Beer-n-Gear event +Cabletron for providing Wireless transceivers and a handful of loaner PCMCIA cards +Merit MichNet for providing transit connectivity to the Hyatt Dearborn Thanks especially to Larry Blunk and Eric Sobocinski who have taken the lead on connectivity to and throughout the meeting space as well as getting the terminal room and servers set up at the Dearborn Hyatt. Thanks Guys! For those attending the meeting Physically rather than Virtually ---------------------------------------------------------------- Bring your appetite for the Monday evening beer-n-gear; there will be many varieties of great food, beer, and gear from Aptis, Bay and Cisco! Speaking of T-shirts...FYI, I have been forced to clean out the Merit closet of old NANOG T-shirts. In doing so, I found that I have enough left over T-shirts to make a small number of "NANOG Tshirt Collector's Sets, N8-N12". I will give away 2 of these Collector's sets away at the next NANOG to those who fill out (and identify themselves on) the survey forms (for lack of a better method). Thanks, and see you all in Dearborn. Bill -------------------------------------------------------------- William B. Norton <wbn(a)merit.edu> (734) 764-9430 (New Area Code)

1 0

New Service Models Coming - Or, All About Bypass
by Jim Fleming 03 Jun '98

03 Jun '98

---- New Service Models Coming - Or, All About Bypass --- In my opinion, the ION announcement by Sprint is only the tip of the iceberg. North American network operators may also want to look at the following press release from Lucent and note that MCI is mentioned as the company testing the new products. http://www.lucent.com/press/0598/980527.nsa.html There is a certain irony that AT&T is not part of these activities...yet... The Internet has captured the imagination of a wide range of people. The Internet has been constructed around the edges of the existing telecommunications infrastructure. Many people have leveraged small investments into large empires and are now resting on their winnings. While they are resting and as the Internet becomes as insular as the old telecommunication cliques, others are busy building new structures around the edges of the existing IPv4 infrastructure. The following is just one example. Some of the ideas put forth in the Sprint annoucements confirm they have been thinking beyond the current legacy Internet. Other large companies are clearly looking down the road and as you can see above Lucent is ready with serious products for serious companies. @@@@ http://www.aiag.org/anx/pilotend.html AIAG PUBLISHES ANX? RELEASE 1 DOCUMENT FOR ISPs; DEFINES CERTIFICATION PROCESS & REQUIREMENTS FOR ANX? SERVICE ... ISP Certification Process Opens Beginning Thursday, May 21, ISPs may apply for certification of their network environment to meet the business quality internet service specified by ANX Release 1. @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Some people feel that these new service models signal the end of the good old days of the Internet. This reminds me of people claiming that early computer store chains signalled the end of people experimenting with PCs. This was not the case, what happened was that the rest of the industry (boring PC usage) grew and it overshadowed the people building Altairs, IMSAIs, and Cromemco systems. It also helped to bring the price of floppy drives down to $18 from the $1,800 we paid for the some of the early drives. In my opinion, these new service models signal the beginning of an exciting time of expansion for the Internet and telecommunications in general. This growth will eventually bypass the legacy IPv4 Internet as we know it. People will have a choice whether to remain with the old-school legacy systems which they can operate as transport networks as long as someone is willing to pay to have some bits hauled, or people can switch and work on the new service models that are going to rapidly grow around the edges. There is a need for both types of people. Hopefully, people will be free to pursue either path. While it is clear that most of the people interested in NANOG fall into the legacy camp, I have a feeling that eventually some people will step out and try some new horizons. When you do, you might be surprised at how much is going on at the leading edge of those horizons... Jim Fleming Unir Corporation - http://www.Unir.net IS Coordinator for the AM Radio Station Registry - http://www.DOT.AM

1 0

industry filtering rules
by Lehrer, Neil 03 Jun '98

03 Jun '98

hi, sprintlink's filter policy for non sprintlink customers is shown below. do other large providers have similar policies? i am a sprintlink customer and am trying to understand how these policies are implemented in the industry. thanks. ip nums cidr RFC 1918 Reserved Addresses Disallow 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 0-126 /8 Allow no subnets of historical addresses that were not announced in July 1995 127-191 /8 Allow nothing longer than /16 (i.e., /17, /18, /19, etc.) 192-205 /8 Allow nothing longer than /24 (i.e., /25, /26, /27, etc.) 206-223 /8 Allow nothing longer than /19 (i.e., /20, /21, /22, etc.) 195 /8 Allow nothing longer than /19 (i.e., /20, /21, /22, etc.) 24 /8 Allow nothing longer than /19 (i.e., /20, /21, /22, etc.) *The principal change is that we used to disallow /19s in 206/8-223/8 and 195/8, and this was not; in line with the minimal allocation units performed by the three primary registries Regards +++++++++++++++++++++++++++++++++++++++ + Neil Lehrer + U.S. Information Agency + Networks and Systems Support Division + + voice 202 619-0903 + fax 202 619-3883 + internet nlehrer(a)usia.gov + + "oh what a tangled net we weave + when we seek to retrieve." + +++++++++++++++++++++++++++++++++++++++

1 0

RE: Sprint's New ION products (fwd)
by David Lesher 03 Jun '98

03 Jun '98

Tom Walton sez: > > The most troubling thing to me about the ION plan is that it > seems to revolve around the idea of using LEC local loops to > deliver service to home customers. The LECs are not going to > be enthusiastic about providing an unbundled loop to > facilitate being cut out of their long-distance termination > fees. This could be a very slow roll for Sprint. Count on SPRINT being their own CLEC; why would they give away the gravy? > This problem will not become acute until they begin > deploying residential service, as many/most business > customers (the initial targets) will be "on-net" with CLECS > who are already interconnected with Sprint. It might be that > Sprint is hoping/praying for regulatory/statutory > intercession before they try to penetrate the residential > market en masse. True. Sprint's legal muscle [irony; it's MCI that was oft-called "The law firm with the antenna on top" not Sprint] may help pry entry into COLO space in/near CO's, but that is far from a universal solution. What about SLC[tm-Lucent]'ed lines, real copper loops too long to be viable [know of several 40Kft ISDN loops], offices with no COLO space, etc. (And even when successful, that means a COLO cage in every CO in the country....) And *will* businesses want to go to all-metered calling? Outside of NYC, Chicago, Gnu Joisy, Califunny {and any I don't know of..}, most US business POTS is flat rate or per-call, not per minute|bit. So they'll split the difference; using Least Cost Routing to try and guess which way is better. Buy PBX stock, and count on the ILEC's fighting this tooth and nail, down to the last T-75 staple and pole spike. > I love the telecommunications business... Amem, Brother.... -- A host is a host from coast to coast.................wb8foz(a)nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433

2 1