From wang!elf.wang.com!ucsd.edu!tcp-digest-relay Wed Feb 6 15:58:31 1991 remote from tosspot Received: by tosspot (1.63/waf) via UUCP; Thu, 07 Feb 91 07:01:53 EST for lee Received: from somewhere by elf.wang.com id aa11631; Wed, 6 Feb 91 15:58:30 GMT Received: from ucsd.edu by uunet.uu.net (5.61/1.14) with SMTP id AA14962; Wed, 6 Feb 91 09:53:45 -0500 Received: by ucsd.edu; id AA20348 sendmail 5.64/UCSD-2.1-sun Wed, 6 Feb 91 04:30:30 -0800 for jbloom Received: by ucsd.edu; id AA20334 sendmail 5.64/UCSD-2.1-sun Wed, 6 Feb 91 04:30:20 -0800 for /usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi -ftcp-digest-relay tcp-digest-list Message-Id: <9102061230.AA20334@ucsd.edu> Date: Wed, 6 Feb 91 04:30:17 PST From: Advanced Amateur Radio Networking Group Reply-To: TCP-Group@ucsd.edu Subject: TCP-Group Digest V91 #34 To: tcp-group-digest@ucsd.edu TCP-Group Digest Wed, 6 Feb 91 Volume 91 : Issue 34 Today's Topics: budlist (6 msgs) How to reach G8BPQ... KA9Q NOS for the Commodore Amiga availability path elevation profiles? (2 msgs) permissions Public Passwords re: budlist RSPF Routes security (6 msgs) Security... size of fines spread spectrum info (2 msgs) Tucson Who is going to the TAPR meeting? Send Replies or notes for publication to: . Subscription requests to . Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the TCP-Group Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Mon, 4 Feb 91 19:56 GMT From: Subject: budlist To: tcp-group@ucsd.edu Yes, Doug. I think that probably both of us would like to see a better solution that budlists. My other thought about budlists that probably about once a week or so I get a completely new AX.25er connect to my system and try it out. Some become real users and some go somewhere else, but I'd hate to restrict access only to known users. A sort of "reverse" budlist (i.e. a "lockout" list) would be a better solution from my point of view. And we already have that. (Indeed, I confess that I have a couple of local trouble makers locked out of my system). So maybe we need do nothing further at all. If we use the lockout facility, then the only way one of those guys can get in is if he pirates a callsign, which is indubitably illegal, as we all know. Toodle-pip Doc ------------------------------ Date: Tue, 5 Feb 91 10:46:27 EST From: crompton@NADC.NADC.NAVY.MIL (D. Crompton) Subject: budlist To: DEVANS%COLOLASP.BITNET@CUNYVM.CUNY.EDU, tcp-group@ucsd.edu Doc, Maybe I am missing something - how do you lock out ax25 connects to the NOS BBS?? I see how it would be done TCP/IP in ftpusers. Anyhow most phone BBS's have a registration procedure. Users are limited in the use of the bbs until they register and are authorized. I think this would be a very good idea for ham bbs's also. A user would be able to read/list mail and other non-write operations, but not send mail (except to the sysop) until authorized. This registration would require the user to provide there name, address and phone number to the sysop. A message detailing the regulations and guidlines for the bbs would be supplied at the time of registration. This registration would usually be completed in a day or two and have little impact on the user. Acknowledgement of the registration would mean that the user understands (and accepts) responsibility for there actions. How about putting this authorization bit in NOS with a disk file lookup - 'ax25user'?? Doug ------------------------------ Date: Tue, 5 Feb 91 18:58 GMT From: Subject: budlist To: tcp-group@ucsd.edu Hi again, Doug I am sure someone will correct me if I am wrong; here is my "understanding" of things. ALL users, not just TCP ones are tested against the FTPUSERS permission bits. This provides the generalised lock-out facility that I described before. I am willing to be corrected on this, but if NOS doesn't behave like this, it darn well should [IMHO :-)], for obvious reasons. Just so that people don't get confused, my posting of a few minutes ago addressed a tangential point, namely that of VERIFICATION, not PERMISSION. The password in FTPUSERS is NOT used for non-TCP connections. This permits people to log in on non-TCP ports with no verification. For some users (like the system operator, for example) this should not be permitted. Please someone correct me if I am wrong on all this. If it doesn't work like this, please someone tell me how another person can get into my system and pretend to be me without knowing my password (which I take great care never to go out over the air), which, apparently, is what has happened. Just sign me... VERY CONCERNED :-( -- Doc ------------------------------ Date: Tue, 5 Feb 91 13:12:01 CST From: kurt@cs.tamu.edu (Kurt Freiberger) Subject: budlist To: tcp-group@ucsd.edu Once we have to start this registration procedure crap, it's time to start shutting down the BBS's. It ain't bloody worth it. What needs to be done is to get the FCC to make the BBS operators "no-fault" entities. The damage is done originally with the originator of the message. Even in Olde Tymes the practice was not to kill the messenger. kurt % Kurt Freiberger, WB5BBW Dept. of Computer Science, TAMU % % Internet: kurt@cs.tamu.edu | "Try not to become a man of success % % AuralNet: 409/847-8607 | but rather a man of value." % % AMPRNet: wb5bbw@wb5bbw.ampr.org | - Albert Einstein % % Disclaimer: Not an official document of Texas A&M University % ------------------------------ Date: Tue, 5 Feb 91 20:07:43 -0500 (EST) From: Anders.Klemets@CS.CMU.EDU Subject: budlist To: tcp-group@ucsd.EDU If you want to disallow someone from using your BBS, add the persons callsign to the ftpusers file and set the permissions to 128. This will kick him off the BBS. Anders ------------------------------ Date: Tue, 5 Feb 91 20:35:51 CST From: root@brainiac.mn.org (Supreme Weenie) Subject: budlist To: tcp-group@ucsd.edu > Maybe I am missing something - how do you lock out ax25 connects > to the NOS BBS?? I see how it would be done TCP/IP in ftpusers. > Anyhow most phone BBS's have a registration procedure. Users are One reason I never call phone bbs's is because of the ridiculous registration procedures. > limited in the use of the bbs until they register and are authorized. > I think this would be a very good idea for ham bbs's also. A user would I think this is a terrible idea, and if I ever get any NOS code with an abortion like this in it I will rip it out. > be able to read/list mail and other non-write operations, but not send > mail (except to the sysop) until authorized. This registration would > require the user to provide there name, address and phone number to > the sysop. A message detailing the regulations and guidlines for the Why ? You have the persons call sign - what more do you want ? > How about putting this authorization bit in NOS with a disk file > lookup - 'ax25user'?? I vote that this doesn't get put in. One of the first things that thrilled me about packet bbs's was instant access. Please, please don't put this in. Maybe an option to lock out certain users ( another disgusting idea ) could be put in, but I would rather see things stay like they are. ------------------------------ Date: Mon, 4 Feb 91 09:11:33 EST From: barry@dgbt.doc.ca (Barry McLarnon DGBT/DIP) Subject: How to reach G8BPQ... To: tcp-group@ucsd.edu I don't think the TSRs to support the other emulation modes have been released yet. You can reach G8BPQ on packet (G8BPQ@GB7DAD), but that's liable to be slow. I would suggest sending mail to Martin Stubbs G8IMB on Compu$erve, as he seems to work quite closely with BPQ. E-mail address is 73457.1536@compuserve.com. Barry VE3JF ------------------------------ Date: Tue, 05 Feb 91 00:06:55 EST From: "Louis A. Mamakos" Subject: KA9Q NOS for the Commodore Amiga availability To: Amateur Radio TCP/IP Discussion Group Contrary to what is published in this month's QST in the Packet Perspectives column, I am NOT a source for the KA9Q NOS for the Amiga. Heck, I'm not an ARRL member and don't even receive QST. Imagine my suprise when I started getting these mysterious phone calls "about the packet article in QST." I am selling off my Amiga system, and no longer have facilities for copying Amiga disks. Can only support one computer toy (now a NeXTstation) at a time... I've already received a number of phone calls from amateurs who read that article, and I'm hoping to save others spending a few dollars in long distance charges to talk to my answering machine. I wish authors would try to check this type of information before publishing it, as I have NEVER offered to to diskette distribution of the code that I ported even when I did have the facilities to do so.. I suspect people will "discover" this incorrect information in the article for years to come. Oh well. As far as I know, the latest work being done on the Amiga version of NOS is being done by John Heaton, G1YYH, who started with my version and added his own changes. I point folks at thumper.bellcore.com in the anonymous FTP directory /pub/ka9q/amiga for the distributions. Or, you might try to contact the author: John Heaton, G1YYH Janet: J.Heaton@uk.ac.MCC MCC Network Unit (g111) DARPA: J.Heaton@MCC.ac.uk The University AX.25: g1yyh @ gb7nwp.gbr.eu Oxford Road or g1yyh @ gb7crg.gbr.eu Manchester M13 9PL Ampr: amiga.G1YYH.ampr.org England [44.131.1.71] for other information about his version. 73, Louis Mamakos WA3YMH ------------------------------ Date: Mon, 4 Feb 91 14:01:17 PST From: Glenn Elmore Subject: path elevation profiles? To: tcp-group@ucsd.edu Does anyone know of an accessible database which can provide elevation profile information over an arbitrary path within the continental US? As we start to improve the physical and link layers we are going to have to pay closer attention to Line-Of-Sightedness of our radio paths. I know that USGS has this sort of information and I believe 3D topo maps exist in some locations (Redwood City, CA?) but I'm looking for a more general way to analyze potential paths. Right now I'm trying to get high level sites lined up and it sure would be nice to be able to tell if potential sites are LOS or not and by how much margin. Maybe I'll just have to "bite the bullet" and study existing hardcopy maps but I was hoping for a better and easier way.... Anyone have ideas? Glenn Elmore -N6GN- N6GN @ K3MC glenn@n6gn.ampr.org glenne@hpnmd.hp.com ------------------------------ Date: Tue, 05 Feb 91 15:24:10 cst From: gerry@n5jxs.jsc.nasa.gov Subject: path elevation profiles? To: glenne@hpnmdlc1.hp.com Yes. Look to your friendly neighborhood pilot store. Get World Aeronautical Charts (WACs), Sectional area charts, and VFR Terminal Area Charts (TCAs) for the areas you are interested in. These are in increasing orders of granularity. That should get you the info for a local area you need, and a single investment can work for years (if you're not a pilot). Better than that, go ask a friend- ly pilot for his old charts when they expire, or for a look now, if it's time sensitive. -gerry ------------------------------ Date: Tue, 05 Feb 91 23:44:17 PST From: noe.UUCP!kdavis%w6rfn.ampr.org@cgl.ucsf.EDU (Ken Davis) Subject: permissions To: noe.UUCP!tcp-group%ucsd.edu@cgl.ucsf.EDU This is the ftp user file, Format: User Password Path Permission add 1 for ftp/mailbox READ add 2 for ftp/mailbox WRITE add 4 for ftp/mailbox DELETE add 8 for mailbox to AX25 add 16 for mailbox to TELNET add 32 for mailbox to NET/ROM add 64 for mailbox to REMOTE Use 128 as a total to LOCKOUT USER Hope this helps.... Ken -- *----------------------------------------------------------------------* | | | Ken Davis - W6RFN San Francisco, CA "One of the NOSty boys!" | | UUCP: {apple,pacbell,hplabs,ucbvax}!well!rainbow!kdavis | | Internet: kdavis@well.sf.ca.us or kdavis%w6rfn@noe.kg6kf.ampr.org | | AMNET: ken@w6rfn.ampr.org AMBBS: W6RFN @ K3MC.CA | | | *----------------------------------------------------------------------* ------------------------------ Date: Wed, 06 Feb 91 04:04:12 UTC From: marcel@hb9rwm.ampr.org Subject: Public Passwords To: tcp-group@ucsd.edu Hello all Till today we hadn't any security violation problems in Switzerland. But to prevent us from such guys I have the following idee: (I know, that it isn't from me, but it works fine) Start with an initial password, written in ftpusers-File. Each time you log into the bbs (any way), you have to compute a new password with the initial password AND Time and Date coded. The algorithm should be save enough to prevent "back-tracking" several password to the initial. Maybe someone else can help here... vy 73 de Marcel%hb9rwm.ampr.org@hb9zz.ethz.ch ------------------------------ Date: Tue, 05 Feb 91 15:21:41 cst From: gerry@n5jxs.jsc.nasa.gov Subject: re: budlist To: DEVANS%COLOLASP.BITNET@CUNYVM.CUNY.EDU Well, seems like the TNC-2 "lidlist" model is the answer.... A budlist in reverse. If I remember correctly, you load turkeys in the budlist, then set budlist off, or something like that. (I don't have the TNC-2 manual where I can grab it here at work :=) ) gerry ------------------------------ Date: Mon, 4 Feb 91 19:21 GMT From: Gareth Howell Subject: RSPF Routes To: tcp-group@ucsd.edu Despite the advice from Anders, we are still having problems with rspf locally. My particular concern at present is the apparent need to be able to lock out nodes, like you can with netrom and rip. I have a station some distance from me, who I can hear but not work reliably. He is running rspf and I can hear his rspf broadcasts occasionally. I am running rspf in vc mode (tho' I think he is running datagram, or none [what's the difference?]). The problem is that I am showing routes via him that I know I cannot use. RSPf status shows him as a bad route, so why haven't the routes been dropped from the table? 73 Gareth PS (To Anders) thanks for the changed rspf timer, I also changed rspf suspect to 7200 so it was still twice the rspf timer. Is this correct? ---------------------------------------------------------------- Gareth Howell G6KVK g6kvk@g6kvk.ampr.org AMPRNET [44.131.19.1] garethh@cix.compulink.co.uk EUNET g6kvk@gb7khw._2111.gbr.eu UK BBS Network 29 Blackmore, Letchworth, Herts ENGLAND SG6 2SX +44 (462) 677090 ---------------------------------------------------------------- ------------------------------ Date: Tue, 5 Feb 91 18:42 GMT From: Subject: security To: tcp-group@ucsd.edu Hard on the heels of the East Coast BBS citations (and, possibly, inspired by it) I am now faced with the following problem. Someone has been accessing my system, coming in either AX.25 or NETROM, using MY call and sending offensive messages out through my system. Naturally, the audit trail makes it look like I was the source of these messages. Would it be possible (Phil/Kelvin/Anders) to structure NOS so that if a user has an entry in the FTPUSERS file, he is ALWAYS prompted for a password, even if he is coming in over a non-TCP connection? I am seriously considering pulling my system off the air now, which, of course, is exactly what this idiot wants... :-( Doc ------------------------------ Date: Tue, 05 Feb 91 16:16:29 cst From: gerry@n5jxs.jsc.nasa.gov Subject: security To: DEVANS%COLOLASP.BITNET@CUNYVM.CUNY.EDU Can't we simply turn the AX25 connect capability off? That'll satisfy your problem child not at all, since you'll still be on the air, but he can't get to you...You'll still be up for the die-hard tcp'ers, and maybe, just maybe, he'll mouth off and somebody will catch him complaining that he can't carry on his bootleg activities... Good luck, gerry ------------------------------ Date: Tue, 5 Feb 91 17:10:47 EST From: crompton@NADC.NADC.NAVY.MIL (D. Crompton) Subject: security To: tcp-group@ucsd.edu The easiest might be the following: 1. Add login for BBS ax25/netrom connects. Login name and Password would be in ftpusers. 2. A general 'bbs' no PW login could have use restrictions. 3. A bit in ftpusers could be used to allow or disallow sending of mail. So if the user had read only capability they could only read mail or download mail. No send mail. No gateway/netrom/telnet. Adding a login (there call) and password could authorize an individual user to additional services. Doug ------------------------------ Date: Tue, 5 Feb 91 22:30 GMT From: Subject: security To: tcp-group@ucsd.edu Sorry to waste bandwidth here. I have been getting quite a few private responses to my security posting, and most of the mail I have tried to send in reply has bounced, so I have to resort to posting here. You can stop reading here, and I won't be offended -- this is merely a response to those who Emailed me. The reason that I can't just shoot the guy is that I don't have the foggiest who he is. He comes in over the NETROM, probably from south-ish Denver 40-50 miles away, but I can't place him better than that; he stays on only for short periods and generally uses any old random callsign he can think of. He uses mine when he wants to post something particularly obnoxious, though. Shutting off AX.25 and NETROM connects would do the job, but then none of my regular users could use my system; and it's taken me a year or so to build up a loyal following of people who believe that TCP/IP systems are better at handling traffic than AX.25. I'm not concerned about the password-over-the-air problem. My password never gets transmitted, so no-one could find out what it is. My idea was that the next time this bozo tries to log in as me, he will be confronted by a password request, no matter what protocol he used to access the system. At that point he's stuck. Thanks for your patience... normal tcp-group service is now resumed... Doc ------------------------------ Date: 6 Feb 91 00:34:32 GMT From: brian@ucsd.Edu (Brian Kantor) Subject: security To: mail-tcp-group In article <27488@ucsd.Edu> crompton@NADC.NADC.NAVY.MIL (D. Crompton) writes: > >The easiest might be the following: > > 1. Add login for BBS ax25/netrom connects. Login name and Password >would be in ftpusers. If you do this, you need to either a) add encrypted transmission of the password, or b) use some algorithm to verify it, such as the old list-of- -indexes-into-a-passphrase trick (sorta like a one-time pad). Remember that ANYONE can monitor the transmission of a password on the radio if you don't do something to hide it. But, soft! What you're saying, forsooth, is that there are hams out there who don't shrink from the illegality of using a callsign not their own to forge messages. What they're doing is illegal. Is it a big enough problem that you can't just get them stomped on? I.e., are at the stage where we can't trust our fellow hams not to be hackers and jammers too? Hmm. I'm not surprised, just disappointed. - Brian ------------------------------ Date: Wed, 6 Feb 91 06:32:22 UTC From: karn@ka9q.bellcore.com (Phil Karn) Subject: security To: DEVANS%COLOLASP.BITNET@cunyvm.cuny.edu, tcp-group@ucsd.edu I am working on a one-time password scheme that I hope will eventually appear in NOS. It uses a one-way function (not a cipher) so it should be exportable. Phil ------------------------------ Date: Wed, 06 Feb 91 00:58:04 GMT From: sysop@kelvin.uk22.bull.com Subject: Security... To: tcp-group@ucsd.edu Ok chaps, I'll sort sommat out and make it available in my next offering to thumper. Watch this space -> <- :-) ------------------------------ Date: Mon, 4 Feb 91 20:10 GMT From: Subject: size of fines To: tcp-group@ucsd.edu ------------------------------ Date: Mon, 4 Feb 91 20:53:30 -0500 (EST) From: Anders.Klemets@CS.CMU.EDU Subject: spread spectrum info To: tcp-group@ucsd.edu I am running a couple of NCR WaveLAN spread spectrum boards on a pair of UNIX laptops. These boards are compliant with "part 15," but what exactly are the rules for output power? Is it 1 Watt ERP or something else? I would like to get some 900 MHz yagis for these boards. Would that be illegal? I have also heard about a "part 97" that would allow one to use more transmission power. Does anyone happen to know if these boards comply with part 97? Tnx, Anders ------------------------------ Date: Mon, 4 Feb 91 22:46:35 PST From: Kevin J. Rowett Subject: spread spectrum info To: Anders.Klemets@cs.cmu.edu > >I am running a couple of NCR WaveLAN spread spectrum boards on a pair of >UNIX laptops. These boards are compliant with "part 15," but what >exactly are the rules for output power? Is it 1 Watt ERP or something >else? In the USA, the limit is 1 watt output. You can take all the gain you can get thru antennas. There is a restriction to not use "repeaters". The rules don't really say what a repeater is, but it's generally mean't each end-point must be something useful besides a pair of radios. >I would like to get some 900 MHz yagis for these boards. Would that be >illegal? It would be a very good idea. > >I have also heard about a "part 97" that would allow one to use more >transmission power. Does anyone happen to know if these boards comply >with part 97? To comply with USA/FCC Part 97, you would have run the specific spreading sequence listed in Part 97. The NCR units don't. In fact, I've heard they have a dismal processing gain of 10dB! N6RCE ------------------------------ Date: Tue, 5 Feb 91 16:20:49 mst From: Bdale Garbee Subject: Tucson To: tcp-group@ucsd.edu Karen and I will be in Tucson, arriving late Thursday and leaving mid Sunday. I'll be in the board meeting all day Friday... Bdale ------------------------------ Date: Mon, 4 Feb 91 12:40:19 -0800 From: brian (Brian Kantor) Subject: Who is going to the TAPR meeting? To: tcp-group The TAPR annual meeting is the first weekend of next month. In the past, once the boring organizational stuff is out of the way, it's sort of a mini-packet radio convention. Anyone going? I guess you could call the TAPR office for details. - Brian ------------------------------ End of TCP-Group Digest ******************************