Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!uunet!mstar!mstar.morningstar.com!bob From: bob@MorningStar.Com (Bob Sutterfield) Newsgroups: comp.dcom.modems Subject: Re: PPP spoofing Message-ID: Date: 26 Dec 90 16:28:32 GMT References: <6547.277047AD@zswamp.fidonet.org> Sender: usenet@MorningStar.COM (USENET Administrator) Reply-To: bob@MorningStar.Com (Bob Sutterfield) Organization: Morning Star Technologies Lines: 93 In-Reply-To: root@zswamp.fidonet.org's message of 19 Dec 90 18:07:24 GMT In article <6547.277047AD@zswamp.fidonet.org> root@zswamp.fidonet.org (Geoffrey Welsh) writes: Bob Sutterfield (bob@MorningStar.Com ) wrote: UUCP spoofing works because uucico's ACKing and retransmission is at the granularity level of a complete file. UUCP-g ACKs (or request retransmission) of each and every packet on a real-time basis. Correct. But I was talking about uucico (the program that typically implements UUCP-g and can be considered the protocol layer "above" UUCP-g), which knows only about complete files. Surely you don't believe that a burst of line noise could cause the retransmission of a complete newsbatch?!? It often does, which is why news is typically batched in a number of 100 Kbyte files, rather than in one nightly 5 Mbyte blortful. With cheap modems and dirty lines, UUCP-g often gives up on a file transfer and a connection, telling the layer above (uucico, in typical implementations) that it was unsuccessful. It's uucico's job to arrange for retransmission by whatever means, usually as specified in L.sys/Systems. And in typical implementations, UUCP-g doesn't tell uucico how far it got in the transfer, only that the connection failed before the entire file was shipped. So uucico has no choice but to start again at the beginning of the failed transfer. Better to have a large number of medium-sized files so that uucico's file-level retransmission synch points occur more frequently. The "g" protocol level doesn't manage file retransmission or restarts in mid-file. Kermit spoofing is similar. This has no bearing whatsoever on spoofing. In-modem protocol spoofing works because it operates at a low enough level in the protocol stack that the modem needn't accept responsibility for the entire file, nor even for that segment that the sender thinks has already arrived at the destination. UUCP-g can safely abandon a link because it knows that uucico above it will arrange for retransmission. But TCP streams think that, once a packet has been ACKed, it has been delivered to the receiving end. Retransmission and restarts happen at a packet granularity. This is also true of UUCP-g. UUCP-g retransmissions happen at a packet granularity. But UUCP-g has no provision for retransmission outside its sliding window (often of size 1), which effectively describes a restart. That's uucico's job, in typical implementations. And uucico restarts happen at a file granularity. An application based on TCP assumes a reliable, sequenced data stream. In fact, IP may switch the stream between several routes as intermediate links break. A TCP application assumes that any portion of a transmission that has been ACKed has reached its destination, and will restart as necessary with the next octet in the stream, until reaching some timeout value. It will then typically report the failure to the user for a user-level restart, such as another attempt at opening a FTP or TELNET connection. If part of the circuit between transmitter and receiver were to accept responsibility for delivery of a packet after ACKing it to the transmitter, it would destroy the end-to-end nature of TCP. Not if it could guarantee accurate delivery of the data to a device which would retransmit it to the final destination if it were to be NAKed... that is the way spoofing works. If such a guarantee were possible, then your conclusion would be correct. But a modem cannot guarantee packet delivery. If a modem has ACKed a packet to the sender and continues to hold it in its on-board memory buffer while it attempts to re-establish a connection, the packet is vulnerable to a multitude of problems such as power loss. TCP assumes that an ACKed packet has been delivered to its destination, and could not resupply it to the modem when power is made available once again. IP and TCP were designed for hostile conditions where intermediate systems (wires, modems, routers, gateways, etc.) can be expected to become unavailable at any time (that's a nice way to say "MiG attack"). In such a scenario, only end-to-end ACKing is robust enough to ensure that the data gets through. And such pessimistic assumptions have proved themselves useful over the life of the civilian Internet as well. I'm having trouble imagining at what level of the stack in-modem protocol spoofing might be useful for IP or ISO internetworks, above the data link layer. I haven't gotten around to testing synchronous PPP over T2500s in PEP SDLC mode - has anyone? Is its performance enough better than asynch PPP over asynch PEP to be worth the trouble?