Off-Path Round Trip Time Measurement via TCP/IP Side Channels Geoffrey Alexander and Jedidiah R. Crandall University of New Mexico, USA
How do you measure something? ● Interact directly ● T ake samples ● Multiple tests 2
Problem How do you measure something you can't access? What about off-path network connections? 3
Motivation ● Internet Censorship – Censored IP address re-binding ● Clear picture of network behavior 4
Contribution ● T echnique for measuring ofg-path RTT – Uses side channel in Linux network stack ● Version 2.6 and higher – RTT = Round T rip Time ● Performs comparably to previous work – 80% of scans within 20% of actual RTT 5
Outline ● Background ● Linux SYN-backlog behavior ● Using SYN-backlog as a Side Channel ● Our T echnique ● Results 6
On-Path Measurements ● Control at least one end host – Not always easy to get access – May not get required privileges ● Provides direct access to network traffjc 7
Ofg-Path Measurements ● No access to either ??? end host ● No direct access to network traffjc – Need to infer behavior – Can use side channels to infer information 8
Side Channels ● Source of Information from a shared resource – CPU timing, power consumption – Shared counters, memory bufgers, etc. ● IPID used as side channel for network scans – Idle scans [1] [2] – Detect ofg-path packet drops [3] [1] Antirez “new tcp scan method”, http://seclists.org/bugtraq/1998/Dec/79 [2] Ensafi, R. et. al. “Idle Port Scanning and Non-Interference Analysis of Network Protocol Stacks Using 9 Model Checking”, USENIX Security 2010 [3] Ensafi, R. et. al. “Detecting intentional packet drops on the Internet via TCP/IP side channels”, PAM 2014
TCP Handshake ● Creates new TCP connection Client Server ● SYNs must be stored SYN during handshake SYN-ACK ● Incomplete connections are “half-open” ACK 10
SYN-backlog ● SYN packets are stored in a bufger known as SYN-backlog until three-way handshake is complete. ● SYN-ACKs for each SYN are sent at set time intervals after fjrst attempt until three-way handshake fjnishes. ● Internally Linux categorizes backlog entries as either “young” or “mature” – “Young” packets have not retransmitted a SYN-ACK 11
SYN-backlog as a side channel ● When backlog is fjlled to or beyond half capacity a retransmission threshold is calculated based on number of “mature” entries ● Entries above this threshold are removed until the backlog size drops below half capacity ● This behavior can be used to infer information about the state of the backlog 12
Our technique ● Using Linux SYN-backlog we developed a technique for estimating RTT between two end hosts ● Perform a binary search using backlog behavior as a comparison operator between estimated and actual RTT ● T echnique divided into three stages – Prepare backlog – Attempt to use backlog as side channel – Infer state information about backlog 14
Our technique ● MM sends SYNs to S S C until the SYN- backlog is almost half fjlled SYN – Leave each “half open” ● Each SYN uses unique sequence number and IPID MM 15
Our technique ● Wait until 2 S C SYN-ACK retransmission RST intervals have elapsed ● Send SYNs to S for Spoofed SYNs 10s at rate based on estimated RTT – Causes S to send SYN-ACKs to C – SYN-ACKs are reset MM 16
Our technique ● MM counts number of S C retransmitted SYN-ACKs for each SYN from Stage 1 ● If all SYNs kept retransmitting then infer SYN-ACK backlog never fjlled past half ● If some stopped retransmitting, infer backlog fjlled past half and removed some entries MM 17
Will this crash the Server? ● Packets sent in short bursts – Not continuous traffjc ● Packets are only headers – Small total size ● SYN backlog never fjlls much past half full – Most connections complete quickly – Regular traffjc should complete as normal 18
Methodology ● Used PlanetLab nodes for Server host – Provided ground truth measurements – No assistance to measurements ● 15 PlanetLab nodes used – Distributed evenly between North America, South American, Europe, Asia, and Australia/New Zealand ● Clients chosen at random from IPv4 address space – Only used if an address meets criteria 19
Results Dataset Within 10% (Percent) Within 20% (Percent) Overall 60.7 81.3 RTT > 25ms 63.6 83.7 RTT < 25ms 18.0 46.1 RTT > 100ms 67.1 87.2 RTT < 100ms 35.5 58.1 25ms < RTT < 100ms 43.5 63.5 ● Measurements for 616 pairs of IP addresses ● Collected from July 14, 2014 to July 28, 2014 20
Results 1.0 Full Dataset No Packet Loss 0.8 Percent of Measurements 0.6 0.4 0.2 0.0 0.0 0.5 1.0 1.5 2.0 Est/Actual RTT CDF of overall results with and without packet loss 21
Efgects of Packet Loss 1.0 1.0 Overall Overall Low RTT Low RTT High RTT High RTT 0.8 0.8 Percent of Measurements Percent of Measurements 0.6 0.6 0.4 0.4 0.2 0.2 0.0 0.0 0.0 0.5 1.0 1.5 2.0 0.0 0.5 1.0 1.5 2.0 Est/Actual RTT Est/Actual RTT Results with packet loss for overall, low (<25ms), and high Results without packet loss for overall, low (<25ms), and (>100ms) estimates high (>100ms) estimates 22
Ethical Considerations ● Traffjc might appear to be Denial of Service – At most send ~800 packets per sec. – Each packet is only 60 bytes in size ● ~48 kilobytes per second – Shouldn't overwhelm modern networks ● Traffjc is sent in bursts – Not continuous like most DoS attacks ● SYN-backlog never fjlls much past half – Regular connections should complete 24
Conclusion ● Using Linux SYN-backlog as side channel ● T echnique for estimating ofg-path RTT values ● Within 20% of actual RTT for ~80% of paths – Similar to previous systems, like King ● Packet loss is largest cause of inaccuracy 25
Future Work ● Improve Accuracy and Speed – Better method for checking SYN removal – Directly probe SYN-backlog ● Find additional side channels – In Linux – In other operating systems ● Windows, OS X, etc. 26
Thank You ● Jed Crandall ● Ben Mixon-Baca and Bianca Bologa ● Xu Zhang ● NSF for funding research 27
Questions 28
Recommend
More recommend
