- Test - lists.nanog.org

Re: So who the heck is "Wolfcon,"
by Bill Woodcock 26 Aug '96

26 Aug '96

LDDS WorldCom? Could be... I got this second-hand from a non-techie who was listening to the noon news on NPR, so I have no idea what he _actually_ heard. :-) That would at least make sense, even if it's not particularly auspicious. -Bill ________________________________________________________________________________ bill woodcock woody(a)zocalo.net woody(a)applelink.apple.com user(a)host.domain.com

3 2

Re: So who the heck is "Wolfcon,"
by Bradley Dunn 26 Aug '96

26 Aug '96

Well, the value of the deal has gone down to about $12.4 billion since "WorldCom"'s stock has taken a tumble today, down almost 14%. The deal is just a stock swap, so they really don't have that much cash. But the new MFS WorldCom is said to rival the baby bells in market cap, and it will be bigger than MCI. The interesting part of it all is that now there is one company that can provide the local loop, the inter-exchange circuit, and the Internet port. Bradley Dunn Harbor Communications ---------- > From: Bill Woodcock <woody(a)zocalo.net> > To: nanog(a)merit.edu > Subject: So who the heck is "Wolfcon," > Date: Monday, August 26, 1996 4:24 PM > > > ...and where did they get 14.1 billion dollars? Does this mean that > it's going to be even harder to deal with MFS? Humpf. > > -Bill > > ____________________________________________________________________________ ____ > bill woodcock woody(a)zocalo.net woody(a)applelink.apple.com user(a)host.domain.com

1 0

Re: So who the heck is "Wolfcon,"
by Scott Bradner 26 Aug '96

26 Aug '96

> unless you're referring to 14 billion pounds of SciFi fans. oops - make that WorldCom

1 0

Re: Access to the Internic Blocked
by Daniel W. McRobb 26 Aug '96

26 Aug '96

> Curtis Villamizar <curtis(a)ans.net> wrote: > > >We have traced back such "clever" denial of service attacks before. > >Within the last 6 months even. > > >Have you forgotten that we log and keep track of source/destination > >pairs. > > I sincerely wish you good luck doing that at OC-12. If you know > a magic technology which can do that please let me know. > Doing that at 10 kpps is not going to be a solution any time soon. You're kidding, right? 10kpps has been doable (and done) for years. Did you forget a zero or two? The vBNS folks are about to release an OC-3 header sniffer that runs on a Pentium box. Rumor has it that it'll handle OC-12 as well. There's a presentation of it on the USENIX agenda. > I would also wish you luck with logging SA/DA pairs at places like > .ICP.NET. where source/destination matrix is about 1-2 millon > entries long. 1-2 million is not much. Even in the NSFNET days, I worked w/ 5-million-cell net matrices. All it takes is memory and some CPU. > >It is really easy for us to spot in incoming path with a set > >of sources that were never coming from that direction and start > >working backwards. > > Yeah? Over six backbones? To the edge of our backbone, absolutely. In someone else's backbone? Of course not. > >Other respectable providers cooperate. Nearnet > >for example flew out a person and workstation to track an attack > >coming through them. > > Cool. Now, if such a bogon generator becomes someting easily > accessible to every newbie (as it is bound to become, sooner or > later), that certainly will help. > > >We have Unix boxes deployed in every POP, even > >with our new backbone. These watch over the FDDI rings. > > That certainly helps to people who already have to use FDDI switches. We're not sniffing a shared FDDI ring w/ these UNIX boxes. They get data from the routers. It doesn't matter what kind of media the packet traversed to hit the router (switched FDDI included). Daniel ~~~~~~

2 1

Re: Customer AS
by Sean Donelan 26 Aug '96

26 Aug '96

>Frankly, where there is significant competition and little >or no loss-leading and cross-subsidy, the Internet >is precisely as reliable as people are willing to pay for. This is likely true. It is also likely rational producers won't use resources for something when they could make more money with the resources elsewhere. If you look a little more closely I suspect circuit-switched and packet-switched networks end up with nearly the same value for the lines. A bigger problem might be trying to convince a high-muckty-muck manager with many years of voice telephone circuit experience that there is more than one way to calculate the value of a line. Depending how you account for interconnect costs, a provider selling $2700/month T1 packet-switched connections with a 23:1 bandwidth overbooking ratio generates the same revenue as analog voice circuits at 10cents/minute - 4cents/minute interconnect fees. As most Internet providers say, not including local loop. If you want a lower bandwidth overbooking ratio, you pay more. If you don't mind a higher bandwith overbooking, you might pay less. This explains the goodput, or throughput of a network, not necessarily the reliability of a network. If gross revenue was the only determinate of network reliablity, at $2700/month/T1 and 23:1 overbooking I should get 67Kbps end to end with the 99.93% reliabilty of the voice network. Well, there was a few rounding errors long the way, but 67Kbps is darn close to a DS0 at 6cents/minute. Bad news for the Internet telephony folks, there still ain't no such thing as a free lunch. If I'm paying for voice telephone level quality, am I getting it? Yes, I have just proven why firetrucks are red :-). With enough numbers, you can prove almost anything. A different question is how to account for risk. A DS3 voice line failure may cost the carrier $4,032/hour (10cents/minute) in lost revenue opportunity. But the customer has no monetary risk with post-paid calls. If a voice call isn't completed the customer pays nothing. On the other hand a DS3 data line failure may cost the carrier nothing in lost revenue opportunity if the customers pay a fixed access fee. A gross generalization is fixed access fees tend to encourage providers to run their networks as close to the edge as possible to maximize profits. This isn't a problem *if* consumers understand the risks involved. I think the risk transfer from provider to network customer accounts for more of the Internet reliability problems than just gross revenue (or the lack of revenue). TCP/IP and the Internet puts the onenous on the end-networks or end-systems to maintain a reliable connection over an unreliable network. That was the plan, wasn't it? Oops, what's missing. If you have an unreliable network in the middle, the end networks need a few (2,3,4?) different connections to other networks. The Internet isn't supposed to work like the voice telephone system, and connections to the Internet shouldn't be purchased like connections to the telephone system. The Internet is a risky system, and should be purchased like a risky system. When pension plan administrators choose portfolio managers to handle the pension investments, the administrators generally split the pension plan assets among three managers with different investment styles. Its called risk diversification. Internet Network Operators (to relate this slightly to NANOG) need to look at diversifying their Internet connections between providers. The key to making the Internet work for you is learning how to manage risk. Your stock broker wouldn't advise putting all your retirement money in a single telecommunications company stock, why would your Internet "consultant" advise buying all your Internet connections from one company? -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

2 1

Re: Access to the Internic Blocked
by Daniel W. McRobb 26 Aug '96

26 Aug '96

> Daniel W. McRobb <dwm(a)ans.net> wrote: > > > Doing that at 10 kpps is not going to be a solution any time soon. > > >You're kidding, right? 10kpps has been doable (and done) for years. > >Did you forget a zero or two? > > Hm. The existing boxes which can do 100kpps can't do accounting at that > speed. Not in the real life. The NSSes did it at 20kpps per interface. We have big customers w/ T3 connectivity that run accounting on their 7XXX boxes. Sure, it beats up the Cisco box. But it's doable. Besides, who mentioned IP accounting? That's not the optimal way to do things (and certainly not how I'd do it). > (Where have you seen a 1Mpps box which actually _works_?) So you did leave out some zeros? > >The vBNS folks are about to release an OC-3 header sniffer that runs on > >a Pentium box. Rumor has it that it'll handle OC-12 as well. There's a > >presentation of it on the USENIX agenda. > > Sniffing and logging are two very different things. You don't have to log every packet. You log flows or you just increment net matrix counters and once in a while dump the whole table. It's not rocket science, and it's not beyond reach. It's been done on the NSSes and can be done on the Ciscos. Maybe I'll talk about it at the NANOG meeting. > > I would also wish you luck with logging SA/DA pairs at places like > > .ICP.NET. where source/destination matrix is about 1-2 millon > > entries long. > > >1-2 million is not much. Even in the NSFNET days, I worked w/ > >5-million-cell net matrices. All it takes is memory and some CPU. > > 1-2 _simultaneoulsy_, not over period of time. The 1-hr matrix > would be two orders of magnitude bigger. A typical 1 hour matrix is considerably smaller. Even a core router who carries 40,000 routes will not see anywhere near 40,000 * 40,000 cells in a one hour period, or even 2 million cells. Not in my experience. Even the NAP and MAE routers where I've collected this data have seen net matrices only on the order of (10^3) to (10^5) for a one hour period. The number of cell entries is not equal to the number of routes squared. It doesn't happen. If you collect this data, you'll find the net matrix in a reasonable collection period (say 15 minutes) is typically 5-7 orders of magnitude smaller than the routing table squared, even for routers that are well-connected and very busy. > Anyway, it does not make any difference, as the box capable of > logging at some speed N is going to cost about the same as a > router of the same speed N (or more). I'm not sure logging worth it. > > >We're not sniffing a shared FDDI ring w/ these UNIX boxes. They get > >data from the routers. > > What kind of routers? NSSes? You can't get that for ciscos, > sorree... conf t ip flow-export a.b.c.d zzzz int XXX/Y ip route-cache flow Where a.b.c.d is a reasonable workstation w/ a decent amount of memory. Nowehere near as costly as (say) a Cisco 7XXX that's exporting the flows. The router does the hard part. The flow-export data still needs some work, but Cisco has been working on it (I think we're up to version 5 of the flow-export PDU in the stuff I'm using), and I've been writing code against it. And maybe one day we'll actually be able to run this on core routers (well, not ANS since we have a different vendor's box in the core, but others). The net matrix (and archiving all of it) gives you enough data to do trend analysis and other things (including searching for bogons from some time past). For the case of the Cisco stuff, when you need more detail from the flow-export, you turn a knob in your code on the workstation. You don't have to do anything on the router. To date I haven't really had a need for host-level granularity, but it's doable (the code I've been working on will have a knob for enabling host-level granularity to find the needles in the haystack when you're trying to spot cracker traffic from a particular source and/or to a particular destination). Even if your router is expiring 20,000 flows per second, it only comes out to about 667 packets per second to the workstation, which is pretty low even for older workstations with fairly weak CPUs by modern standards. An Alpha can handle it w/o even breaking a sweat. Daniel ~~~~~~

1 0

Traceroute Servers
by Robert Bowman 25 Aug '96

25 Aug '96

On a much less vibrant note... I've put together the most extensive list of traceroute server links that I have seen. Hopefully it will be useful and kept up to date by myself. http://www.exodus.net/noc/utilities/traceroute.html sorted by upstream providers (as far as I could see them) for the U.S. sorted by country for dem foreigners. Rob

1 0

Re: Access to the Internic Blocked
by Vadim Antonov 25 Aug '96

25 Aug '96

Daniel W. McRobb <dwm(a)ans.net> wrote: > Doing that at 10 kpps is not going to be a solution any time soon. >You're kidding, right? 10kpps has been doable (and done) for years. >Did you forget a zero or two? Hm. The existing boxes which can do 100kpps can't do accounting at that speed. Not in the real life. (Where have you seen a 1Mpps box which actually _works_?) >The vBNS folks are about to release an OC-3 header sniffer that runs on >a Pentium box. Rumor has it that it'll handle OC-12 as well. There's a >presentation of it on the USENIX agenda. Sniffing and logging are two very different things. > I would also wish you luck with logging SA/DA pairs at places like > .ICP.NET. where source/destination matrix is about 1-2 millon > entries long. >1-2 million is not much. Even in the NSFNET days, I worked w/ >5-million-cell net matrices. All it takes is memory and some CPU. 1-2 _simultaneoulsy_, not over period of time. The 1-hr matrix would be two orders of magnitude bigger. Anyway, it does not make any difference, as the box capable of logging at some speed N is going to cost about the same as a router of the same speed N (or more). I'm not sure logging worth it. >We're not sniffing a shared FDDI ring w/ these UNIX boxes. They get >data from the routers. What kind of routers? NSSes? You can't get that for ciscos, sorree... --vadim

1 0

Re: Access to the Internic Blocked
by Hank Nussbacher 25 Aug '96

25 Aug '96

On Wed, 21 Aug 1996 08:16:59 -0700 (PDT) Michael Dillon wrote: >One thing that would help diagnose the true source of the problem with >less human interaction required (avoiding voicemail and all that) would be >wider public access to traceroutes beginning at key sites. There is a >group of ISP's who make CGI-based traceroutes available from their sites >at http://amazing.netaxs.com/internet/club-traceroute.html We maintain a page that has major sites who run traceroute and who they run thru: http://www.ibm.net.il/traceroute We have sites for Sprintlink, UUnet/Alternet, PSI, ANS, IBM, MCI, Nysernet. Suggestions for additions are welcome. >Michael Dillon - ISP & Internet Consulting >Memra Software Inc. - Fax: +1-604-546-3049 >http://www.memra.com - E-mail: michael(a)memra.com > Hank

1 0

Re: Access to the Internic Blocked
by Sean Doran 24 Aug '96

24 Aug '96

| We maintain a page that has major sites who run traceroute and who they run | thru: http://www.ibm.net.il/traceroute Hm, this is actually pretty neat. I don't suppose those of you partcipating in this would consider running Vern Paxson's software, too? Sean.

1 0