Additional Metrics of TCP Anomalies

RST Packets

A TCP connection is reset by an RST packet. There is no need to acknowledge such packet; the closure is immediate. An RST packet may have many meanings:

• If a TCP client tries to reach a server on a closed port, the server sends an RST packet. The connection attempt could be a malicious one (port scanning – NMAP, etc.), or the consequence of an unexpectedly down server, client/server misconfiguration, server restart, etc.;
• A router might send an RST packet if the incoming TCP packet does not fit with the security policy (source range IP address is banned, the number of connection attempts is too high in a small period of time, etc.);
• A QoS (Quality of Service) equipment limits the bandwidth (or the number of connections) by sending an RST packet to any new connection attempt;
• If an Intrusion Detection System (e.g., Snort) detects a malicious connection, he can send an RST packet to roughly close it;
• If a host between Client and Server wants to do a Denial of Service, it can reset the connection by sending RST to both peers. Basically, it’s the same mechanism as the previous one, but the motivation is quite different.

Retransmissions

One of the TCP metrics that is interesting to analyze is the retransmission. A TCP Retransmission is when a TCP packet is resent after having been either lost or damaged. Such a retransmitted packet is identified thanks to its sequence number. In Cisco Provider Connectivity Assurance Sensor Capture (formerly Skylight sensor: capture), we do not consider packets with no payload, since duplicate ACKs are much more frequent, and not really characteristic of a network anomaly. There are several common sources for TCP retransmission:

• A network congestion. If a router can’t cope with the whole traffic, its queue will grow bigger until it gets full and then starts dropping the incoming packets. If you reach a predefined QoS limit, the exceeding packets will be dropped as well. Such drop will result in a TCP retransmission. A common way to identify this kind of problems is by taking a glance at the traffic statistics. If you see a flat line at the max traffic allowed, then you get the root cause of retransmission. If the traffic graph looks OK, you can check the load of the routers/switches you own (e.g., with the SNMP data). If the load is too high, you found the culprit.
• An overloaded server. Check the Section Slow Server.
• A hardware failure. Maybe a network equipment is simply down. It will obviously result in TCP retransmission until a new route is computed, or the issue fixed. This type of retransmission should occur with very short time effects and give some quite big peaks of retransmission, on very broad types of traffic on a specific subnet. If this happens often, it becomes important to find the faulty hardware by tracking down which subnets are concerned.
• A packet header corruption. Network equipments are used to rewrite portions of packets (Ethernet source/destination, IP checksum, maybe TOS field). A buggy firmware can result in corruption while rewriting protocol headers. In this case, the packet will probably be dropped within the network route. Even if it reaches the destination, the TCP/IP stack won’t consider it as a valid packet for the current TCP sessions, and the stack will wait for the correct packet. It will end in a TCP retransmission, anyway. This problem will likely occur on the same type of traffic and continuously.