- Test - lists.nanog.org

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

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

24 Aug '96

Curtis wrote: >I've said many times that if security in your network is weak enough >that you need to worry about LSRR packets you need to worry about >security in your network. 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. (LSRR attacks against service providers are particlularly bad -- just imagine somebody flooding you at T-1 speed and bouncing packets back and forth two dozen times. Poof -- here goes the T-3 :) There are particularly nasty man-in-the-middle attacks (which defeat one-time-password login authentication, like that) if you can combine LSRR with bogus routing. >The minute someone unpacks a Sun workstation, configures an IP address >and sticks it on the ethernet without installing the security patches >and doing the administrative work needed to secure the machine, if you >had a small hole in your security with LSRR, you now have a gaping >hole in your security. If you are relying on blocking LSRR, your >security is a weak as the most peerly administered machine on your >network. A real bad thing if you are constantly hiring. I never argued that blocking LSRR plugs all security holes. However it is one thing _not_ used in normal operations; and everything not used _must_ be shut down by a prudent security. And, again, there are several LSRR-based attacks. >Even so, if anywhere, where you want LSRR turned off is the border >router(s) in front of the machines used for operations, network >management, etc. >Obviously you want your network to be secure even if >LSRR was enabled for the reason I cited above. Security Rule #1: You're never secure. Turning LSRR off doesn't particularly hurt connectivity, and is cheap. It's a way to _improve_ security. --vadim

3 3

new rtty released (V3.2) -- console server software for UNIX systems
by Paul A Vixie 23 Aug '96

23 Aug '96

------- Blind-Carbon-Copy to: nobody(a)vix.com reply-to: paul(a)vix.com Subject: new rtty released (V3.2) -- console server software for UNIX systems Date: Fri, 23 Aug 1996 15:29:41 -0700 From: Paul A Vixie <vixie(a)wisdom.home.vix.com> FTP Path <URL:ftp://ftp.vix.com/pub/vixie/rtty-3.2.tar.gz> (24940 bytes) Credits This work has been paid for by Digital Equipment Corporation, Vixie Enterprises, and the Internet Software Consortium. /* Copyright (c) 1996 by Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any * purpose with or without fee is hereby granted, provided that the above * copyright notice and this permission notice appear in all copies. * * THE SOFTWARE IS PROVIDED "AS IS" AND INTERNET SOFTWARE CONSORTIUM DISCLAIMS * ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL INTERNET SOFTWARE * CONSORTIUM BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL * DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR * PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS * ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS * SOFTWARE. */ Introduction Rtty is "remote tty" (not radioteletype). You run a server per port and then connect to that server from any number of "tip"/"cu"-like clients. I wrote it for our console concentrator, but there's no reason other than performance why you couldn't use it to drive modems, printers, prom programmers, and so on. When you connect to the server from more than one client, all clients will see the same session and all clients can type at and see output from whatever device is attached to the tty port. Typing at a device when someone else is also typing at that device is confusing and more than a little bit creepy. You will need a BSD-derived UNIX to use this, and you will need "termios" (the POSIX terminal interface). (If "man termios" doesn't say something informative and useful, you are probably hosed.) Ultrix and SunOS and AT&T V.4 all have what you need. AT&T V.3 and non-Tahoe/Reno BSD are both lacking one thing or another. Details The server can be told to keep a log file. This log file will record all data in or out of the tty port; that is, data that comes from the tty port will be logged, and data that is typed at (and therefore sent to) the tty port from any client will be logged. There are no special markers in the log file to tell you which data came from which source; the data is all just interleaved in the order it was received by the server. Note that line terminators in the log file will be "physical" meaning probably \r\n rather than the normal UNIX \n. It depends on the device on the other end of the tty port, but \r\n is pretty common. We watch our log files with daemons that do roughly what "tail -f" does except they scan for things like "file table full" or "out of inodes" or "panic" -- you know, things that computers say when they are unhappy. None of our scanning software is included in this release of rtty, but you can write your own. Note that the protocol used between the server and client is mostly implemented in a separate module of this source directory; if you want to connect to the server in real time and scan the output direcly instead of tailing the log file, that's an option. (You would most especially want to do it this way if you aren't using any log files.) UNIX-domain sockets are the normal way that clients connect to the server. Both client and server support internet-domain sockets (we'll let you figure out "how" by reading the sources), there is absolutely no security in rtty, and opening up our tty ports to the local internet with no access control has seemed like a bad idea (especially since they are the main consoles of our Internet gateway computers). So we don't use this feature. (Win promised to Kerberize this stuff for me but then he got busy.) Other Notes Since there's no documentation, there's no harm in telling you that the "console" script just runs "rtty" with some obscure arguments to grease its skids. While in "rtty", a "~" after a carriage return (\r or 0x0D) is magic; "~?" will explain the magic to you somewhat tersely. The source code will explain it in more detail. Have fun. Drop me a note if you find this useful. Definitely drop me a note if you find a bug or add a feature. Paul Vixie <paul(a)vix.com> ------- End of Blind-Carbon-Copy

1 0

Re: NANOG Registration
by Brett D. Watson 23 Aug '96

23 Aug '96

ok, so the only confusion is with me reading mail out of order. sorry folks. -brett > On Fri, 23 Aug 1996, Brett D. Watson wrote: > > > i just went back to redo the web form (since i was one that tried using a > > non-visa/mastercard) and note that the button for credit card selection lists > > american express as an option. you should probably remove that to avoid any > > more confusion. > > As Pam stated in her last message American Express is now a option. > > Nathan Stratton CEO, NetRail, Inc. Tracking the future today! > --------------------------------------------------------------------------- > Phone (703)524-4800 NetRail, Inc. > Fax (703)534-5033 2007 N. 15 St. Suite 5 > Email sales(a)netrail.net Arlington, Va. 22201 > WWW http://www.netrail.net/ Access: (703) 524-4802 guest > --------------------------------------------------------------------------- > "Therefore do not worry about tomorrow, for tomorrow will worry about > itself. Each day has enough trouble of its own." Matthew 6:34 > >

1 0

Re: Customer AS
by matthew＠scruz.net 23 Aug '96

23 Aug '96

Original message <m0uscvd-000F25C(a)roam.psg.com> From: randy(a)psg.com (Randy Bush) Date: Aug 19, 15:36 Subject: Re: Customer AS > > >> just what i always wanted, two connections to a broken provider. you > >> must be kidding. > > I guess this brings to mind the question: Why would you want *any* > > connections to a broken provider? > > all providers break. >-- End of excerpt from Randy Bush Agreed. That can't be stressed enough. *ALL* providers break. Many of them choose different days and times to do so, and multihoming to different providers causes a huge increase in total reliability as a result. Speaking of broken providers, AGIS just mailed me and said that Sprint is "broken" today, and so they've decided to filter out Sprint routes until it gets fixed. Anyone know the _real_ story? -matthew kaufman

4 3