Consider adding JA4L Light Distance information for TCP and UDP (QUIC)

[marcb]

Low priority feature enhancement would be to consider supporting JA4L Light Distance to estimate the distance between the initiating host and the destination where target port is specified and that port supports handshakes.

[fujiapple852]

Thanks @marcb - I was not aware of JA4L, an interesting technique.

For TCP, Trippy currently defers the 3-way handshake to the OS rather than sending raw syn packets for reasons of platform compatibility.

Most platforms allow you to send these packets with a raw socket but do not deliver the responses back the application, something like a TUN device would be needed for that.

I wonder if OSs provides access to timing information about the TCP handshake? If not, the best Trippy could do would be to measure the cost of connect call which should only represent the cost of sending the outgoing syn, receiving the incoming syn+ack and sending the final ack of the 3-way handshake.

Trippy doesn't use higher layer protocols like QUIC (maybe it should?), but this could be added for UDP where it already measures the latency between the probe being send and the response being received. Trippy already has the ttl information for each hop and so should be able to avoid having to estimate it as JA4L does.

[marcb]

Thanks @fujiapple852 for considering. I understand. I figure a lot of JA4 techniques will be better achieved via eBPF and/or TLS library extensions / instrumentation.

JA4L is probably really useful when probing a destination from a number of geographically disperse locations - triangulation. So I figure in the context of trippy that would mean having to run multiple disperse instances and doing the math. To me that sort of steps away from trippy's raison d'être.

[fujiapple852]

@marcb a few (vaguely defined and unplanned) long term ideas I have for Trippy are:

• Support for operating at layer 2/3 for all protocols (via TAP/TUN and/or eBPF)
• Support for host fingerprinting, such as Identify router from hostname  #532 and also with techniques similar to those shown in JA4
• Support for running simultaneously bidirectional traceroute (with some back channel control plane between instances of Trippy)
• Support for triangulation and timing based GeoIp

So what you are suggesting fits well with this. I'm also keen to keen Trippy narrowly focused on the core tracing functionality and not become bloated with general networking tools/features.