brave / zerotrace

Go package that provides an implementation of the 0trace traceroute technique to determine the round trip time to a remote client.

ZeroTrace

Imagine you run a Web service and want to determine the network-layer round trip time to clients that connect to your Web service. An ICMP ping is unlikely to work as most home routers don't respond to ICMP echo requests. A TCP ping is also unlikely to work because home routers typically don't respond to unexpected segments with a TCP RST segment. It is generally difficult to get home routers to respond to unsolicited traffic.

The key insight of the 0trace technique is to piggyback onto an already-established TCP connection to conduct a traceroute measurement. As long as the client has an open TCP connection to our Web service, we can inject segments with increasing TTL into the TCP connection. Firewalls along the path are more likely to respond to packets with an exceeded TTL if they are part of an established TCP connection. While this technique may not always make it all the way to the client, it tends to get close.

This Go package implements the 0trace traceroute technique. The API is straightforward: Instantiate a new ZeroTrace object by calling NewZeroTrace. Then, start the object by invoking its Start method. Afterwards, you can invoke the CalcRTT method by providing the net.Conn object of an already-established TCP connection. CalcRTT returns the round trip time to the client (or the hop that's closest) as time.Duration, or an error.

Configuration

ZeroTrace's constructor expects a configuration object as argument. Take a look at the Config struct to learn more about configuration options. The function NewDefaultConfig returns a default configuration object with reasonable defaults.

Example

Use the code in the example directory to get started.

Development

To test and lint the code, run:

make

zerotrace's Issues

Accessing webpage on mobile data causes error

Accessing the webpage on mobile data returns an unhelpful error on the webpage,json: unsupported value: NaN and console log says Failed to load resource: the server responded with a status of 500 ()

It fails to log anything useful on ErrLogger as well. It possibly fails when logging* all ICMP and TCP ping measurements and hence has an empty JSON, but this needs investigation to return better values that don't break UI.

Take into account user agent

When receiving connections from clients, let's take a look at the user agent because it may reveal if we're dealing with a desktop or a mobile device.

Large stderr logfile size due to excessive logging

I currently log all the TCP errors we get when we ping different IPs. This was done to get an idea of what errors are returned when the ports is filtered or closed. This line leads to logging these errors in a particular format in the ErrLogger file.

The file is getting larger as most (now x/24=256 IPs) are getting pinged and have filtered ports. We should analyze the existing log files and then, reduce the amount of logging to ErrLogger done.

Make available code base as Go package

Goncalo and I had a chat about how we're going to integrate the latency measurement code into our reputation service and decided to make available the latency code as Go package, which we then integrate in reputation. Let's use this issue to keep track of this effort.