On Wed, May 03, 2000 at 01:51:07PM -0400, Randy Janinda wrote:

> Let me try to explain this:

> 

> BoxA talks to 2 boxes, FE1 and FE2.

> 

> Somewhere along the way something happens and BoxA sends a reset (RST) to FE2.

> Now, while looking at the network log the RST packet contained an ACK number

> that was obviously meant for FE1. I know it doesn't matter what the ACK number

> in a RST packet, because the connection is going to be terminated, BUT this

> brings up a few questions:

> 

> 1) Why did BoxA send the wrong ACK # to FE2? Does the OS share "TCP buffers"

> with both connections?

> 

Why:  A bug?

I don't know that there actually is a "wrong" ACK # in a RST segment, except in one case.  The protocol requires that if the incoming segment (the one being reset) does not have an ACK # (e.g., it's a SYN segment), then the ACK # of the RST must be set equal to the incoming SEQ # plus the incoming segment length, thus effectively ACKing the incoming (SYN) segment.  Except for this case, the protocol is silent regarding the ACK # in the RST.  Therefore, while it might appear that your RST segment contained an ACK # "obviously meant for FE1", such behavior does not seem to violate the protocol.  Nonetheless, it does seem unusual, and the code that I've looked at behaves more logically by clearing the ACK # and the ACK bit. 

Probably of greater importance is the SEQ # of the RST segment.  If the incoming segment has an ACK #, then the SEQ # of the RST segment is set equal to the incoming ACK #.  This assures that the when the RST is received at the remote end, it will be found to fall within the receive window.  If this were not the case, the RST would be ignored.  (This protects against old RST segments floating around from prior connections.)

So the question is, does the RST contain a SEQ # "obviously meant for FE1"?

> 2) Doesn't this present a small security problem since FE2 now knows information

> about the current FE1 connection?

> 

While the behavour might not be desirable, I'm not coming up with any ideas of how it might be exploited. 

--Joe


--
To unsubscribe: mail ">majordomo@ale.org with "unsubscribe ale" in message body.