Replay: How TCP Works - The Timestamp Option (by Chris Greer)

 

In the TCP handshake, you may see an option called timestamps, shortly followed by scary-looking “TSval” and "TSecr" numbers. What are those values and how can you interpret them? Let’s dig.

What is a TCP Timestamp?

The timestamps option in TCP enables the endpoints to keep a current measurement of the roundtrip time (RTT) of the network between them. This value helps each TCP stack to set and adjust its retransmission timer. There are other benefits, but RTT measurement is the major one.

How it works.

Each end of the connection derives a 4-byte increasing value. This value is unique to each side and has no real numerical significance. The opposite end does not care what the value is, it will simply echo it back to the original sender. The original sender can then measure the timing between the packet(s) that were sent and received with this unique value.

The value used by each end will be increased as the connection goes along. Many TCP implementations will add the measured network RTT value (in milliseconds) to the 4-byte timestamp and use this new number for the next segment to be sent.

For example, in the screenshot below, we can see both ends of the TCP connection using timestamps. Both values, the one used by the sender and receiver, have been added as columns in Wireshark to make them a little easier to see.

The first packet has a timestamp value of 1125169296. Told you it was long and scary! But let's analyze...

At the start of the connection, the sender has not yet seen a timestamp value from the opposite end of the connection, so it has no number to echo back yet. That is why we see a zero in the Timestamp Echo Reply column.

The second packet shows the receiver echoing back the timestamp value, while sending a unique value of its own. Notice that these two numbers are completely different and are not related to each other at all. However, in the SYN/ACK, the timestamp echo value must be exactly the same as the value sent in the SYN, or the connection will fail. The connection initiator will likely send a reset to clear the connection.

Next, in the third packet, we can see that the original sender increases its timestamp by 212, sending a new value to the other end. From the delta time column, we can see that the roundtrip time between the two stations is 212 milliseconds (we captured on the 192.168.10.108 end). This value is added to the original timestamp and sent out on the next segment.

As the connection goes along, these values will increase. While they look long and scary, remember that they are only echoed back from the opposite side allowing the sender to mark and measure the roundtrip time. The value itself doesn’t have a specific meaning.

Keep in mind that the TCP Timestamps Option and the Wireshark-derived TCP Conversation Timestamps (which you need to enable in Wireshark) are very different things. For some info on the conversation timestamps, check out this video:

Getting Started Is The Tough Part

 Regardless if you are troubleshooting, baselining installing or designing getting accurate data is critical.

We’ve all heard that old saying “garbage in, garbage out” but what about “no data, no chance”?

When I present or teach I always try to instill some basic concepts to help attendees regardless of their role.

The first point is “get off your chair”. When possible get off your chair and visit the site, or client, to get a proper perspective of the issue, site and gather first-hand information. In the day of video calling, and the ability to record video/photos from your phone, you can ask the client to ‘show you the issue’ or a walk around the site.

The second point is to document! Document anything, tools used, methodology the switch make/model, ip addresses, port numbers, operating systems, etc… you would be surprised how helpful this information can be for you at a later date or for someone else working with you.

No matter what you do, document or start with, just start with something. For example, I get many requests to help with application or device baselines. The first thing I ask is how do you want to baseline? There are many options; you can use the SNMP port stats of your switch to watch load/utilization, review firewall logs for port numbers used, if its windows or linux, look at netstat output, or lastly capture packets.

When I started working with packet analyzers, I would capture packets while on hold or any opportunity so I can get comfortable with the tool and interpreting the results BEFORE I take it out in the field.

The critical part of performing packet captures is to ensure you note if you used a span port, hub, tap, directly from the device to capture your packets. The most common techniques I see out there is a span port or tap.

When it comes to taps, they are not all built the same, or have the same features. Make sure you get the one that fits your needs, for example is it a packet broker, goes it pass POE through, what interface does it use to connect to your computer, how user friendly is the software, etc..

In this short video, I show you how I connected a Profitap Profishark inline to capture a phone’s bootup for baselining, troubleshooting and baselining.

Cheers

TLS Decryption in Wireshark (chris greer)

 Hey packet gang!

Encryption. We see more and more of it in our packet traces. What used to be open, clear-text, and easily readable is now locked down, secure, and tough to troubleshoot. Hey that is a GREAT thing for security and ensuring that data is protected when it is in motion.

Until something breaks.

Troubleshooting encrypted data streams is very difficult, especially if the problem is not a network or transport layer issue. Even measuring application response is difficult because we cannot always confidently map a client request to a server reply unless we decrypt the session. This is especially true with HTTP/2 where multiple parallel streams are supported within one TCP connection.

So how can we capture the TLS session keys, feed them to Wireshark and decrypt traffic? In this video we will talk about how to do it. Be sure to download the packet capture and keylog files here so you can follow along.