Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbatt!ucbvax!richb.UUCP@seismo.css.gov@dartvax.UUCP
From: richb.UUCP@seismo.css.gov@dartvax.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Submission for mod-protocols-tcp-ip
Message-ID: <8702091705.AA23665@dartmouth.EDU>
Date: Mon, 9-Feb-87 12:05:25 EST
Article-I.D.: dartmout.8702091705.AA23665
Posted: Mon Feb  9 12:05:25 1987
Date-Received: Wed, 11-Feb-87 19:57:04 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 41
Approved: tcp-ip@sri-nic.arpa

Path: dartvax!richb
From: richb@dartvax.UUCP (Richard E. Brown)
Newsgroups: mod.protocols.tcp-ip
Subject: Re: network password protection/TCP spec
Message-ID: <5665@dartvax.UUCP>
Date: 9 Feb 87 17:05:24 GMT
Reply-To: richb@dartvax.UUCP (Richard E. Brown)
Organization: Dartmouth College, Hanover, NH
Lines: 30
References:

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