Security Analysis of the Micro Transport Protocol with a Misbehaving - PowerPoint PPT Presentation

Security Analysis of the Micro Transport Protocol with a Misbehaving Receiver Security Analysis of the Micro Transport Protocol with a Misbehaving Receiver Florian Adamsky, Syed Ali Khayam, Rudolf Jäger and Muukrishnan Rajarajan The 4th International Conference on Cyber-Enabled Distributed Computing and Knowledge Discovery 2012 B. Sc. Florian Adamsky | CyberC 2012 1 / 26 florian@adamsky.it http://florian.adamsky.it

Security Analysis of the Micro Transport Protocol with a Misbehaving Receiver Contents 1 Introduction Background 2 Aack Details and Results Aack 1: Lying about the Delay Aack 2: Lazy Opt-Ack Aack 3: Opt-Ack 3 Countermeasures Randomly Skipped Packets 4 Conclusions B. Sc. Florian Adamsky | CyberC 2012 2 / 26

Security Analysis of the Micro Transport Protocol with a Misbehaving Receiver | Introduction Contents 1 Introduction Background 2 Aack Details and Results Aack 1: Lying about the Delay Aack 2: Lazy Opt-Ack Aack 3: Opt-Ack 3 Countermeasures Randomly Skipped Packets 4 Conclusions B. Sc. Florian Adamsky | CyberC 2012 3 / 26

Security Analysis of the Micro Transport Protocol with a Misbehaving Receiver | Introduction Introduction BitTorrent is the most widely used Peer-to-Peer (P2P) application Before December 2008, TCP was its default transfer protocol Since this date, uTorrent switched from TCP to the Micro Transport Protocol (uTP) which is based on UDP B. Sc. Florian Adamsky | CyberC 2012 4 / 26

Security Analysis of the Micro Transport Protocol with a Misbehaving Receiver | Introduction | Background What’s the problem with TCP and BitTorrent? BitTorrent is in most cases background traffic BitTorrent uses multiple connection at once TCP distributes the available bandwidth evenly across connections The more connections one application uses, the larger the share of bandwidth Old Solution: Configure bandwidth limit Requires knowledge about the own Internet connection Oen lets big head room which is unused Bad configured BitTorrent client can harm other people in the network B. Sc. Florian Adamsky | CyberC 2012 5 / 26 ⇒ Novel transport protocol based on UDP: Micro Transport Protocol (uTP)

e next Internet meltdown? http://www.theregister.co.uk/2008/12/01/richard_bennett_utorrent_udp/print.html

Why the sky isn’t falling http: //arstechnica.com/old/content/2008/12/utorrents-switch-to-udp-and-why-the-sky-isnt-falling.ars

uTP traffic . Security Analysis of the Micro Transport Protocol with a Misbehaving Receiver | Introduction | Background .. B. Sc. Florian Adamsky | CyberC 2012 All Traffic (except uTP) . . . . Bandwidth . Time . . . Traffic . Micro Transport Protocol (uTP) . Scales beer when sending over many connections at once Detects foreground traffic and automatically slows down Advantages: SACK uses a 32 bitmask where each bit represents a packet Sequence numbers and ACKs refer to packets, not bytes Differences to TCP Sequence numbers and ACK numbers Window based flow control Similarities to TCP Transport (LEDBAT) Introduces a new congestion control: Low Extra Delay Background uTP is a reliable transport protocol which makes use of UDP 8 / 26 No congestion control (Slow-start, congestion avoidance, …) → LEDBAT

Security Analysis of the Micro Transport Protocol with a Misbehaving Receiver | Introduction | Background .. B. Sc. Florian Adamsky | CyberC 2012 All Traffic (except uTP) . . . . Bandwidth . Time . . . Traffic . Micro Transport Protocol (uTP) Sequence numbers and ACK numbers uTP is a reliable transport protocol which makes use of UDP Introduces a new congestion control: Low Extra Delay Background Transport (LEDBAT) Similarities to TCP Window based flow control Differences to TCP . Sequence numbers and ACKs refer to packets, not bytes SACK uses a 32 bitmask where each bit represents a packet Advantages: Detects foreground traffic and automatically slows down Scales beer when sending over many connections at once 8 / 26 No congestion control (Slow-start, congestion avoidance, …) → LEDBAT uTP traffic .

Security Analysis of the Micro Transport Protocol with a Misbehaving Receiver | Introduction | Background LEDBAT (Congestion Control) B. Sc. Florian Adamsky | CyberC 2012 IETF just tries to standardize LEDBAT (Dra 09³) ACKs during one window And also: . . 9 / 26 . . Receiver LEDBAT uses one way delay as the main congestion measurement . Will be compared with previous values (not absolute values) Sender . t [ s n d D a t a ] ∆ t = t rcv − t snd ∆ ] K C A [ t Packet loss (max_window = max_window × 0 . 78 ) ³ http://tools.ietf.org/id/draft-ietf-ledbat-congestion-09.txt

Security Analysis of the Micro Transport Protocol with a Misbehaving Receiver | Aack Details and Results Contents 1 Introduction Background 2 Aack Details and Results Aack 1: Lying about the Delay Aack 2: Lazy Opt-Ack Aack 3: Opt-Ack 3 Countermeasures Randomly Skipped Packets 4 Conclusions B. Sc. Florian Adamsky | CyberC 2012 10 / 26

Security Analysis of the Micro Transport Protocol with a Misbehaving Receiver | Aack Details and Results | Aack 1: Lying about the Delay Sender B. Sc. Florian Adamsky | CyberC 2012 . . Aack Idea 1 (Delay Measurement) . . 11 / 26 . . How to do that? more packets into the network .. Lying about the one way delay to induce the sender to send more and Idea . Aacker A t s n [ D d a t a ] ∆ t = 1 ms ∆ ] K C A [ t

Security Analysis of the Micro Transport Protocol with a Misbehaving Receiver | Aack Details and Results | Aack 1: Lying about the Delay Delay Calucation B. Sc. Florian Adamsky | CyberC 2012 delay_factor delay_factor Code Snippet delay_factor 12 / 26 4 1 2 scaled_gain = MAX_CWND_INCREASE_PACKETS_PER_RTT * delay_factor * window_factor; max_window += scaled_gain; ⃗ 100 ms − min ( our _ hist ) = 100 ms 100 ms − 0 = 100 ms = 1

Bandwidth Usage (100 MiB File Transfer) Time in Seconds . . . . . . . . . Packets per Second . . . Without Aack . . . Delay Aack . . . . . . . . . 6 , 000 5 , 000 4 , 000 3 , 000 2 , 000 1 , 000 0 . 0 20 40 60 80 100 120 140 160 180

Security Analysis of the Micro Transport Protocol with a Misbehaving Receiver | Aack Details and Results | Aack 2: Lazy Opt-Ack Aack Idea 2 (Packet loss) .. Idea . We do not inform the sender about packet loss How to do that? As an aacker we’re not interested in data integrity Save all packets we got sequentially and not according to there sequence number B. Sc. Florian Adamsky | CyberC 2012 14 / 26

Security Analysis of the Micro Transport Protocol with a Misbehaving Receiver | Aack Details and Results | Aack 2: Lazy Opt-Ack . . 0 . 0 . 1 . 1 . 3 2 Aack: Packet sorting sequentially . 3 . 4 . 5 . 6 . 4 B. Sc. Florian Adamsky | CyberC 2012 . 4 Aack Idea 2 2 Normal packet sorting . . 0 . 0 . 1 . 1 . . . Packet Loss . 3 . 3 . 4 . 5 . 6 15 / 26

Security Analysis of the Micro Transport Protocol with a Misbehaving Receiver | Aack Details and Results | Aack 2: Lazy Opt-Ack . . 0 . 0 . 1 . 1 . 3 2 Aack: Packet sorting sequentially . 3 . 4 . 5 . 6 . 4 B. Sc. Florian Adamsky | CyberC 2012 . 4 Aack Idea 2 2 Normal packet sorting . . 0 . 0 . 1 . 1 . . . Packet Loss . 3 . 3 . 4 . 5 . 6 15 / 26

Security Analysis of the Micro Transport Protocol with a Misbehaving Receiver | Aack Details and Results | Aack 2: Lazy Opt-Ack . . . . . Time in Seconds . Packets per Second . . . Without Aack . . Delay Aack . . Lazy Opt-Ack Aack B. Sc. Florian Adamsky | CyberC 2012 Bandwidth Usage with Loss Aack 16 / 26 . . . . . . . . . . . 6 , 000 4 , 000 2 , 000 0 . 0 20 40 60 80 100 120 140 160 180

Security Analysis of the Micro Transport Protocol with a Misbehaving Receiver | Aack Details and Results | Aack 3: Opt-Ack Set all bits of the SACK bitmask to the value 1 B. Sc. Florian Adamsky | CyberC 2012 1 with this code 1 Aack Idea 3 (Selective Acknowledgment) Replace that code: Again: As an aacker we’re not interested in data interested How to do that? Pretend that we got all packets always via SACK . Idea .. 17 / 26 uint m = 0; // SACK bitmask uint m = UINT_MAX; // SACK bitmask

Security Analysis of the Micro Transport Protocol with a Misbehaving Receiver | Aack Details and Results | Aack 3: Opt-Ack Without Aack . . . Time in Seconds . Packets per Second . . . . . . Delay Aack . . Lazy Opt-Ack Aack . . Opt-Ack Aack B. Sc. Florian Adamsky | CyberC 2012 Bandwidth Usage with SACK Aack 18 / 26 . . . . . . . . . . . . 6 , 000 4 , 000 2 , 000 0 . 0 20 40 60 80 100 120 140 160 180

Bandwidth from all Aacks . . . . . . . . . Average Bandwidth Usage in Mbit/s . . . . Opt-ACK . . . . . . . 25 23 . 84 20 15 . 39 15 10 6 . 2 5 . 43 5 w/o Aack . Delay Aack . Lazy Opt-ACK .

Security Analysis of the Micro Transport Protocol with a Misbehaving Receiver | Aack Details and Results | Aack 3: Opt-Ack Delay Aack B. Sc. Florian Adamsky | CyberC 2012 42 % Opt-Ack Aack 7 % Lazy Opt-Ack Aack 0 % 0 % Can we create Congestion? Without Aack Packet loss Client Results Parallel to this file transfer via uTP Constant 50 Mbit/s UDP stream with iPerf Congestion Experiment 20 / 26