- NANOG - lists.nanog.org

ADSL & iLEC
by Jonathan Arneault 04 Jun '98

04 Jun '98

I just read (http://www.internews.com/isp-news/1998/06/0301-bell.html) that Bell Atlantic is looking to finally roll out xDSL. However, not as a wholesale, unbundled service, but as an Internet service which will directly compete against ISPs. While I do believe that BA and the rest of the iLECs have the right to compete in their market, I don't think they should have the right to put private, unsubsidized businesses out of business by using their utility based advantages. Additionally, how is it that a "regulated monopoly" is able to transit service outside of the LATA (such as is required with Internet service)? IS this Bell's way of getting into LD, through packet switching? Does anyone know, now that BA has announced that they will provide ADSL internet services, if they provide a similar, tarriffed, unbundled xDSL service by which a local, regional or national ISP could provide a competitively priced service? How does a ten million dollar a year company serve in a market with a 10 billion dollar a year company? Is there a way for us "little guys" to compete against the behemoths? Has anyone had similar experiences with their primary iLEC (such as PACBell and US West)? Hoping for good news, Jonathan Arneault Director of Business Development CMA / INet Solutions Division 518.783.9003 x 253

4 3

Re: Attack/DoS
by John Fraizer 04 Jun '98

04 Jun '98

At 11:38 PM 6/3/98 -0400, Perry E. Metzger wrote: > >"Todd R. Stroup" writes: >> 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? > >What do you mean by an "attack"? Are you being flooded? Are the >packets somehow "interesting"? Without details the information is >useless. > >Port 0, btw, is not generally valid, and most proper TCP and UDP >implementations will just send an ICMP Unreachable back when they get >such a packet. > >Perry Perry, Here are some logs of slightly different format that show the same attack Todd writes about: Jun 3 17:02:47 eth0-core0 kernel: IP acct in eth0 UDP 199.199.125.28:53 209.115.17.67:53 L=57 S=0x00 I=47916 F=0x0000 T=49 Jun 3 17:02:47 eth0-core0 kernel: IP acct out eth2 UDP 199.199.125.28:53 209.115.17.67:53 L=57 S=0x00 I=47916 F=0x0000 T=48 Jun 3 17:02:47 eth0-core0 kernel: IP acct out eth0 ICMP/3 209.115.17.65 199.199.125.28 L=119 S=0xC0 I=63767 F=0x0000 T=64 Jun 3 17:02:47 eth0-core0 kernel: IP acct in eth0 UDP 165.113.1.73:53 209.115.17.66:53 L=56 S=0x00 I=25895 F=0x0000 T=57 Jun 3 17:02:47 eth0-core0 kernel: IP acct out eth2 UDP 165.113.1.73:53 209.115.17.66:53 L=56 S=0x00 I=25895 F=0x0000 T=56 Jun 3 17:02:47 eth0-core0 kernel: IP acct out eth0 ICMP/3 209.115.17.65 165.113.1.73 L=118 S=0xC0 I=63769 F=0x0000 T=64 Jun 3 17:02:48 eth0-core0 kernel: IP acct in eth0 UDP 166.93.1.3:63098 209.115.17.66:53 L=56 S=0x00 I=44767 F=0x0040 T=245 Jun 3 17:02:48 eth0-core0 kernel: IP acct out eth2 UDP 166.93.1.3:63098 209.115.17.66:53 L=56 S=0x00 I=44767 F=0x0040 T=244 Jun 3 17:02:48 eth0-core0 kernel: IP acct out eth0 ICMP/3 209.115.17.65 166.93.1.3 L=118 S=0xC0 I=63770 F=0x0000 T=64 Jun 3 17:02:48 eth0-core0 kernel: IP acct in eth0 UDP 198.81.19.238:4569 209.115.17.66:53 L=59 S=0x00 I=34977 F=0x0000 T=20 Jun 3 17:02:48 eth0-core0 kernel: IP acct out eth2 UDP 198.81.19.238:4569 209.115.17.66:53 L=59 S=0x00 I=34977 F=0x0000 T=19 Jun 3 17:02:48 eth0-core0 kernel: IP acct out eth0 ICMP/3 209.115.17.65 198.81.19.238 L=121 S=0xC0 I=63771 F=0x0000 T=64 Jun 3 17:02:48 eth0-core0 kernel: IP acct in eth0 UDP 128.112.129.15:56224 209.115.17.66:53 L=58 S=0x00 I=50842 F=0x0040 T=247 Jun 3 17:02:48 eth0-core0 kernel: IP acct out eth2 UDP 128.112.129.15:56224 209.115.17.66:53 L=58 S=0x00 I=50842 F=0x0040 T=246 Jun 3 17:02:48 eth0-core0 kernel: IP acct out eth0 ICMP/3 209.115.17.65 128.112.129.15 L=120 S=0xC0 I=63772 F=0x0000 T=64 Jun 3 17:02:48 eth0-core0 kernel: IP acct in eth0 UDP 158.152.1.81:53 209.115.17.67:53 L=56 S=0x00 I=21310 F=0x0000 T=53 Jun 3 17:02:48 eth0-core0 kernel: IP acct out eth2 UDP 158.152.1.81:53 209.115.17.67:53 L=56 S=0x00 I=21310 F=0x0000 T=52 The thing that makes it "interesting" is the fact that most implementations DO send an ICMP unreach back. The ICMP Unreach traffic alone generated in the neighborhood of 1.7Mb before they routed the netblock in question to a loopback interface on the 7507. The attacker was sending less that 300Kb of traffic and consuming 2Mb. ------- 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: Sprint's New ION products
by Pete Farmer 04 Jun '98

04 Jun '98

Nathan Stratton [mailto:nathan@robotics.net] wrote: >Right now most of the move to voice over packet/cell networks is >because people want to avoid termination and USF charges. The pace will >accelerate even more now that port density and port cost is approaching >that of TDM. For Sprint simply to use ATM in their core does not let them get around termination and USF. Only if they use an access mechanism other than standard PSTN do they get around these charges. Unfortunately, it's rather difficult to discern what the access mechanism will be for their 'ION' psudo-offering. Pete ______________________________________________________________________ Peter J. Farmer E-mail: pfarmer(a)strategies-u.com Strategies Unlimited Voice: +1 650 941 3438 201 San Antonio Circle, Suite 205 Fax: +1 650 941 5120 Mountain View, CA 94040 WWW: http://www.strategies-u.com

3 2

Re: PPP over Ethernet?
by woody＠zocalo.net 04 Jun '98

04 Jun '98

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. The idea is neither "highly bogus" nor used in association with 10Base-T cross-over cables. It's used to tunnel ATCP, IPCP, IPXCP, et cetera over IP. -Bill Woodcock

2 1

111 8th Ave - NYC
by Jonathan Arneault 04 Jun '98

04 Jun '98

Is anyone else co-located in the MFS node in this building? If so, would you be interested in peering? I've got a big honking' router and an ATM switch with only one private peer into them, and a FDDI - MAE connection that isn't currently talking to anyone. If so, e-me off line. Thanks, Jonathan Arneault Director of Business Development CMA / INet Solutions Division 518.783.9003 x 253

1 0

RE: flat vs non-flat charging
by Mike Trest (In Japan) 04 Jun '98

04 Jun '98

Bill, Jerry, Steve, et. al. I don't think I can over stress that the operational issue is not what the technology can support but what patterns the commercial fiber providers of the future will adopt. IMHO, operating separate channels of a WDM drop-and-insert will is no different from operating separate SONET/SDH drop-and-insert. Furthermore, the operational comparisions of multiple point-to-point links with a staticstically multiplexed link has been explored extensively on this list. However, can one *reasonably* expect that the owners of fiber in the ground to allow dark fiber access for the average (or even larger-than-average) network operator. Will the owners of the fiber allow the network operator to manipulate and re-structure his own drop-and-insert revisions over their dark fiber network? IMHO, the best you can reasonably expect is a dedicated port at both ends of a point-to-point link. If the price is right, you can expect to buy as many of these point-to-point links as you can afford. But physical control and network re-structuring will remain in the hands of the fiber plant owner-operator. Perhaps a network operator can plant dark fiber in a campus or regional deployment for extended WDM use. But I suspect the budget would need to be a lot larger (or you would need a really sweet political deal) to gain national access to dark fiber to implement and control the OADM or WDM equipment. The answers to Jerry's original question and the probability of a network operator truly controlling his own WDM network will come from future commercial practice of the fiber owners. ..mike.. At 09:31 AM 6/1/98 -0400, Bill St. Arnaud wrote: >Steven: > >New municipal and campus WDM gear from Cambrian, Ciena and Nortel makes it >a lot easier and cheaper to deliver data services over separate WDM channels >than to MUX them into one SONET or ATM service. More importantly becuase >the service is data transparent, each customer can manage their own WDM >channel independent of the other channels. Try doing that with SONET or >ATM!! > >Check out www.cambrian.com for more details. > >However, I agree with you that if you have spare fiber it is cheaper just to >light up the fiber without WDM or SONET. Packet Engines claims they can >drive 22km of dark fiber with no additional equipment or repeaters > >Bill > >------------------------------------------- >Bill St Arnaud >Director Network Projects >CANARIE >bill.st.arnaud(a)canarie.ca >http://www.canarie.ca/bstarn > > > > > > > >> -----Original Message----- >> From: steven hessing [mailto:stevenh@inet.unisource.nl] >> Sent: Friday, May 29, 1998 5:08 PM >> To: Bill St. Arnaud >> Cc: Jerry Scharf; nanog(a)merit.edu >> Subject: Re: flat vs non-flat charging >> >> >> Bill, >> >> WDM may lower the price per Mbit/s considerably, however many of these >> Mbit/s will have to be sold to be profitable as a service. Connecting >> two routers using dedicated WDM gear and 5km of fiber to send over >> 155Mbit/s traffic is more expensive then connecting the two routers >> directly using 5km of fiber, even though the first solution would >> give you much more available capacity. >> >> If multiple services need to run over the same fiber then existing >> ATM or SDH networks are well capable of multiplexing these services >> over one fiber at often lower costs then installing new WDM gear. >> >> There where there is a fiber shortage because there is no further >> room for service multiplexing or there is a shortage of capacity, WDM >> will be a very good solution. It is much cheaper then installing new >> fiber. >> >> WDM is therefor very real for connecting TEX's together and for >> connecting LEX's to TEX's. I expect that WDM needs OADMs or other >> up and coming technology for SDH or WDM to become cost-effective for >> the MAN/local loop. >> >> To return to the original topic, for the forseeable future (3-5 years?) >> bandwidth will remain scarce and therefor expensive. The prices per >> MBit/s will drop shortply but this will be compensated in a large >> increase in demand. An distance-based pricing scheme could therefor >> be an appropriate solution. Personally, I don't think it will happen. >> >> -- Steven >> >> PS: if anyone can prove me wrong with some numbers, please show me :) >> I've been working on cost calculations for bandwidth for the last >> couple of weeks. >> >> In your mail from 29-5-1998 you write: >> > Jerry: >> > >> > You are absolutely right. I have pulled together some numbers on public >> > pricing for long haul WDM (including right of way) showing that >> if you ou= >> > t >> > IP over WDM the cost of bandwidth drops by a factor of 100 to 1000. On >> > local loops it is more dramatic - with new WDM technology from companies >> > like Cambrian and Ciena gigabit ethernet or OC-48 SONET on a >> 5km local lo= >> > op >> > should cost about $2500 per YEAR. >> > >> > A number of our regional networks have already pulled their own >> fiber and >> > our realizing these costs in the real world. >> > >> > Fibre - $4 to $6 per meter >> > 20 year economic life and 10% maintenance per year >> > 48 strands NZDSF >> > Right of way $0 -$10 per meter per year (up to $200 per meter >> on long hau= >> > l) >> > but >> > common solution is to offer right way owner free use of a couple of >> > strands instead of paying cash >> > Installation $25 per meter underground in cities >> > $6 per meter on poles (maintenance costs 20% year) >> > Twenty year amortized cost with 10% cost of money plus maintenance plus >> > right of way costs at $10/year per meter >> > $17 per year per meter for 48 strands >> > $1.50 per year per meter per strand >> > $.50 per year per meter per wavelength >> > A 5 km OC-48 local loop should cost about $2500/year >> > >> > >> > Bill >> > >> > ------------------------------------------- >> > Bill St Arnaud >> > Director Network Projects >> > CANARIE >> > bill.st.arnaud(a)canarie.ca >> > http://www.canarie.ca/bstarn >> > >> > =A0 >> > >> > =A0 >> > >> > >> > >> > > -----Original Message----- >> > > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of >> > > Jerry Scharf >> > > Sent: Friday, May 29, 1998 12:07 PM >> > > To: nanog(a)merit.edu >> > > Subject: flat vs non-flat charging >> > > >> > > >> > > I think the idea of distance charging is going away in many >> > > cases. With WDM, >> > > the cost of the WDM and SONET eqiupment on the ends of a fully >> > > populated 32 >> > > channel per fiber, 144 strand pull vastly outweight end-to-end >> > > fiber costs of >> > > anything pulled through the ground. When you add routers and the >> > > like on top >> > > of that, the distance issue really goes away and it becomes >> on of netwo= >> > rk >> > > topology hops. Can anyone with figures for new >> intercontinental pulls s= >> > ay >> > > whether this is true there as well (project oxygen marketing >> claims thi= >> > s, >> > > but...)? >> > > >> > > Using archaic telephone pricing models to argue cost of >> providing bulk = >> > IP >> > > services is just not right. >> > > >> > > jerry >> > > >> > > >> > >> >

2 1

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 04 Jun '98

04 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