Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!sri-spam!ames!ucbcad!ucbvax!dartvax.UUCP!richb.UUCP From: richb.UUCP@dartvax.UUCP (Richard E. Brown) Newsgroups: comp.protocols.tcp-ip Subject: Re: network password protection/TCP spec Message-ID: <6045@dartvax.UUCP> Date: Mon, 20-Apr-87 08:07:13 EST Article-I.D.: dartvax.6045 Posted: Mon Apr 20 08:07:13 1987 Date-Received: Tue, 21-Apr-87 02:07:23 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: dartvax!richb (Richard E. Brown) Distribution: world Organization: Dartmouth College, Hanover, NH Lines: 43 TO THE MODERATOR: I tried to post this a while ago, but received a reply from some mailer daemon that this message should be mailed to you, not posted. I never received any responses, so I'm suspicious: did it arrive and was it posted? If not, would you post it now? If it was, thanks. Rich Brown ------------ MY MESSAGE FOLLOWS ------- A while back, there was a discussion of protecting passwords, which lead to a discussion of taking over someone's TCP connection. One person noted that if a spoofer simply startd sending in-sequence messages, they could take over the session and the victim would be relatively helpless. Another person responded that he thought TCP specified that an ACK with a sequence number that was too high would result in a RST to clean out the connection. (Further discussion revealed that TCP does *not* specify this -- in fact, it allows the session to continue.) My question: Is this behavior (sending RST if the ACKs get too high) desirable? Are there any pitfalls to doing this? Here at Dartmouth, we have developed a stream protocol which runs over AppleTalk. It is in use throughout the campus with our Macintosh terminal emulator, and several commercial vendors are also implementing this protocol. If it is useful, a stroke of a pen will implement it (well, you know what I mean). Thanks. Rich Brown Dartmouth College Kiewit Computer Center Hanover, NH 03755 603/646-3648 richb@dartmouth.edu richb@dartmth.bitnet richb@dartvax.UUCP A0183 on AppleLink