[Intrusions] [Non-intrusion Q] Is this normal FTP and TCP"underneath it" behavior?

[Stef]

I understood this (my explanation of client and server was more along
the lines of "who is the "owner" of server (<1023) ports), but my
question was about the ACK=0 in the RST sent by the "server" (client
with port 20, if you will). I do not remember having seen ACK=0,
except for when the numbers would "wrap around". Then - on the
"client" side (server with ephemeral port) - why would it send an ACK
of its own data? I guess what I am saying is that I would have
expected it to ACK (perhaps again, if nothing else, and as a RST does
not take seq. nb.) the server (client wirh port 20) last successful
data segment?!?


On Sat, 18 Sep 2004 18:05:05 -0400, Bill Royds <broyds at rogers.com> wrote:
> Remember that in standard FTP (not passive with PASV), the data connection is
> initiated by the server with the FTP client as listener (reversing the standard
> client-server relationship). So what you are seeing is the server (as client in
> the data connection) sending the reset saying it is out of synch and your client
> (as server) agreeing with indication of last data received (or sent).
> 
> -----Original Message-----
> From: intrusions-bounces at lists.sans.org
> [mailto:intrusions-bounces at lists.sans.org] On Behalf Of Stef
> Sent: Saturday, September 18, 2004 12:48 PM
> To: Intrusions List (GCIA Practicals)
> Subject: [Intrusions] [Non-intrusion Q] Is this normal FTP and TCP"underneath
> it" behavior?
> 
> This is a non-intrusion question, which, though, I have thought of
> being worth debating with you - TCP/IP gurus. I have an odd behavior
> of an FTP server-client communication, which I call "odd" because I
> have not found anything in the RFCs I tried, or in Steven's book,
> explaining the following:
> 
> - in a scheduled (every hour) ftp "conversation" between a client and
> a server (which conversation consists in a simple upload and download
> of some files, each one taking approximately 2 minutes), every once in
> a while such a session fails with the following last packets:
> 
> server --> client packet: flags: RST, ACK=0 (! - the ACK in those RSTs
> is always 0)
> client --> server packet: flags: RST(!!! -as if there is a standard to
> force a RST from the client, in response to a RST from server?!?) and
> SEQ = "number", ACK = "number" (!! - the ACK in the client "reply"
> RSTs is always equal to its own sequence number, and not related to
> the SEQ of the server)
> 
> NOTE1: the above is always happening over the data connections (never
> over the control one)
> 
> NOTE2: normal traffic ends ... well, normally: FIN --> ACK --> FIN --> ACK
> 
> Could anyone tell me what they think of this, or point me to the place
> where the above may be explained?!?
> 
> TIA,
> Stef