Hi Jim, On Fri, May 02, 2014 at 04:13:40PM +0100, Jim Rippon wrote: > Hi all, > > As mentioned on the IRC channel today, I have a > requirement to extract an end users IP address from the TCP Options > Header (in my case with key 34 or 0x22, but there are other similar > implementations using 28 or 0x1C). This header is being added by some > Application Delivery Optimisation solutions by providers such as Akamai > (with their IPA product line) and CDNetworks (with their DNA product) > though there are likely others out there hijacking the TCP headers this > way.
Cool, I'm happy that some people start to use TCP options for this, it could drive forward improved APIs in various operating systems to help retrieve these options. We designed the PROXY protocol precisely as an alternative for the lack of ability to access these. > Because the options headers won't be forwarded by haproxy to the > back-end servers, the most useful way to deal with this for our http > services would be to extract the IP address encoded and place it into > either the X-Forwarded-For or X-Real-IP headers, so that it can be > understood and handled by the upstream servers. > > Sample implementations > can be found in documentation from F5 [1] and Citrix [2] below. In the > TCP SYN packet (and some later packets, but always in the initial SYN) > we see the option at the end of the options header field like so in our > packet capture: > > 22 06 ac 10 05 0a > > Broken down, we have: > > 22 => TCP > Options Header key (34 in this case with CDNetworks) > > 06 => Field size > - this appears to include the key, this size field and the option value > > > ac 10 05 0a => the IP address of the end-user - faked in this example > to private address 172.16.5.10 > > This would be hugely useful > functionality - it would allow us to avoid the expense of high-end load > balancer devices and licenses to support testing of our CDN > implementations before going into production. Sure it would be great, and even better if we could set them. The only problem is that there is no way to retrieve these information from userland. The option is present in the incoming SYN packet, is not recognized by the kernel which skips it, and as soon as the system responds with the SYN/ACK, the information is lost. Are you aware of kernel patches to retrieve these options ? If at least one of them is widely deployed, we could consider implementing support for it, just like we did in the past with the cttproxy or tcpsplicing patches. Best regards, Willy
