Re: not sure ESTABLISHED TCP traffic will have ACK flag set always...

["Taylor, Grant" <gtaylor@riverviewtech.net>]

Yes it is plausable (and common) for one side to send more traffic than the
other side (pick your favorite downloading client for downloading ISOs).
Something to keep in mind (at least as far as I know it) is that for TCP to
operate packets that get sent MUST be ACKnowledged with in the TCP Window
size.  The WINDOW is how many packets can be out in the ether
unACKnowledged.  If a packet goes too long unACKnowledged the sending side
will resend the packet assuming that the packet has been lost somewhere.
That being said for at least 1 packet in every TCP WINDOW size received the
client will send an ACK with the ACK number set to the next Sequence number
that it is expecting to receive.  This is where Window sizeing comes to play
when you try to optimize transmition of data.  ...pause to think about the
question some more...  Something to keep in mind is that just because I'm
receiving data from the server does not mean that I can NOT respond to the
traffic that it has received.  Restated the client has to respond to the
server stating that it did receive the traffic that was sent to it.  Also
any traffic in an established TCP converstaion will have an ACK bit set
acknowlidgeing that it received traffic prior and a sequence number set to
the number of the next packet that it sees.  Thus the server will send a LOT
of packets to the client with the same Sequence number associated with the
ACK field.  I may have some terms / names of fields incorrect but this is
the conceptual understanding that I have of TCP conversations.



Grant. . . .

> Firewall packet filter question.....
>
>
> **After** setting up a TCP connection, it may seem to make
> sense that ALL future packets would set the ACK flag.
>
> (ACK is important in 2 way communication since both sides
> need to constantly confirm //receipt// of _past_ packets.)
>
> Therefore, you might think it would be a good idea to
> set up you firewall to drop packets on ESTABLISHED
> connections that don't have ACK bit set.
>
> However, here is an apparent case where non-ACKs exist!!!...
>
> 1. One way traffic!!! --- sender has nothing to ACK!
>
> 2. One side sends LESS packets then the other! --
>    fast side doesn't have enough incoming to ACK either!
>
> Agree? Why then do people say to drop non-ACK'd packets
> as suspicious??.... I would think it would be common
> for one side to send more packets then the other.  I could
> be wrong.
>
> Chris
>
>
>