[EMAIL PROTECTED] wrote:
Disagree.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
ACKs don't stop when the handshake is over. They continue for every packet passed over an established connection. This is how TCP knows there was an error. A packet is sent for which no ACK is received in acknowledgement. I think you are misperceiving how TCP connections work.
The initial handshake : HostA requests a new connection(sends SYN) to HostB, HostB, among other things, sends an ACK to acknowledge HostA's SYN and Sends a SYN to HostA, HostA Sends an Ack back to HostB.
This establishes the connection. HostA starts sending packets, which HostB acknowledges(ACK bit) according to the window size. Established connections will have ACKs set unless there is an error, which would be detected as follows: Assuming HostA has negotiated a window size of one(ineffeicient, but easy as an example) with HostB, it expects to receive an ACK from HostB for every packet it sends to HostB. If HostA fials to receive an ACK, it resends the packet until it reaches its retry/timeout limit or it gets an ACK. In the event of a larger window size, say three, HostB will send an ACK every three packets and nothing in between, except in the event of HostB failing to receive one of the three windowed packets from HostA, in which case it would send an ACK for the last packet it did receive, and HostA would retransmit the packet(s) HostB missed based on the TCP sequence numbers established when the connection was first synched during the handshake. In both cases, HostA should see an ACK bit set on all packets coming back to it from HostB, even though HostB will send back fewer packets than HostA sends if a larger window size is used.
Robert Donovan -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
