Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!axion!uzi-9mm.fulcrum.bt.co.uk!uzi-9mm.fulcrum.bt.co.uk!igb From: igb@fulcrum.bt.co.uk (Ian G Batten) Newsgroups: comp.dcom.modems Subject: Re: PPP spoofing Message-ID: Date: 2 Jan 91 09:32:52 GMT References: <6578.277D7512@zswamp.fidonet.org> Sender: news@fulcrum.bt.co.uk (News with an UZI) Organization: BT Fulcrum, Birmingham Lines: 47 In article <6578.277D7512@zswamp.fidonet.org> root@zswamp.fidonet.org (Geoffrey Welsh) writes: > As you point out, end to end ACKing is the only robust procedure... but > spoofing implies ACKing in a non end-to-end manner, so you seem to imply that > there is no way to enhance Internet protocol performance by using spoofing? Yes. UUCP-g has two levels of acknowledgement. There is the g protocol stuff that provides a service not unlike X.25 level 3 --- 64 bytes of data plus checksum and sequence being acknowledged usually on a 3-packet window --- and then there is the S-SY-file-C-CY handshake at file boundaries that uucico uses. That part is also used over c,d,e,f,t,x and all the other weird and wonderful UUCP protocols. Trailblazers spoof the low-level stuff but leave the hosts to manage the uucico stuff. [[ Incidentally, that's why TB performance is better on large files; hosts are re-syncing and the buffers on the modems have to flush on every file boundary. ]] If Something Horrible happens during transmission, the fact that the acks you got back at the lower level were fake doesn't matter --- the C-CY exchange will fail. PEP ensures that a stream of data will be stopped at a given point and what has been delivered will be accurate. You won't get packets 1 2 3 and 5 delivered and four dropped. This can't work for TCP streams. There's essentially only one level of acknowledgements --- the packet level. If the link goes down you have no way of knowing what structure is imposed on the link and therefore no way of knowing what's been lost. Suppose I write a protocol which sends multiple files over a single connection. Suppose I am getting false acks back from a spoofer and then the link dies. Just how many files have been transferred? The only spoofing that could, I suppose, be written is on a per protocol level. I believe, for example, that FTP manages its own acks above the TCP level, or you could do some very tricky things based on the fact that FTP opens a distinct session for each transfer. Having the SYN/SYNACK and FIN/FINACK exchanges end to end would work for FTP. SMTP could be spoofed by making the SMTP operations end to end and the messages spoofed. [[ Note: I didn't say this. Make sure you have an adult present if you try it. ]] Or if you could ensure that only one message was transferred per session the same trick as with FTP could be pulled. General TCP spoofing is not possible because of the unknown semnatics of the data stream passing. UUCP (and Kermit, and ?Modem) is spoofable because you can distinguish in a fairly trivial way between packet level acknowledgements and end to end acknowledgements and Do The Right Thing.