bob@MorningStar.Com (Bob Sutterfield) (12/27/90)
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?shri@ncst.ernet.in (H.Shrikumar) (12/27/90)
----------------------- [For comp.protocols.tcp-ip-ers ... There is this thread in Comp.dcom.modems talking about PPP and TCP/IP spoofing on Telebit modems. I am cross posting this for info ... all followups directed to comp.dcom.modems.] ----------------------- In article <BOB.90Dec26112824@volitans.MorningStar.Com> bob@MorningStar.Com (Bob Sutterfield) writes: > >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. Thanx Bob Sutterfield, for the much needed long post ... hopefully this will clear all doubting minds on this group. >An application based on TCP assumes a reliable, sequenced data stream. >[...] A TCP application assumes that any portion >of a transmission that has been ACKed has reached its destination, and [...deleted...] >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. 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 ? 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. Howmuch of this does the Netblazer do ? 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). Sigh! but since as netBelief goes, Telebit does not read this group anymore ... so would they listen to this idea ? ( 1/2 :-) >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? These results would be interesting ... has anybody any ? -- shrikumar ( shri@ncst.in )
bob@MorningStar.Com (Bob Sutterfield) (12/28/90)
In article <1211@shakti.ncst.ernet.in> shri@ncst.ernet.in (H.Shrikumar) writes:
However, some spoofing is still possible... 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.
It might be useful to allocate a few DAMQAM carriers or the HST
"reverse channel" for use by ACKs and the like, or to fit the MTU to
the characteristics of the line (or vice versa); but I wouldn't call
it spoofing, only accomodation and tuning. The modem wouldn't know
anything about TCP, only that it's allocating bandwidth to packets of
certain sizes and characteristics.
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.
While TCP can handle line problems admirably, there's certainly no
need to introduce them except perhaps for performance tuning. No need
to spoof a flat tire by shooting it, just to keep me on my toes while
I'm driving :-)
The modem can also spoof VJ Header Compression, so plain vanilla
slip can give good performance over the line.
Hmmm... I'll have to think about that one a while longer before I'm
convinced. Something doesn't feel right.
Thus, while the modem *should* *not* ACK any TCP packets, it can do
other things to increase thruput.
Right, but that's not spoofing in the same sense that Telebit modems
use the term in their handling of other protocols. It's just tuning.
How much of this does the Netblazer do ?
None, except VJ header compression (computed on the PC, not in the
modem) across serial links it manages. It's a conventional enough IP
router, with no intermediate-system protocol spoofing at all.
... the modem can also generate IP packets ... tell the computer
about the health of the modem, and the local host can reply back
and perhaps change modem settings etc...
Link quality monitoring is among the purposes of the proposed PPP MIB
for SNMP. Rather than have the modem generate IP packets, I suppose
the contents of the Trailblazer's S7[02] (for PEP) or S78 (for V.32)
or various other status registers could be acquired via the secondary
DTE channel, and digested for broadcast as a pppLinkQualityEntry. But
that secondary DTE was turned off in the standalone T2500 v7.00 ROMs,
so slightly more cleverness would be required.barmar@think.com (Barry Margolin) (12/28/90)
In article <1211@shakti.ncst.ernet.in> shri@ncst.ernet.in (H.Shrikumar ) writes: >In article <BOB.90Dec26112824@volitans.MorningStar.Com> 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
root@zswamp.fidonet.org (Geoffrey Welsh) (12/30/90)
Bob Sutterfield (bob@MorningStar.Com ) wrote: GW > Not if it could guarantee accurate delivery of the data GW >to a device which would retransmit it to the final destination if it GW >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. Jeez... first I thought were were talking about recovery from line noise bursts... then we got into IP rerouting around breaking links... now you're throwing in a charge of Grand Failure Powerline! 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? It's logical... but it's sad if true. >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. It took me a while to figure out that this is what you were saying. It looks like we're stuck with the following situation: we can use intermediate queues and spoofing to increase the performance of the actual data transfer, but we must still depend on end-to-end acknowledgement at the file level. This leaves us vulnerable in that the situation may require retransmission of packets ACKed locally... but let's look closely at what we gain/lose: First of all, my machine and my modem run off the same power. If I am the originating site, it doesn't matter whether I've sent all of the data to the modem and am waiting for the whole file ACK from the remote site, or I'm still sending data blocks to the remote site and being ACKed end-to-end; the transfer will be interrupted either way. In both cases, I know that the file has not been received at the other end... but the enhanced throughput of the spoofed connection might allow me to complete the transfer before the power fails! <grin - the only defence better than presence of mind is absence of body> I may really be sticking my foot in my mouth when I say this, because I am not familiar with the mechanics of Internet protocols, BUT... we need to develop protocols such that the receiving end can determine if a transfer has been previously attempted, and provide information to the sender such that it may be resumed. ZMODEM already does this: the receiver, if it detects that the file name, datestamp are identical to an existing file, informs the sender of how many bytes it has of the file and what the CRC of the bytes are. If the sender finds that the first n bytes of the file it's sending matches the CRC, the transmission jumps to the uncompleted portion. If we can all agree that this is a sensible way to go, we can take advantage of the enhanced throughput of spoofing while neither losing the robust nature of end to end ACKing nor necessitating massive redundant retransmissions whenever an in-progress transfer has been interrupted. Am I completely off the wall on this? If so, pardon my ignorance... I should lock myself into a (padded) room with some books on TCP/IP... -- UUCP: watmath!xenitec!zswamp!root | 602-66 Mooregate Crescent Internet: root@zswamp.fidonet.org | Kitchener, Ontario FidoNet: SYSOP, 1:221/171 | N2M 5E6 CANADA Data: (519) 742-8939 | (519) 741-9553 MC Hammer, n. Device used to ensure firm seating of MicroChannel boards Try our new Molson 'C' compiler... it specializes in 'case' statements!
igb@fulcrum.bt.co.uk (Ian G Batten) (01/02/91)
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.
csg@pyramid.pyramid.com (Carl S. Gutekunst) (01/03/91)
>UUCP-g has two levels of acknowledgement. There is the g protocol stuff >that provides a service not unlike X.25 level 3.... ^ Level 2. Just splitting hairs. <csg>
root@zswamp.fidonet.org (Geoffrey Welsh) (01/07/91)
Ian G Batten (igb@fulcrum.bt.co.uk ) wrote: >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. Thank you for a much needed (and I speak only for myself, of course) lesson in TCP/IP mechanics. I often wish that I had the time, equipment, and cash to learn these things first-hand. -- UUCP: watmath!xenitec!zswamp!root | 602-66 Mooregate Crescent Internet: root@zswamp.fidonet.org | Kitchener, Ontario FidoNet: SYSOP, 1:221/171 | N2M 5E6 CANADA Data: (519) 742-8939 | (519) 741-9553 MC Hammer, n. Device used to ensure firm seating of MicroChannel boards Try our new Molson 'C' compiler... it specializes in 'case' statements!