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

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

[Christian Seberino]

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

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

[Taylor, Grant]

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
>
>
>

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

[Michele Vetturi]

On Fri, Apr 08, 2005, someone also known as Christian Seberino wrote:
> 2. One side sends LESS packets then the other! --
>    fast side doesn't have enough incoming to ACK either!

This problem is resolved by the TCP window? Am I right?


> 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.


One side CAN send more packets.


-- 
[ Michele Vetturi
  --------------------------------------------------
  IRItaly.org and Honeynet.it member
  PGP key available at:    http://vetz.homelinux.org ]

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

[Taylor, Grant]

> This problem is resolved by the TCP window? Am I right?

If the ""problem that you are referring to is how many unACKed packets can
be sent by either side before it retransmits the packet that has not been
ACKed, then Yes this number is controlled by the TCP Window size.  The TCP
Window size is asically the number of TCP packets that can be sent out and
still on the wire before the sender resends a packet assuming that it was
dropped.

> One side CAN send more packets.

Yes I believe that this is correct.  Any packets sent by the server MUST be
ACKed by the client, but the client could ACK the SYN number of a packet
sent later in the conversation thus ACKing all packets that were sent up to
the point just prior to the number that was ACKed.  What??? When a packet is
ACKed, the ACK number is the number of the next sequence number that the
receiving system is expecting to receive from the server.  Thus if I have
received packets 1234, 1235, 1236, and 1237 from you I would send a packet
back to you with an ACK of 1238 statin gthat I'm expecting your next
sequence number to be 1238 effectively ACKing all packets up to and
including 1237.



Grant. . . .

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

[seberino]

> Thus if I have
> received packets 1234, 1235, 1236, and 1237 from you I would send a packet
> back to you with an ACK of 1238 statin gthat I'm expecting your next
> sequence number to be 1238 effectively ACKing all packets up to and
> including 1237.
>

 Grant

Thanks for your reply.  I did not know you could ACK multiple sequence
numbers with a single ACK.  That really helps.   You obviously
have a deep knowledge of TCP.

I am still confused why anyone could believe that packets //without//
the ACK flag set are suspicious.  Going back to your scenario above,
there is a faster side blasting packets (1234, 1235, 1236, 1237...)
faster than the other side is sending packets.  Clearly the
faster side cannot set the ACK bit in all those packets
(1234, 1235, 1236, 1237...) on because the fast side has fewer
incoming packets to acknowledge right?

Chris

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

[Grant Taylor]

> Thanks for your reply.  I did not know you could ACK multiple sequence
> numbers with a single ACK.  That really helps.   You obviously
> have a deep knowledge of TCP.

You are welcome.  I have some info in my head but I'm not entirely sure that it is 100% accurate, I'm hoping that it's close though.  So if you find any thing wrong with what I'm saying please let me know.

> I am still confused why anyone could believe that packets //without//
> the ACK flag set are suspicious.  Going back to your scenario above,
> there is a faster side blasting packets (1234, 1235, 1236, 1237...)
> faster than the other side is sending packets.  Clearly the
> faster side cannot set the ACK bit in all those packets
> (1234, 1235, 1236, 1237...) on because the fast side has fewer
> incoming packets to acknowledge right?

When the faster sending site sends it's packets to the slower receiving site the packets that are sent (1234, 1235, 1236, 1237...) will all have the same Acknowledgment number set in their packet stating that the next packet the faster sender receives from the slower client should be that Sequence number.  I personally do not know of a scenario where it would be plausible to receive a TCP packet with out the ACK bit set except during the SYN, SYN-ACK, ACK-ACK initiation phase and even just the first packet does not have the ACK bit set.  Even if you send a RST (reset), FIN (finish), PSH (push), URG (urgent) (I'm trying to remember my flags here with out looking them up so I could be wrong) flags they will all be during an on going TCP conversation and thus would have the ACK bit / flag set.  The only really questionable flag is the RST where some TCP/IP stacks will send packets with the 
 RST flag set if they mistakenly receive a packet that was not destined to them.  This is i
mplementation dependent and not clearly defined in RFCs and thus a matter of some confusion.  IMHO the stack tat received this packet should just drop the packet as it was obviously not meant for it and there was a failure elsewhere.



Grant. . . .

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

[seberino]

> When the faster sending site sends it's packets to the slower
  receiving
> site the packets that are sent (1234, 1235, 1236, 1237...) will all
  have
> the same Acknowledgment number set in their packet stating that the
  next
> packet the faster sender receives from the slower client should be
  that
> Sequence number.

Grant

Wow!  Thanks again.  You cleared up the last missing piece about ACKs!
So the slow side can ACK multiple sequence numbers with a single
packet.  Likewise, the /fast/ side can send multiple ACKs for
the same repetitive sequence number.  That makes perfect sense.

Now I believe that TCP packets can all have ACKs set on an
ESTABLISHED connection.

Chris

P.S. BTW, I'm curious how you knew this level of great info.  Did you
carefully read through RFC 793?  That was jam packed with info but
hard to digest fully.

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

[seberino]

> The only really questionable flag is the RST where some TCP/IP stacks will
> send packets with the RST flag set if they mistakenly receive a packet that
> was not destined to them.  This is i
> mplementation dependent and not clearly defined in RFCs and thus a matter
> of some confusion.

I haven't read this in RFC 793 myself.  However, I've read other
docs /about/ RFC 793 that state that RFC 793 mandates closed
ports *must* send an RST in response to packets.  This is the
basis for at least some of stealth scans like FIN, Xmas and NULL
IIRC.

It is true that different stacks don't follow the RFC in this area.
MS Windows does not do the proper thing in this area.  This
is why the /absense/ of the RST from a closed port is one way
to do OS fingerprinting!  If every OS followed the RFC in this
area there would not be so much confusion if I understand things
correctly.

Cheers,

Chris

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

[Grant Taylor]

> Grant
> 
> Wow!  Thanks again.  You cleared up the last missing piece about ACKs!
> So the slow side can ACK multiple sequence numbers with a single
> packet.  Likewise, the /fast/ side can send multiple ACKs for
> the same repetitive sequence number.  That makes perfect sense.
> 
> Now I believe that TCP packets can all have ACKs set on an
> ESTABLISHED connection.
> 
> Chris
> 
> P.S. BTW, I'm curious how you knew this level of great info.  Did you
> carefully read through RFC 793?  That was jam packed with info but
> hard to digest fully.

No, I cant say as I recall reading RFC 793 in particular, though I do read a LOT of RFC pertaining to what I do, I'm a systems administrator / consultant, so I need to know a lot about email (SMTP), DNS, www (HTTP), etc.  I spend a lot of time helping others get their system up to speck thus I've run across a lot of not quite up to spec but close enough to work *most* of the time.  I get called when it does not.  If ever I run across things that I don't know about (and it happens more than you might think) I turn to RFC, Google (this is a REALLY BIG ONE), and peers in the industry on mail lists like this one.  It's not what you know, it's who you know to ask.  :)



Grant. . . .