1 / 17

Detecting ICMP Rate-Limiting

Detecting ICMP Rate-Limiting. Les Cottrell Warren Matthews Mit Shah. Motivation 1. Smurf Attacks : IP spoofing and ICMP packets to an IP Broadcast group. Traffic to target multiplied by responses from each member

athalia
Download Presentation

Detecting ICMP Rate-Limiting

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Detecting ICMP Rate-Limiting Les Cottrell Warren Matthews Mit Shah

  2. Motivation 1 • Smurf Attacks : IP spoofing and ICMP packets to an IP Broadcast group. Traffic to target multiplied by responses from each member • Example : Attacker on 768Kbps stream and a 100 member Broadcast group generate 77Mbps of traffic and swamp target! • Routers set to : “no ip directed-broadcast”

  3. Motivation 2 • Cisco introduces CAR (Committed Access Rate) in 7200 and 7500 series routers. Later includes support in IOS 12.0 • access-list 102 permit icmp any any echo • interface Serial3/0/0 rate-limit input access-group 102 256000 8000 8000 conform-action transmit exceed-option drop

  4. ICMP Blocking - No Response! • www.vincy.bg.ac.yu blocked 884 rounds of 10 ICMP packets each, out of 903 • islamabad-server2.comsats.net.pk blocked 554 out of 903 rounds • leonis.nus.edu.sg blocked all packets it was sent (All examples from data for Dec 1999) • Yet in reality, none of these servers was down!

  5. SYNACK developed in-house Establishes TCP connections and measures time taken by target to respond Cleans up connections Highly visible to system admins STING developed by Stefan Savage TCP can’t ack out-of-order packets Data-seeding and Hole-filling (reliable) Need to change one line of kernel code New tools to the rescue

  6. Results from Sting & Synack • Both tools based on TCP/IP, hence appear to router to be “normal” traffic • Results : • The Singapore node responds ONLY to 56+8 byte packets • Both the other nodes were alive-and-kicking with low loss rates!

  7. Utility of Sting as an aid • These are 5 sites that were responding to pings very infrequently, and neglecting entire sets of 10 pings more than 50% of the time • Sting showed that they were alive on port 80!

  8. Tail-Drop Behavior • Rate-limiting kicks in after the first few packets and hence later packets are more likely to be dropped • This node no longer displays tail-drop behavior!

  9. Frequency Analysis • Calculate the packet drops as a function of packet-numbers • Calculate the slope and identify extremes • Implemented by Warren as a metric • Some encouraging early results!

  10. Some Candidates :

  11. CAR (Committed Access Rate) • Tokens removed in proportion to size of packet • Maximum number of tokens in bucket = Normal Burst Size • Extended Burst mechanism to make drops more RED-like

  12. RED (Random Early Detection) • Tail-drop causes packet-loss across all TCP streams when traffic is too heavy • Causes all TCP-streams to sense congestion and start recovery • Small, bursty TCP streams also have to restart • Solution : drop packets randomly BEFORE congestion strikes!

  13. Extended Burst Mechanism in CAR • Stream allowed to borrow more tokens if extended-burst value > normal-burst • “ Compounded debt” computed as sum of a(j) where j denotes the jth packet that tries to borrow tokens since last packet drop and a(j) denotes actual debt value • Packet dropped if CD > extended-burst and CD set to 0

  14. Detecting CAR : the good news • A stream at constant rate R, above the configured-rate C, will exhaust tokens in bucket after B/(R-C) sec, at most • From this point on, borrowed packets at jth packet = j*(R-C) and beyond j=E/(R-C), actual debt > extended-burst and all packets will be dropped • Pattern is non-random!

  15. Detecting CAR : A trial • Analyzed the first-order differences in packet-numbers of dropped packets to see if there was a pattern hoping that site-specific CAR might have set packet-size > normal_burst_size + extended_burst_size • Not surprisingly, no results • False alarm : 10th packet being dropped but data was TOO clean!

  16. Detecting CAR : the bad news • It appears that most sites will impose a traffic-limit on TOTAL icmp traffic • Predicting when a packet drop occurs akin to predicting the rest of the traffic on that router at that moment - a known “hard” problem! • Solution : Aggressive pinging, your traffic-stream dominates! High signal-to-noise!!!

  17. Further study • Pinging with variable-sized packets (less than MTU) and detect whether packet-loss varies linearly with size • trivial to determine MTU? • How important are other effects like being more likely to be dropped from queue? • Set up a router that implements CAR, simulate icmp traffic, and study patterns

More Related