the internet s not a big truck
play

The Internets Not a Big Truck: Toward Quantifying Network Neutrality - PowerPoint PPT Presentation

The Internets Not a Big Truck: Toward Quantifying Network Neutrality Robert Beverly, Steven Bauer, Arthur Berger {rbeverly,bauer,awberger}@csail.mit.edu PAM 2007 It's not a big truck. It's a series of tubes! Network Neutrality:


  1. The Internet’s Not a Big Truck: Toward Quantifying Network Neutrality Robert Beverly, Steven Bauer, Arthur Berger {rbeverly,bauer,awberger}@csail.mit.edu PAM 2007

  2. It's not a big truck. It's a series of tubes! � Network Neutrality: � Actively debated/discussed by politicians, regulators and researchers � But…many definitions! � And…no measurements! � We focus on one important, well-defined dimension: “ port blocking ” 4/11/2007 R. Beverly, S. Bauer, A. Berger 2

  3. Internet Port Blocking � Background � Methodology � Initial Results 4/11/2007 R. Beverly, S. Bauer, A. Berger 3

  4. Internet Port Blocking � This work: Active/Passive hybrid measurement approach � Main contribution: � Novel leverage of P2P overlay for large- scale Internet measurements � Promising results: � First measurements of “Network Neutrality” 4/11/2007 R. Beverly, S. Bauer, A. Berger 4

  5. Port Blocking for Policy � Port blocking: policy control that relies on coupling between applications and port � IANA Well-known port assignments � We focus on TCP port blocking, examples: � Comcast blocks outgoing port 25 (SMTP, prevent botnet spamming) � Michigan blocks incoming ports 135, 137, 139 (Microsoft file sharing) � UCI blocks port 1433 (MS-SQL) 4/11/2007 R. Beverly, S. Bauer, A. Berger 5

  6. Blocking and Neutrality � ISPs may block for altruistic reasons: � MS-SQL worm � NetBIOS, etc. � ISPs may block competing services: � Force use of SMTP gateway � Madison River Ruling [United States FCC] � We seek to inform the debate � We do not argue legitimacy or justifiability 4/11/2007 R. Beverly, S. Bauer, A. Berger 6

  7. Measuring Port Blocking � Design Criteria: � Generality : Test arbitrary ports � Range : Test a wide range of networks � Quantity : Large number of tests � Minimal participation : Assume no active cooperation from remote hosts � Approach: Referral Super Peer (RSP) 4/11/2007 R. Beverly, S. Bauer, A. Berger 7

  8. Internet Port Blocking � Background � Methodology � Initial Results 4/11/2007 R. Beverly, S. Bauer, A. Berger 8

  9. Referral Super Peer � RSP is a “normal” Gnutella Super Peer � Abides by Gnutella protocol � Bootstraps into Super Peer Mesh with standard GWebCache mechanisms Induces clients which connect to the RSP to probe for port blocking as part of their natural overlay formation process 4/11/2007 R. Beverly, S. Bauer, A. Berger 9

  10. Infrastructure High-Level 1. Connect Super Peer Gnutella Referral Super 2. “Busy, try peer Client Super Peer Peer a.b.c.d:25” Super Peer Measurement 3. TCP SYN to a.b.c.d:25 Super Peer 4/11/2007 R. Beverly, S. Bauer, A. Berger 10

  11. RSP is Innocuous! � Does not disrupt or degrade overlay � RSP and Measurement SP do not serve any content (no legality question) � RSP only redirects clients (not harmful) � Measurement SP is a real SP, once connected, clients receive service � In fact, long-lived, high-bandwidth Super Peers help Gnutella network 4/11/2007 R. Beverly, S. Bauer, A. Berger 11

  12. Infrastructure High-Level � Want to measure at a BGP prefix granularity: � Tie system into BGP database � Maintain per-IP per-CIDR state: � Tie system to a SQL database � Bias initial search toward contentious ports: P2P, SMTP, VPN, VoIP, etc. 4/11/2007 R. Beverly, S. Bauer, A. Berger 12

  13. Full Methodology Gnutella Gnutella Network 1. Connect from c Network Gnutella 2. Lookup b=IP(c) BGP Client 3. Return b DB Referral 6. Try a.b.c.d:p Super Peer 4. Lookup NextPort(b) DB 5. Return p 7. Connect a.b.c.d:p Super NextPort MUX Peer Updater 4/11/2007 R. Beverly, S. Bauer, A. Berger 13

  14. A Map of Internet Port Blocking � Devil in the details… � Consider a busy referral for port p to client c residing in CIDR b � Observe TCP SYN from c for p : � p is not blocked on path from b � b is neutral to applications using p � No TCP SYN from c for p implies either: � p is blocked on path from b � c ignored referral 4/11/2007 R. Beverly, S. Bauer, A. Berger 14

  15. Probabilistic Inference � Empirical prior probability � For 99.5% probability that i non-responsive referrals indicates b blocks p : � P(n(p,b)=0|H(p,b,i)=0) = 0.995 � Solution (see paper for formal derivation): � i=log 0.9 (0.005) ≈ 50 Must send and not observe responses for ~50 referrals to clients in b for port p to conclude that p is blocked on the path from b 4/11/2007 R. Beverly, S. Bauer, A. Berger 15

  16. Why Gnutella? � Exploit the Gnutella P2P overlay to easily: � Globally advertise a service � Draw (lots of) incoming connections toward us � Gnutella is estimated at ~3.5M users � Test large portions of the Internet topology � Method is general; any service which allows arbitrary IP:port redirection suffices � Current work using same ideas with HTTP 4/11/2007 R. Beverly, S. Bauer, A. Berger 16

  17. Internet Port Blocking � Background � Methodology � Initial Results 4/11/2007 R. Beverly, S. Bauer, A. Berger 17

  18. Measurement Bias � Unbiased measurements from non-trivial portion of Internet (~31k prefixes ≈ 15% of Internet) � Cannot measure networks that disallow Gnutella content filtering � RSP listens on non-default port to avoid Gnutella port blocking � Networks we don’t measure could block more, fewer or different ports than we find 4/11/2007 R. Beverly, S. Bauer, A. Berger 18

  19. Efficacy of Methodology � Collected data for two months: October to December 2006 � ~31k unique BGP prefixes � ~1M TCP connections � ~72k unique Gnutella clients � ~150k referrals sent 4/11/2007 R. Beverly, S. Bauer, A. Berger 19

  20. Size of Network � First question: what is the rate of new unique clients and BGP prefixes? 4/11/2007 R. Beverly, S. Bauer, A. Berger 20

  21. Rate of New Clients Slope remains high across measurement period Maintenance period 4/11/2007 R. Beverly, S. Bauer, A. Berger 21

  22. System Performance � Second question: how well does the system allow us to make inferences? 4/11/2007 R. Beverly, S. Bauer, A. Berger 22

  23. Fraction of Ports Classified Within Each Prefix Can’t make any inferences over ~%55 of all prefixes Classified >50% of tested ports for ~13k prefixes 4/11/2007 R. Beverly, S. Bauer, A. Berger 23

  24. Initial Results � Given our observations, which ports are more likely to be blocked relative to others? 4/11/2007 R. Beverly, S. Bauer, A. Berger 24

  25. Control Port Control Port : Not associated with any service, unlikely to be blocked. Use to calibrate our measurements. 4/11/2007 R. Beverly, S. Bauer, A. Berger 25

  26. Gnutella Blocking Gnutella Port : As expected, the lowest blocking percentage. Non-zero; attributable to hosts using non-standard ports. 4/11/2007 R. Beverly, S. Bauer, A. Berger 26

  27. HTTP Blocking HTTP Port : Matches intuition that HTTP is rarely blocked. Only control and Gnutella are lower. Non-zero attributable to proxies. 4/11/2007 R. Beverly, S. Bauer, A. Berger 27

  28. MS-SQL Blocking MS-SQL Port : Blocking shows prominently three years after Slammer worm outbreak. Implies filtering rules are long-lived. 4/11/2007 R. Beverly, S. Bauer, A. Berger 28

  29. Email Blocking Email : Ports associated with email more than twice as likely to be blocked as the control port! 4/11/2007 R. Beverly, S. Bauer, A. Berger 29

  30. Collateral Damage Profile Port : Most frequently blocked! Innocuous port between Microsoft file sharing ports: 135,137,138,139. 4/11/2007 R. Beverly, S. Bauer, A. Berger 30

  31. Future Analysis � Determine relationship between blocking and type of prefix (business, .edu, ISP, etc) � Determine geographical distribution of blocking � Use AS topology to make inferences on where filtering is employed � Evolution of blocking over time 4/11/2007 R. Beverly, S. Bauer, A. Berger 31

  32. Future Work � Continue to collect measurements, increase our degree of confidence � TCP Traceroutes: � Port-specific traceroutes to determine ingress filtering properties � Traceroutes allow us to determine where blocking occurs, filtering asymmetry, etc. � Second methodology in progress employing HTTP using techniques outlined in this work 4/11/2007 R. Beverly, S. Bauer, A. Berger 32

  33. Research Summary � Novel use of P2P overlay for measurement � First measurements of Internet port blocking � Initial results suggest promising avenue for systematic large-scale measurement Thanks! Questions? 4/11/2007 R. Beverly, S. Bauer, A. Berger 33

Recommend


More recommend