Results 1 to 8 of 8

Thread: Protocol exchange

  1. #1
    Junior Member
    Join Date
    May 2005
    Posts
    15

    Protocol exchange

    Just got a simple question. What is an example of an accidental incomplete protocol exchange? not one caused maliciously e.g. syn flood but one that happens accidentally. The only think i could think of is when a computer/application sends a packet then crashes preventing the reciever from sending back a confirmation. Can someone please give me some real world examples.......thanks in advance

  2. #2

    Talking

    Not sure if this is what you are after. But one that comes to mind (was just reading about it earlier today) could be in the case of a Kerberos KDC. If the client requests a token but then crash prior to receival.....?

    Hope this helps

    D

  3. #3
    Senior Member
    Join Date
    Oct 2002
    Posts
    1,130
    A quick example would be a protocol exchage in which one of the packets was lost during transmission, either entering a routing loop and timing out, or becoming corrupted and therefore discarded.

    Another possibility would be a firewall dropping packets in between somewhere. Imagine you have a firewall that, for some assanine reason, allows SYN packets through to a private network, but to disallow new connections, does not allow SYN/ACK packets back (I have seen this used in honeynets before). The node sending the SYN packet would eventually time out because of an incomplete exchange.

    Actually, even dropping the SYN packets would cause an incomplete exchange or handshake, but only on the sending computer. The connection would have to wait to time out, or would clear if the firewall sends a reset packet pack.

    In most cases, the missing packet is resent when the expected reply is not recieved after a timeout perioud, and eventually the connection attempt will fail after a set number of retires. The TCP stack is designed to handle the few cases where something like this would happen. With malicious intent, the incomplete exchanges, in a SYN flood, for example, exceed the capability of the stack to handle them properly. An incomplete handshake or exchange here and there is really nothing to worry about. It happens all the time.
    Government is like fire - a handy servant, but a dangerous master - George Washington
    Government is not reason, it is not eloquence - it is force. - George Washington.

    Join the UnError community!

  4. #4
    Junior Member
    Join Date
    May 2005
    Posts
    28
    This can happen anytime the three-way handshake isn't successfully completed. When a server receives a SYN, it will respond with a SYN/ACK and wait to receive the final ACK. If the computer never receives the SYN/ACK, or never responds with an ACK, then the connection will remain half open until time out. Lost packets, firewalls, and other elements of computing could cause the half open connection. These half open connections will take up space in the TCP/IP queue, which would eventually become full, effectively rendering the machine unable to create new connections (SYN flood). Like Striek mentioned, a firewall could effectively block the SYN/ACK packet and leave the half open connection. I have also seen people new to network security attempt to write their open port scanners. When writing the code for a Stealth SYN scan, I've seen people forget to send the final RST packet to take down the half open connection. Nevertheless, I would expect the main cause to be lost packets, which should be resent under TCP anyway
    An ancient chinese man once told me: \"The hotter the tea, the bigger the wang.\"

    My tea is extra hot.

  5. #5
    Most of what Striek and frostedegg are talking about will not ever be viewable by the average user anyways due to the self correcting nature of TCP. You would, however be able to see these errors with a packet sniffer on a network. Running a sniffer could be useful if you are getting slow network response time or problems getting out to the internet.

    The protocol could experience all types of problems. Take, for example, IP can send those TCP packets throughout any different number of routes across the internet. If one or more of those packets do not arrive TCP has a problem. Now it has to have all the Packets after the last error free packet resent even if there was an error only halfway through the line. Now like I said this is almost completely transparent to the user.

    A breakdown in the TCP protocol can sometimes be seen in the use of OWA (Outlook Web Access) where a user does not specifically click to log out of the page the Fin, Fin/Ack sequence is not completed. The user can then, up to half an hour later, just open the portal back up and be completely logged into the same Outlook portal.

    Yes... after reading some more of Striek's post I have a little more to add. Like he said about firewalls dropping packets. Even the most basic firewalls employ what is known as SPI (stateful packet inspetion) technology. This means they can reassemble fragmented packets and monitor open TCP connections. If something times out or violates the firewall rules the traffic will be stopped. The user machine will never know what happened so this could lead to an incomplete protocol exchange. Most likely only the administrator and the IDS will know that what happened.
    "Experience is the hardest teacher, it gives the test first and the lesson after." Anonymous

  6. #6
    Junior Member
    Join Date
    May 2005
    Posts
    15
    thanks guys that helps quite a bit.

  7. #7
    Senior Member
    Join Date
    Oct 2002
    Posts
    1,130
    A breakdown in the TCP protocol can sometimes be seen in the use of OWA (Outlook Web Access) where a user does not specifically click to log out of the page the Fin, Fin/Ack sequence is not completed. The user can then, up to half an hour later, just open the portal back up and be completely logged into the same Outlook portal.


    OWA can also use cookies for authentication and not rely on a specific IP address and connection. This is very important in mobile networks or on networks with a short DHCP lease. So the "open connection" may in fact be a cookie left on the computer that was not deleted, as the "log out" button would normally do.
    Government is like fire - a handy servant, but a dangerous master - George Washington
    Government is not reason, it is not eloquence - it is force. - George Washington.

    Join the UnError community!

  8. #8

    Talking

    I did not know that... but now I do. Thanks
    "Experience is the hardest teacher, it gives the test first and the lesson after." Anonymous

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •