in reply to Piggybacking data on TCP ACK

The TCP protocol can be thought of like a state machine (as can many protocols). Data can only be sent in what is commonly refered to as the established state. The connection is only in the established state when the 3 way handshake is complete. Data is not sent in the ACK packet.

If you could provide some background as to why you want to put data in the ACK packet instead of just sending another packet we might be able to help you find an alternative. I don't see an immediate reason that one would need to put data in the ACK packet.

Wikipedia:TCP has some great entry level information into this protocol.

Update: After reading your title I infer that you may be interested in sneaking data across a network by using the 3 way handshaking. I believe that there is a better way of doing it. A packet sniffer/analyzer (like wireshark) would immediately flag the ack+data packets as not conforming to known protocols. However... you can sneak data through on the syn packets using the sequence number. By creating a raw socket you can craft your own SYN packet with a meaningful sequence number (rather than a random one). Then your own TCP engine will likely reject the SYN+ACK response (because it didn't know about your raw socket). If your TCP engine does not work that way you can always send a RST packet to terminate the process. Then you send a new SYN packet with a sequence number corresponding to the next 32 bits of your data. This will appear less suspicious (especially if you encrypt the data) because it will appear to be an old style TCP Denial of Service SYN flood attack foiled because of modern tcp engines.

Of course my inference could be completely wrong and that lengthy passage could be completely worthless to you but hopefully it helps a little.

Replies are listed 'Best First'.
Re^2: Piggybacking data on TCP ACK
by rrekhi (Initiate) on Jun 16, 2011 at 20:48 UTC

    Thanks for replying, Let me explain why i want to simulate the data along with Ack packet.I have seen some web clients which Piggyback HTTP GET request in the Ack packet, I want to simulate that to test a proxy.I am very sure this is allowed as per TCP RFC.If anybody knows any trick other than Raw sockets and creating packets please let me know

      If anybody knows any trick other than Raw sockets and creating packets please let me know

      You *will* need to use a raw socket since you don't want to use your system's TCP driver. The only question is whether there exists something that will create the packets for you or not.

      I think we are using the same terminology to refer to 2 different things. After a connection is made:

      A B SYN------> <--------SYN+ACK ACK------>

      Then the ACK flag (or bit) is kept high for all subsequent packets. I used the term ACK to mean specifically the packet sent in response to a SYN+ACK packet, I did not mean to use it to refer to any packet with the ACK flag set.

      You are correct that data is allowed to be sent during the 3 way handshaking provided that it remains in a buffer until the connection is established (from RFC 793). So the data does (should) not be passed up the stack until the connection is made.

      I currently do not have access to a computer with the libpcap library but this code should help get you started towards your goal.

      use Net::RawIP; $ack_with_data = Net::RawIP->new({ ip => { saddr => '111.111.111.111', daddr => '111.111.111.112' }, }); tcp => { source => 111, dest => 111, ack => 1, #insert the correct seq number and ack seq number seq => 11111, ack_seq => 11111, #insert http data here (i am not very familiar with http) data => "GET /asdlfk HTTP/1.1\nHost: asd.asd.com\n", }, }); $ack_with_data->send;

      Disclaimer: This code might be missing some things. I was not able to test it but it should help you see how to form a packet and send it. The specific fields will need to be correctly set and I might be missing a few.