Traffic Classification

From wiki.measurementlab.net
Jump to: navigation, search

Mechanisms

Detection

Measurement Implementations

References

Degrade performance of certain protocols (e.g TLS) X “Fast Lane” (Net Neutrality) X Traffic differentiation e.g: rate limit slope

Degrading HTTPS performance to disencourage its use

Performance degraded by dropping packets of a TCP connection

Drop some packets to reduce performance

Throttle bandwidth to discourage use ?

Traffic Throttling

Fast lane routes that are not based on efficiency BW throttling X Throttling X Degraded packet routing (drop/delay based on content) Speed Throttling (generally) X Bandwidth throttling X random packet drop Priority Packet Delivery for Favored Services Slow down certain pages (Throttling) Lowering throughput on unknown connections to 1 Bps after time Performance throttling i.e. - lowering priority of SSH


Degrade performance to certain IP prefixes Priority packet delivery for favored services




DPI-based {detection, blocking} of protocols Question Are we blocked? How are we blocked? OONI has a test where the input is a packet trace and it replays the protocol, tweaks it, and iterates

Are there algorithms to tweak it efficiently? “Binary search”?

0) China intentionally only samples traffic in periods of higher load ←- so it misses some censorship 1) What about when the firewall blocks the next ten minutes of all traffic? 2) Or China’s automated followup active probes

Insight: China’s recent strategies have taken the feedback out of the loop.

3) Throttling makes it hard to know if the DPI triggered - and also reduces the collateral fammage of false positives! 4) Is your vantage point representative? Mobile network, hotel network, urban network,...

Censor actions change over time, so any detection strategy we describe must adapt too

So, to measure: 1) do we replay a packet trace, or 2) run the application and see if it bootstraps?

For #2, we need cooperation from the app to know whether it succeeded.

How do we know if the server side got blocked? Need to do baseline network tests before the “real” test

Assumptions Immediate feedback Known unblocked protocols Triggering based on signature matching Tests are reproduceable (No A/B testing) Ability to run unlimited number of tests without being blocked Previous test shows IP addr/port pair unblocked







APP - SPECIFIC THROTTLING

BASELINE

Very close in time to experimental test Junk data? Traffic that “looks” like the original trace? (same timing/volume/different payload) Sent to a helper

EXISTING BASELINE

Same prerecorded data transmitted over VPN (assuming that the VPN itself is not throttled) to/from a controlled “helper” (single point of failure? what if they block it? enhance it’s traffic performanbce?) Close in time Repeated

EXPERIMENT

WE WANT TO MEASURE PERFORMANCE OF SERVICES for all-or-app specific? so, value of service matters drop box want B/W VOIP wants jitter/latency interpacket timing patters sometimes, sometimes does not traffic caps might exist, patience is also be limited


Assumptions and Characteristics Protocol, content or destination triggers also, time of date powerboost usage level by customer <--- isn’t app specific




DEEP PACKET INSPECTION BLOCKING

Assumptions Immediate feedback Known unblocked protocols Triggering based on signature matching Tests are reproducible (No A/B testing) Ability to run unlimited number of tests without being blocked Previous test shows IP addr/port pair unblocked

Test Cases Test side effects of protocol blocking Test block time period Replay TCP Dump and manipulate bytes until protocol is not blocked Start with known unblocked protocol and transform into blocked protocol until blocked Replay TCP Dump and iterate over manipulating until all permutations are exhausted, then find the intersection of all blocked packets to find selectors Test tcpdump from different locations on the network and determine if blocked on larger scale or locally block due to another factor Continually test known unblocked protocol and use as a comparison to prove network connectivity

48 - another wide shot of all the post it notes

49 - repeat of #14

50 - see #46,47

51 (transcription from notepad)

Is one packet trace enough? Depends on what you want to learn.

Insight: Use FTE to generate traces that conform to the protocol But that requires perfectly specifying your protocol or you’ll miss something.

What if they DPI for five things, and block if all five, but throttle if any of the five?

Reframe: 1) Are you blocked? 2) Heuristics /Guidelines for being less blocked.

Insight: here we are trying to design a general solution to this complex problem. Whitelisting vs. Blacklisting! “Be a thing they won’t” rather than “don’t be a thing they don’t want”


52 - repeat of #40


53



PORT BLOCKING DPI-Protocol DPI-Content Port filters DPI for a whitelist of protocols, and drop all unexpected protocols after 60 seconds Terminate or surveil Skype chat conversations based on keyword triggers Port blocking DPI for suspect protocol, then connect to destination, and talk the suspect protocol to confirm. Identify keywords and inject TCP resets Port blocking Protocol Filtering (Based on behavioral heuristics/DPI)

DPI to perform filtering based on certain keywords

Block P2PTorrent) Degrading service to see if the protocol responds like the protocol it’s masquerading as Content + Filtering Firewall/DPI (DPI) - differentiate on basis of port, address, pag/out, etc. - could block or degrade performance

 - drop is also an option

Image recognition based censorship


Block based on protocol detection DPI: Keyword blocking (more recently, protocol blocking) (Eg. IRC packets)



Keyword filtering



Forum keyword **** - ing



Keyword based filtering



Block P2P protocol ports (e.g. Bittorrent) Degrading service to see if the protocol responds like the protocol it’s masquerading as (e.g. Parrot is Dead) Content scanning + filtering Firewall / DPI (DPI) - differentiate on basis of port, address, pag/out, etc. - could block or degrade performance

 - drop is also an option

Image recognition based censorship.


Block based on protocol detection DPI: Keyword blocking (more recently, protocol blocking) (e.g. IRC packets)



Keyword filtering



Forum keyword ****-ing.



Keyword



Locally installed web filters



Client-side HTTP block



OS host firewall



browser plugins



malware



Mandatory OS patches (?facilitating?)


Port blocking DPI for suspect protocol, then connect to destination, and talk the suspect protocol to confirm Identify keywords and inject TCP resets Pork blocking Protocol filtering (Based on behavioral heuristics/DPI)

DPI to perform filtering based on certain keywords

Block P2P protocol ports (e.g. Bittorrent) Degrading service to see if the protocol responds like the protocol it’s masquerading as (e.g. Parrot is Dead) Content scanning + filtering Firewall / DPI (DPI) - differentiate on basis of port, address, pag/out, etc. - could block or degrade performance - drop is also an option Image recognition based censorship


Block based on protocol detection

DPI: keyword blocking (more recently, protocol blocking) (e.g. IRC packets)


Performance Degradation and Censorship Timing on requests, such as port 80 being slower than 443 resulting from caching not working correctly (lots of mobile carriers impose caching, should compare 80 and 443), Some ISPs also do transcoding to replace content on the fly, What is good and bad content? How do we curate lists, since the quality of measurements is dependent upon it, Reputation management -- could someone post content to make a site blocked, creating collateral censorship, Content categorization services: wikileaks has some block lists for countries like Norway, but that is basically all child porn sites; How do we distinguish between network issues and actual censorship? What if censorship isn’t intentional, e.g. rioters knock out power to a colo? how do we differentiate between peering and performance problem; This spills over into DDoS, someone with a lot of content sends down a single link, Areas where encryption is unusual, common to have software on home routers to replace ads, know of one case where from ISP, another case from manufacturer, Difference between poor availability and censorship may be intention, can we truly measure censorship? Availability has borders, and so do ISPs, so what does that mean? Things to improve: Measurements over port 80 and 443, Better lists to test, Detecting things like transcoding; Application Layer Manipulation and Throttling There are reasons why censorship regimes don't block outright, but prefer throttling: Traceroutes don't show entire prefixes as vanished - things are just essentially unusable, Such practices can make inaccessibility seem like technical failing, genuine problem, Making performance suck is more pragmatically coercive than making a site/app disappear; Goal may not be to completely censor everything - but rather to push users towards domestic services which authorities have more access to, control over: Iran shut down Gmail access during week in October 2012 when they were pushing national email providers, China has been very effective at pushing people towards Baidu; Prior and Current Work: My Speed Test: Send traffic in the clear, then replay traffic to a helper server through an encrypted tunnel, for applications such as Netflix, Hulu or Skype, Problems: Protocol use on baseline tests, e.g. UDP over TCP during replay changes the behavior and introduces unknown delays, Need second baseline? (Overhead of TCP connection); Informal Quantitative Methods: Used downloading Firefox or other content over HTTP, HTTPS as test case, In Iran difference was pronounced: HTTPS was 3% of HTTP capacity, Used SCTP to derive baseline (no one knows about it); Interference techniques used: Traffic shaping of particular applications down to extremely low bitrate, TCP resets, Generalized throttling, e.g. Iran slowing down to 80% of normal capacity; Onset of throttling very closely correlated with political events; How to accomodate the problem of measurement bias, such as error associated with VPN use; Longitudinal study with multiple datapoints, Reproducable results derived from multiple clients, Overhead should stay the same, and any changes to interference infrastructure should show up through the noise -- although changes will be necessary over time; Many wireless carriers have policies that proscribe the use of P2P apps, video streaming, etc; Problem: We still need to establish a clean baseline -- this may be a major challenge for any study in this domain: What constitutes a good baseline? Is it some measure of the max capacity of the network, or the most stable measure? What if we used a combination of different measures as baseline? We can delay the decision about what the baseline should be - we just need to make absolutely sure that have points of comparison, We shouldn't make any normative assumptions about baselines, particularly in contexts where everything could be blocked - we should only make comparative statements: x type of traffic is slower than y, Throttling could be done on a whitelist basis - making the baseline "throttled", VoIP: Very difficult to detect throttling, because even small increases in latency can make the tech completely unusable One major challenge for all censorship measurement: differentiating between incompetence and blocking - particularly when authorities have learned to hide censorship as incompetence, e.g. China changing its DNS from returning NX to returning random domain; Field knowledge is essential, to suss out some of these issues;


Application Layer Throttling Differentiation detection: Replay traffic (not directly) through the clear and through VPN to look for differences in throughout (My Speed Test approach is with PCAP files), Assumptions for ensuring a foundational and valid baseline: Wireless environments and conditions are constant between comparative tests, Traffic is differentiated is by content and request type, That there is no difference based upon destination, No VPN throttling (or could measure VPN throttling itself), therefore Must tease apart the various ways that conditions can affect performance that are not the censorship or intentional interference of interest; Infrastructure: Cell phones in a lab tethered to a laptop, Support for users to run tests on their own from the phone itself, Replay boxes in providers to add detection of throttling;