detecting icmp rate limiting n.
Skip this Video
Loading SlideShow in 5 Seconds..
Detecting ICMP Rate-Limiting PowerPoint Presentation
Download Presentation
Detecting ICMP Rate-Limiting

Loading in 2 Seconds...

play fullscreen
1 / 17

Detecting ICMP Rate-Limiting - PowerPoint PPT Presentation

  • Uploaded on

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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Detecting ICMP Rate-Limiting' - athalia

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
detecting icmp rate limiting

Detecting ICMP Rate-Limiting

Les Cottrell

Warren Matthews

Mit Shah

motivation 1
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”
motivation 2
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
icmp blocking no response
ICMP Blocking - No Response!
  • blocked 884 rounds of 10 ICMP packets each, out of 903
  • blocked 554 out of 903 rounds
  • blocked all packets it was sent (All examples from data for Dec 1999)
  • Yet in reality, none of these servers was down!
new tools to the rescue
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
results from sting synack
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!
utility of sting as an aid
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!
tail drop behavior
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!
frequency analysis
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!
car committed access rate
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
red random early detection
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!
extended burst mechanism in car
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
detecting car the good news
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!
detecting car a trial
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!
detecting car the bad news
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!!!
further study
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