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

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend