thomson@zazen.macc.wisc.edu (Don Thomson) (05/20/91)
We have several DECstation 3100's running Ultrix 4.1 and are looking at
offering uucp services, but are concerned about the feasibility of doing so
given that the 3100 serial ports don't provide complete modem control. The
ports have been described to me as RS423, data lead only, as opposed to the
full-blown RS232 ports on the DECstation 5000's. Are other people successfully
running uucp on a 3100, and if so was there anything special done in the setup
to compensate for the serial port problems?
--
----- Don Thomson ----- MACC, 1210 W. Dayton, Madison, WI 53706 -------------
(608) 262-0138 thomson@macc.wisc.edu / thomson@wiscmacc.bitnetlan_csse@netrix.nac.dec.com (CSSE LAN Test Account) (05/25/91)
In article <THOMSON.91May20071835@zazen.macc.wisc.edu> thomson@zazen.macc.wisc.edu (Don Thomson) writes: >We have several DECstation 3100's running Ultrix 4.1 and are looking at >offering uucp services, but are concerned about the feasibility of doing so >given that the 3100 serial ports don't provide complete modem control. The >ports have been described to me as RS423, data lead only, as opposed to the >full-blown RS232 ports on the DECstation 5000's. Are other people successfully >running uucp on a 3100, and if so was there anything special done in the setup >to compensate for the serial port problems? We've run both UUCP and SLIP on 3100s here; the modem-control "problems" really aren't that serious a problem unless you are a high-security sort of place. What is missing is the CD line that lets the modem tell the computer that it has lost its connection. This means that when the other end (or the phone company ;-) decides to hang up on you, the modem knows about it right away, but the software has to use a timeout mechanism, because the modem's attempt to say "Hey, we just lost the connection" doesn't get through. UUCP has no problem with this; it times things out just fine. The reason that security people get excited is that there's this window during which an outsider could make a call and connect to a live UUCP (or SLIP) daemon. If the outsider knew *exactly* how to take up such a connection in the middle of a conversation, it would be possible to come in and masquerade as the previous caller. Needless to say, this is not easy; you'd have to call occasionally, looking for a busy signal. When you got one, you'd then go into a phase of calling as frequently as possible, trying to connect to a modem that still has uucico talking to it. You'd then have to decode uucico's retransmissions, figure out where things lie, send in the right ACKs, and if you did it just right, you'd get the tail end of the file that was being sent. On this machine, you'd also have the problem of trying to decode SLIP packets (and sometimes our data-compression algorithm) and then faking the right IP addresses, TCP packets, etc. Not an easy job, but it is theoretically doable. If you are worried about an opponent with sources to uucp, detailed knowledge of the protocol, and a desire to intercept files being sent between your sites, then the 3100 is probably not the machine for you. But then, if you have such extreme security concerns, Unix is probably not the OS for you, either. And what the hell are you doing using the phone lines? The phone company has lots of UUCP experts on staff; they are quite capable of recording any conversation across their lines and decoding the data that it contains. A judicious bribe in the right phone exchange is a much more cost-effective approach than trying to intercept a UUCP link, and it gets them *all* your data. For most sites, this isn't a real big deal. The "problem" can't be exploited by anyone using commercial software. It certainly can't be a source of accidental mis-transfers of files. The link will die in 30 seconds or so; incoming calls will fail during this period (because they get a lot of binary garbage instead of a login prompt) and will try again later. The only real problem is these short periods of non-availability that could be productive time if the modem's hangup signal got through to uucico. +----------------------------------------------------------------+ Reply-to: John Chambers <jc@sppip7.lkg.dec.com> or <ub40.enet::jc> +----------------------------------------------------------------+