characterizing ipv4 anycast adoptjon and deployment
play

Characterizing IPv4 Anycast Adoptjon and Deployment Dario Rossi - PowerPoint PPT Presentation

Characterizing IPv4 Anycast Adoptjon and Deployment Dario Rossi Professor dario.rossi@telecom-paristech.fr htup://www.enst.fr/~drossi/anycast Joint work with D.Cicalese, J. Auge, D. Joumblatu and T. Friedman Talk Teaser A seminal work [4] at


  1. Characterizing IPv4 Anycast Adoptjon and Deployment Dario Rossi Professor dario.rossi@telecom-paristech.fr htup://www.enst.fr/~drossi/anycast Joint work with D.Cicalese, J. Auge, D. Joumblatu and T. Friedman

  2. Talk Teaser A seminal work [4] at NANOG’59 investjgates who are the IP anycasters. Our focus is instead on where they are Note: everything you see in this talk is available as open source at Note: everything you see in this talk is available as open source at htup://www.telecom-paristech.fr/~drossi/anycast htup://www.telecom-paristech.fr/~drossi/anycast Demo shortlink: goo.gl/Ff8gdQ 12

  3. Outline • Preliminaries – Motjvatjon, defjnitjon & state of the art • Background (wrt the anrp paper) – Recall on Latency-based anycast geolocatjon technique [1] • Foreground (the anrp paper) – IPv4 anycast censuses [2] – Demo, source code, ground truth and more [3] • Ongoing – Study infrastructure evolutjon & usage – Applicatjon to BGP hijack detectjon [1] D. Cicalese et al. A Fistgul of Pings: Accurate and Lightweight Anycast Enumeratjon and Geolocatjon, IEEE INFOCOM, Apr 2015. [2] D. Cicalese et al. Characterizing IPv4 Anycast Adoptjon and Deployment, ACM CoNEXT, Dec 2015. [3] htup://www.telecom-paristech.fr/~drossi/anycast 3

  4. Motjvatjons O(100ms) 400ms delay , 0.7% less searches (=less ads (=less $)) : ms (2sec) reduces by 1.2% (4.8%) O(10ms) 5sec speedup, +25% visit, +12% revenue

  5. Motjvatjons O(10ms) O(10ms)

  6. Applicatjon-layer anycast  How it works  Pros • Ability to specify selectjon criteria • Relies on IP unicast • Fine-grained control over server • Server selectjon via DNS redirectjon, URL rewritjng load • Maintains connectjon affjnity • Fast failover X1  Cons X3 X2 • Ad hoc, per service confjguratjon DNS • Overhead to collect selectjon X1 IP metrics • E.g. List of servers up, latency, load C3 C2 C1 x.com?

  7. IP-layer anycast  How it works  Pros • Natjvely supported by IP • Shared IP address for replicate • Transparent to upper layers servers • Visibility of servers • BGP Prefjx advertjsed from (Global vs Local) multjple points of origin  Cons X X • Lack of fjne-grained control BGP X announces • Destjnatjon determined by IP routjng metrics IP • Prone to prefjx hijacking forwarding C3 • No guarantees of server affjnity C2 C1 (e.g., connectjon-oriented services) Our focus Our focus

  8. Anycast geolocatjon • Problem statement: where are the anycast instances? – E.g., Google 8.8.8.8 or CloudFlare, or EdgeCast or root servers, etc. Commercial databases Distributed measurement Mountain View, CA (IP2Locatjon) Tools using distributed New York, NY (Geobytes) measurement aren’t betuer ! United States (Maxmind) Single (tme varying) answer ? ? Unknown accuracy ? ? ? S U o t U E m o r f s m ! violaton ! 2 t h g i l ????? f o d e e p S 1ms ≈ 100Km ICMP packets are ~3x slower than lightspeed 8

  9. Outline Background Part I: iGreedy Part II: Census Ongoing work Summary Anycast geolocatjon • Problem statement: where are the anycast instances? – E.g., Google 8.8.8.8 or CloudFlare, or EdgeCast or root servers, etc. • Solutjon Distributed measurement – Leverage inconsistency Tools using distributed of latency measurement measurement aren’t betuer ! – This was used in NANOG’59 But they could! to detect who are the anycasters – We raise this to the next level ? ? ? ? ? S and geolocate where they are U o t U E m o r f s m ! violaton ! 2 • Propertjes t h g i l f o d e e p S – Lightweight : few pings – Protocol agnostc : ICMP probes Hey, that Hey, that must be – Accurate against ground truth must be anycast! anycast! – Fast : greedy, but as good as costly optjmum solutjon 9

  10. Outline Background Part I: iGreedy Part II: Census Ongoing work Summary Related work FG FG BG all IPv4 Main difgerentators • Background fjrst lightweight and protocol-agnostjc technique able to detect, enumerate and geolocate anycast instances • Foreground fjrst large-scale (several IPv4 censuses) geolocatjon of anycast instances 10

  11. Outline Background Part I: iGreedy Part II: Census Ongoing work Summary Workfmow iGreedy Census iGreedy PlanetLab and RIPE Atlas Census PlanetLab (+ RIPE Atlas) – Lightweight : O(1) pings per target per – Broad : apply iGreedy to all IPv4 / vantage point 24 for each census – DNS : validate with RIPE Atlas – Costly: 3 Billions RIPE Atlas DNS CHAOS ground truth credits, per census; combine iGreedy PlanetLab and RIPE Atlas (backup – PlanetLab slides) – Detailed: complementary nmap – CDN : ground truth with new protocol- portscan of detected anycast specifjc technique replicas (HTTP headers; see paper) – Protocols: ICMP, DNS/UDP, DNS/TCP, HTTP/TCP, etc. 11

  12. Outline Background Part I: iGreedy Part II: Census Ongoing work Summary iGreedy overview Filter latency Scalability noise Detect Detect Enumerate Enumerate Geolocate Geolocate Speed of light Speed of light Solve MIS Solve MIS Classifjcatjon Classifjcatjon violatjons violatjons Brute force (Optjmum) Brute force (Optjmum) Maximum likelihood Maximum likelihood Greedy (5-approx ) Greedy (5-approx ) pick the largest city pick the largest city Measure Measure Iterate Latency Latency Feedback Planetlab/RIPE Atlas Planetlab/RIPE Atlas Increase recall Lightweight Infrastructure Measure Detect Enumerate Geolocate Iterate 12

  13. iGreedy overview Filter latency Scalability noise Detect Detect Enumerate Enumerate Geolocate Geolocate Speed of light Speed of light Solve MIS Solve MIS Classifjcatjon Classifjcatjon violatjons violatjons Brute force (Optjmum) Brute force (Optjmum) Maximum likelihood Maximum likelihood Greedy (5-approx ) Greedy (5-approx ) pick the largest city pick the largest city Paris-Madrid Measure Measure Iterate 1053Km Latency Latency Feedback Planetlab/RIPE Atlas Planetlab/RIPE Atlas Increase recall Lightweight Infrastructure 1ms ≈ 10% disks Median latency stretch Importance of over speed-of-light Internet side-channel infos 100Km < 1000Km Measure Detect Enumerate Geolocate Iterate 13

  14. iGreedy performance • At a glance Accurate enumeratjon over 75% recall Precise geolocatjon over 75% true positjves Protocol agnostjc DSN and CDN, etc. Lightweight 100x less probes than previous work Fast O(100ms) greedy vs O(1000sec) for brute force Ready Open source code [3] to measure, analyze and map (demo if tjme allows later) Reliable Open dataset [3] along the code, with latency measurement & ground truth 14

  15. Census agenda • Census preliminaries – Confjrms iGreedy works for non-DNS services – Select a probing protocol and rate Backup slides – Optjmize data storage and processing – Infrastructure consideratjon (PlanetLab vs RIPE) – Scale up the iGreedy technique (& be gentle) • Census results – At a glance: Geographic heatmap – Big fjshes: Top-50 deployments – Services: Complementary port-scan – Web interface: What’s available

  16. Anatomy of an IPv4 census Typical workfmow • O(10 7 ) likely alive targets x O(10 2 ) actjve probes with ICMP • O(10 3 ) targets/sensor/second , 1 census = few hours • O(10 7 ) runs of iGreedy later…. • O(10 3 ) targets are anycast – proverbial needle in the IPv4 haystack 1

  17. Anatomy of an IPv4 census Typical workfmow IPv4/32 census by ANT/ISI • O(10 7 ) likely alive targets x O(10 2 ) actjve probes with ICMP • O(10 3 ) targets/sensor/second , 1 census = few hours • O(10 7 ) runs of iGreedy later…. • O(10 3 ) targets are anycast – proverbial needle in the IPv4 haystack 1

  18. Anatomy of an IPv4 census Typical workfmow Administratjvely prohibited /24 are probed only by 1 VP Greylist Avoid overload targets • O(10 7 ) likely alive targets x O(10 2 ) actve probes with ICMP • O(10 3 ) targets/sensor/second , 1 census = few hours • O(10 7 ) runs of iGreedy later…. • O(10 3 ) targets are anycast – proverbial needle in the IPv4 haystack 1

  19. Anatomy of an IPv4 census Typical workfmow Service agnostjc: Higher recall Results match with difgerent protocols • O(10 7 ) likely alive targets x O(10 2 ) actjve probes with ICMP • O(10 3 ) targets/sensor/second , 1 census = few hours • O(10 7 ) runs of iGreedy later…. • O(10 3 ) targets are anycast – proverbial needle in the IPv4 haystack 1

  20. Anatomy of an IPv4 census Typical workfmow Avoid VP overload /fjrewalls • O(10 7 ) likely alive targets x O(10 2 ) actjve probes with ICMP • O(10 3 ) targets/sensor/second , 1 census = few hours • O(10 7 ) runs of iGreedy later…. • O(10 3 ) targets are anycast – proverbial needle in the IPv4 haystack 2

  21. Anatomy of an IPv4 census Typical workfmow VP • Our tool can scan more • Some PlanetLab nodes than 10k hosts/sec/VP are fjrewalled– they • We maximize interarrival drop ICMP reply traffjc tjme between ICMP echo request from difgerent VPs • Experimentally, to the same target no problem • However, ICMP echo replies Avoid VP with 1k req/sec aggregate at the VP, that overload /fjrewalls receives 10k replies/sec • O(10 7 ) likely alive targets x O(10 2 ) actjve probes with ICMP • O(10 3 ) targets/sensor/second , 1 census = few hours • O(10 7 ) runs of iGreedy later…. • O(10 3 ) targets are anycast – proverbial needle in the IPv4 haystack 2

Recommend


More recommend