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

▶
the internet s not a big truck
SMART_READER_LITE
LIVE PREVIEW

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

Jan 31, 2023 32 likes •363 views

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:

slide-1
SLIDE 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

slide-2
SLIDE 2

4/11/2007

  • R. Beverly, S. Bauer, A. Berger

2

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”

It's not a big truck. It's a series of tubes!

slide-3
SLIDE 3

4/11/2007

  • R. Beverly, S. Bauer, A. Berger

3

Internet Port Blocking

Background Methodology Initial Results

slide-4
SLIDE 4

4/11/2007

  • R. Beverly, S. Bauer, A. Berger

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”

slide-5
SLIDE 5

4/11/2007

  • R. Beverly, S. Bauer, A. Berger

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)

slide-6
SLIDE 6

4/11/2007

  • R. Beverly, S. Bauer, A. Berger

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

slide-7
SLIDE 7

4/11/2007

  • R. Beverly, S. Bauer, A. Berger

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)

slide-8
SLIDE 8

4/11/2007

  • R. Beverly, S. Bauer, A. Berger

8

Internet Port Blocking

Background Methodology Initial Results

slide-9
SLIDE 9

4/11/2007

  • R. Beverly, S. Bauer, A. Berger

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

  • verlay formation process
slide-10
SLIDE 10

4/11/2007

  • R. Beverly, S. Bauer, A. Berger

10

Infrastructure High-Level

Referral Super Peer Super Peer Super Peer Super Peer

Gnutella Client Measurement Super Peer

  • 1. Connect
  • 2. “Busy, try peer

a.b.c.d:25”

  • 3. TCP SYN to a.b.c.d:25
slide-11
SLIDE 11

4/11/2007

  • R. Beverly, S. Bauer, A. Berger

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

slide-12
SLIDE 12

4/11/2007

  • R. Beverly, S. Bauer, A. Berger

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.

slide-13
SLIDE 13

4/11/2007

  • R. Beverly, S. Bauer, A. Berger

13

Full Methodology

Gnutella Network Gnutella Network

Referral Super Peer

Gnutella Client

Super Peer

MUX

DB BGP DB

NextPort Updater

  • 1. Connect from c
  • 2. Lookup b=IP(c)
  • 3. Return b
  • 4. Lookup NextPort(b)
  • 5. Return p
  • 6. Try a.b.c.d:p
  • 7. Connect a.b.c.d:p
slide-14
SLIDE 14

4/11/2007

  • R. Beverly, S. Bauer, A. Berger

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

slide-15
SLIDE 15

4/11/2007

  • R. Beverly, S. Bauer, A. Berger

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=log0.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

slide-16
SLIDE 16

4/11/2007

  • R. Beverly, S. Bauer, A. Berger

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

slide-17
SLIDE 17

4/11/2007

  • R. Beverly, S. Bauer, A. Berger

17

Internet Port Blocking

Background Methodology Initial Results

slide-18
SLIDE 18

4/11/2007

  • R. Beverly, S. Bauer, A. Berger

18

Measurement Bias

Unbiased measurements from non-trivial portion

  • f 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

slide-19
SLIDE 19

4/11/2007

  • R. Beverly, S. Bauer, A. Berger

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

slide-20
SLIDE 20

4/11/2007

  • R. Beverly, S. Bauer, A. Berger

20

Size of Network

First question: what is the rate of new unique clients and BGP prefixes?

slide-21
SLIDE 21

4/11/2007

  • R. Beverly, S. Bauer, A. Berger

21

Rate of New Clients

Slope remains high across measurement period Maintenance period

slide-22
SLIDE 22

4/11/2007

  • R. Beverly, S. Bauer, A. Berger

22

System Performance

Second question: how well does the system allow us to make inferences?

slide-23
SLIDE 23

4/11/2007

  • R. Beverly, S. Bauer, A. Berger

23

Fraction of Ports Classified Within Each Prefix

Classified >50% of tested ports for ~13k prefixes Can’t make any inferences

  • ver ~%55
  • f all

prefixes

slide-24
SLIDE 24

4/11/2007

  • R. Beverly, S. Bauer, A. Berger

24

Initial Results

Given our observations, which ports are more likely to be blocked relative to

  • thers?
slide-25
SLIDE 25

4/11/2007

  • R. Beverly, S. Bauer, A. Berger

25

Control Port

Control Port: Not associated with any service, unlikely to be blocked. Use to calibrate our measurements.

slide-26
SLIDE 26

4/11/2007

  • R. Beverly, S. Bauer, A. Berger

26

Gnutella Blocking

Gnutella Port: As expected, the lowest blocking percentage. Non-zero; attributable to hosts using non-standard ports.

slide-27
SLIDE 27

4/11/2007

  • R. Beverly, S. Bauer, A. Berger

27

HTTP Blocking

HTTP Port: Matches intuition that HTTP is rarely blocked. Only control and Gnutella are

  • lower. Non-zero attributable to proxies.
slide-28
SLIDE 28

4/11/2007

  • R. Beverly, S. Bauer, A. Berger

28

MS-SQL Blocking

MS-SQL Port: Blocking shows prominently three years after Slammer worm outbreak. Implies filtering rules are long-lived.

slide-29
SLIDE 29

4/11/2007

  • R. Beverly, S. Bauer, A. Berger

29

Email Blocking

Email: Ports associated with email more than twice as likely to be blocked as the control port!

slide-30
SLIDE 30

4/11/2007

  • R. Beverly, S. Bauer, A. Berger

30

Collateral Damage

Profile Port: Most frequently blocked! Innocuous port between Microsoft file sharing ports: 135,137,138,139.

slide-31
SLIDE 31

4/11/2007

  • R. Beverly, S. Bauer, A. Berger

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

slide-32
SLIDE 32

4/11/2007

  • R. Beverly, S. Bauer, A. Berger

32

Future Work

Continue to collect measurements, increase

  • ur degree of confidence

TCP Traceroutes:

Port-specific traceroutes to determine ingress filtering properties Traceroutes allow us to determine where blocking

  • ccurs, filtering asymmetry, etc.

Second methodology in progress employing HTTP using techniques outlined in this work

slide-33
SLIDE 33

4/11/2007

  • R. Beverly, S. Bauer, A. Berger

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?