Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!think.com!barmar From: barmar@think.com (Barry Margolin) Newsgroups: comp.dcom.modems Subject: Re: PPP spoofing Keywords: PPP, TCP, IP, Telebit, Trailblazer Message-ID: <1990Dec27.203446.16765@Think.COM> Date: 27 Dec 90 20:34:46 GMT References: <6547.277047AD@zswamp.fidonet.org> <1211@shakti.ncst.ernet.in> Sender: news@Think.COM Organization: Thinking Machines Corporation, Cambridge MA, USA Lines: 78 In article <1211@shakti.ncst.ernet.in> shri@ncst.ernet.in (H.Shrikumar ) writes: >In article bob@MorningStar.Com > (Bob Sutterfield) writes: >>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, > > This is very correct. You hit the problem on the head. > > However, some spoofing is still possible. When TCP sees the >long turnaround of ACKs via the slow (or delayed) PEP reverse channel, >it may prefer to set rather inappropriate window sizes etc. However, by >spoofing these packets, the two modems can tune their PEP packets to >the IP packet size, the TCP window to the PEP window, which inturn will >depend on line conditions and retransmission rates, and this can be >dynamic. This will be at no extra (transmission) cost since surely >the modems are already doing dynamic PEP adaptation already. You seem to be using a more general definition of "spoofing" than most other people. It usually refers to sending fake responses (e.g. ACKs) before receiving them from the actual recipient of the packet (in this case, the destination host's TCP layer). This would not be reasonable for a link-layer device when being used to transmit TCP, because it can't guarantee delivery after it acks. It could keep retransmitting the packet, but that doesn't guarantee that the packet will eventually get delivered; meanwhile, the sending TCP will assume that it has. But worse, what if the destination host sends an error indication back instead of a positive acknowledgement; for instance, a later router may fragment the datagram, but the host may not be able to reassemble it for some reason (I suppose this could be hacked by having the spoofer implement a path MTU discovery algorithm). In general, you frequently open a big can of worms when low-layer devices try to be clever about the high-layer data; another example of this is routers that do packet filtering based on TCP/UDP port numbers. On the other hand, if all you're suggesting is that the modem recognize PPP packets and lower its forwarding timeout, that seems perfectly reasonable. For insstance, it could peek at the PPP packet's length field and forward immediately upon receiving that many bytes. It doesn't change the semantics of the data path, merely optimizes the use of the medium for the type of data being transmitted. > Of course, this will make the line look error free to TCP, but my >uneducated guess is that would not affect TCP too much. If it would, >then some errors need to be spoofed as well to keep the algorithms in >TCP happy. Would some C.P.TCP-IP-guru correct, if I am wrong ? TCP (actually IP) doesn't see individual lines, it sees a sequence of lines connected by routers. An error-correcting modem can only make one of those lines look error free, but TCP depends on finding out about errors at any of the lines or routers along the way (either through error responses or timeouts). > The modem can also spoof VJ Header Compression, so plain vanilla >slip can give good performance over the line. This is another >spoofing possible. > > Thus, while the modem *should* *not* ACK any TCP packets, it >can do other things to increase thruput. Yes, this is correct. Note that both this suggestion and my suggestion about timeouts above perform their spoofing on data that is only concerned about single links. A link layer device should not spoof end-to-end data. > Now howabout this ... the modem can also generate IP packets, >and mix them into the stream coming from the telco side into the >local host. These TCP or UDP packets could tell the computer about the >health of the modem, and the local host can reply back and perhaps >change modem settings etc. Each modem will need an IP address too, though. >(This can be done with PPP, 'cos PPP is point to point). Not a bad idea. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar