- Test - lists.nanog.org

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 26 Aug '96

26 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 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. (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 25 Aug '96

25 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

Sprint and Multi-Homing
by William Allen Simpson 24 Aug '96

24 Aug '96

> From: Sean Doran <smd(a)chops.icp.net> > Date: 17 Aug 1996 17:29:52 -0400 > In order to enforce that contract, we have installed > inbound prefix filters to ignore all subnets of our PA > CIDR blocks that are announced by our peers at exchange > points. > Gack! So that's what happened to my network last Sunday! Even though the provider from which we get our service claims to be multi-homed with Sprint and MCI, when the Sprint link was down, no traffic was flowing through MCI. OK. I'll be recommending that the Sprint contract not be renewed. And in the $10M RFP that just went out for one of my clients, I'll specify during my bid technical review in September that any bids that include SprintLink will not be accepted. Enough is enough. WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson(a)MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

3 2

nanog mail looping.
by Forrest W. Christian 24 Aug '96

24 Aug '96

It looks like we've got a nanog mail loop going on here. Haven't seen one of these in quite a while. In any case, I have included the full headers below, and cc'd the relevant postmasters at (apparently) netscape and mcom.com -forrestc(a)imach.com ---------- Forwarded message ---------- Return-Path: owner-nanog(a)merit.edu Received: from merit.edu (merit.edu [35.1.1.42]) by IMgate.iMach.com (8.6.12/8.6.12) with ESMTP id VAA20161 for <forrestc(a)imach.com>; Fri, 23 Aug 1996 21:03:03 -0600 Received: from localhost (daemon@localhost) by merit.edu (8.7.5/merit-2.0) with SMTP id WAA25979; Fri, 23 Aug 1996 22:37:18 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 23 Aug 1996 22:37:15 -0400 Received: (from daemon@localhost) by merit.edu (8.7.5/merit-2.0) id WAA25965 for nanog-outgoing; Fri, 23 Aug 1996 22:37:15 -0400 (EDT) Received: from littlewing.mcom.com (h-205-217-255-33.netscape.com [205.217.255.33]) by merit.edu (8.7.5/merit-2.0) with ESMTP id WAA25960 for <nanog(a)merit.edu>; Fri, 23 Aug 1996 22:37:12 -0400 (EDT) Received: (from root@localhost) by littlewing.mcom.com (8.7.3/8.7.3) id TAA11467; Fri, 23 Aug 1996 19:39:35 -0700 (PDT) Received: from maleman.mcom.com (maleman.mcom.com [198.93.92.3]) by tera.mcom.com (8.6.12/8.6.9) with ESMTP id WAA10758 for <mcom.list.nanog(a)tera.mcom.com>; Thu, 22 Aug 1996 22:36:06 -0700 Received: from ns.netscape.com (ns.netscape.com.mcom.com [198.95.251.10]) by maleman.mcom.com (8.6.9/8.6.9) with ESMTP id WAA05229 for <list-nanog(a)netscape.com>; Thu, 22 Aug 1996 22:32:52 -0700 Received: from merit.edu (merit.edu [35.1.1.42]) by ns.netscape.com (8.7.3/8.7.3) with ESMTP id WAA27127 for <list-nanog(a)netscape.com>; Thu, 22 Aug 1996 22:31:57 -0700 (PDT) Received: from localhost (daemon@localhost) by merit.edu (8.7.5/merit-2.0) with SMTP id BAA02728; Fri, 23 Aug 1996 01:26:26 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 23 Aug 1996 01:25:34 -0400 Received: (from daemon@localhost) by merit.edu (8.7.5/merit-2.0) id BAA02706 for nanog-outgoing; Fri, 23 Aug 1996 01:25:33 -0400 (EDT) Received: from gw.quake.net (gw.quake.net [140.174.86.11]) by merit.edu (8.7.5/merit-2.0) with ESMTP id BAA02701 for <nanog(a)merit.edu>; Fri, 23 Aug 1996 01:25:28 -0400 (EDT) Received: from quest.quake.net (avg(a)l24.ip.Quake.Net [198.68.224.24]) by gw.quake.net (8.7.4/8.7.4) with ESMTP id WAA02853; Thu, 22 Aug 1996 22:24:56 -0700 (PDT) Received: (from avg@localhost) by quest.quake.net (8.6.9/8.6.9) id WAA02453; Thu, 22 Aug 1996 22:22:03 -0700 Date: Thu, 22 Aug 1996 22:22:03 -0700 From: Vadim Antonov <avg(a)quake.net> Message-Id: <199608230522.WAA02453(a)quest.quake.net> To: curtis(a)ans.net, nanog(a)merit.edu Subject: Re: Access to the Internic Blocked Sender: owner-nanog(a)merit.edu Curtis Villamizar wrote: > Not at all. LSRR is a nice tool to mount practically untraceable > flooding attack (hint -- just forge source address and spread > intermediate points evenly across the network). Shutting you > down may be exactly what the attacker wants. >Oh come on. Like they're not going to get caught stuffing an entire >T1 with LSRR packets. Face it. You're grabbing at straws. Ugh. To kill multiple DS-3s you don't even need a full T-1 (you need one LS address for every loop), and you can kill multiple DS-3s and an IXP to boot, with the single stream of bogons routed in a loop with many hops. And there's a lot of big name Us with DS-3 connectivity and no security whatsoever. Now, throw in randomized first hop and forged source address, and i'll wish you good luck catching the perpetrator. A careful attacker would also randomize destinations and make it to look like regular TCP traffic. (And did anybody think of IP stacks which reverse the source routes, just to make things funnier). >Besides the fact that with your suggestion of traceroute using ICMP >echo requests they'd just send a T1s worth of ICMP echo requests with >LSRR and accomplish the same thing. Ok, with only one intermediate point allowed. _That_ should take care of all diagnostic needs. >LSRR is just too useful for diagnosing network problems to shut down >on a backbone. I sometimes wonder if the threat of hackers is exaggregated. They certainly missed a nice opportunity to crash the Internet with TCP resets on iBGPs. Now nobody cares about the creative potential of LSRR-anonymized denial of service attacks. They must be stupid or something. Should i write a backbone-crasher and post it to USENET just to make a point about LSRRs? Note that a provider which won't shut LSRR will be the threat to others... --vadim --WAA10774.840778792/tera.mcom.com--

1 0

Re: *** MAKE SPAM@INTERRAMP.COM DIE FAST!!! *** (fwd)
by Robert Sanders 24 Aug '96

24 Aug '96

lists(a)reflections.mindspring.com writes: > The transition has not yet occurred; we will start transferring customers > come the beginning of September. In addition, we will not be offering free demo accounts. The ease with which spammers can acquire throwaway PSI accounts, coupled with PSI's inability to trace a given post back to its source, has made PSI a spammer's dream. It's not a matter of apathy, but of impotence. Those in charge of curtailing net abuse had few of the facilities necessary to do so. We will require NNTP authentication for news posting, and will immediately take action against accounts whose postings violate our terms of service (http://www.mindspring.com/aboutms/policy.html) -- Robert

3 2