Docstoc

ICMP Rate-Limiting

Document Sample
ICMP Rate-Limiting Powered By Docstoc
					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 Example : Attacker on 768Kbps stream and a 100 member Broadcast group generate 77Mbps of traffic and swamp target! Routers set to : “no ip directedbroadcast”

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!








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!

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 outof-order packets Data-seeding and Hole-filling (reliable) Need to change one line of kernel code

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-andkicking with low loss rates!

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


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








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!

Some Candidates :

Remote-Node www.wits.ac.za eros.cnea.gov.ar df.uba.ar main.tirana.al . sun.ihep.ac.cn www.uzsci.net ffden-1.phys.uaf.edu sci.am

Jan-00 -3.297 0.218 -0.691 -0.691 -0.788 -1.564 -0.018

Dec-99 -31.152 -1.521 -6.455 -1.97 -5.418 -4.891 -0.945 -3.333

Nov-99 -1.964 . -1.036 -6.667 -3.03 -3.479 -1.042 . -3.497 -2.115

Oct-99 . -1.442 -6.309 -3.418 -1.485 . -3.497 -1.309

Sep-99 .

Aug-99

0.594 -44.806 -5.188 -4.667 -4.121 . -2.133 -2.582 . -1.994 -0.212 -2.812 .

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 REDlike

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






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






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/(RC), actual debt > extended-burst and all packets will be dropped Pattern is non-random!

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






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-tonoise!!!

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


				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:206
posted:11/3/2009
language:English
pages:17