Beautiful and warm morning in Barcelona! I'm here today with a whole bunch of ex-SRG people: Narseo Vallina-Rodriguez, Ilias Leontiadis and Nishanth Sastry. I will do my best to liveblog as much of the event as I can.<\/p>\n
<\/p>\n
Revealing Middlebox Intererence with Tracebox<\/a>\u00c2\u00a0- short paper<\/p>\n G. Detal, B. Hesmans, O. Bonaventure\u00c2\u00a0(Universit\u00c3\u00a9 Catholique de Louvain)<\/i>, Y. Vanaubel and B. Donnet\u00c2\u00a0(Universit\u00c3\u00a9 de Li\u00c3\u00a8ge)<\/i><\/p>\n End-to-end principle does not hold because of middleboxes in the net and especially NAT boxes.<\/p>\n Refers to previous work which has shown that with today's middleboxes almost every field of a TCP packet can potentially be modified, potentially making it difficult to detect some middleboxes. This is the motivation for Tracebox - they want to detect and localise all middleboxes.<\/p>\n Based on ICMP probes and incremental TTL. ICMP response includes the request payload, hence can use to detect middleboxes. Issue: ICMP (RFC792) only requires the first 8 bytes to be included, so only sequence number can really be used.<\/p>\n Deployment on planetlab - 70 vantage points talking to top 5000 Alexa pages... 80% paths tested contain at least one middlebox.<\/p>\n MSS gets modified as well...<\/p>\n The conclusion is that Tracebox can detect some middleboxes sometimes...<\/p>\n <\/p>\n Demystifying the Dark Side of the Middle: A Field Study of Middlebox Failures in Datacenters<\/a>\u00c2\u00a0- full paper<\/p>\n R. Potharaju\u00c2\u00a0(Purdue University)<\/i>\u00c2\u00a0and N. Jain\u00c2\u00a0(Microsoft Research)<\/i><\/p>\n Confusion between application and network failures - nobody knows why things are not working and everyone thinks those are the other guys' fault. in 2008 middlebox failures contributed to 43% of high-severity incidents.<\/p>\n Want to answer three questions:<\/p>\n Challenges with:<\/p>\n Going back to the questions they wanted to answer<\/p>\n How reliable are they:<\/p>\n Most failures are short-lived, dominated by connectivity errors.<\/p>\n Median number of annual failures is small (1-3)<\/p>\n What causes the failures?<\/p>\n Typically the first solution to solve the problem is to replace the cables and reboot, but the most common one is hardware replacements.<\/p>\n Effectiveness of middlebox redundancy: take the traffic impact test grouping the redundant middleboxes. Redundancy was ineffective in 33% of firewall failures, but almost 100% effective for IDS and VPN systems. The main causes are misconfiguration errors...<\/p>\n QA:<\/p>\n Q: Methodology - look back 2 hours, but traffic itself is varying (peak\/off-peak), how do you deal with that?<\/p>\n A: All events deemed actionable by operators in the dataset were covered, so must be right.<\/p>\n Q: If I were to take the results and be practical... I sounds like I should deal with power supply vendors and have better configuration deployment policies. What can you do with Firewall failures though?<\/p>\n A: The main reason was difficulty of problem detection by replicating the problem the user is facing. Another problem was inconsistency between operators due to the lack of central management<\/p>\n <\/p>\n A Method for Identifying and Confirming the Use of URL Filtering Products for Censorship\u00c2\u00a0<\/a>\u00c2\u00a0- short paper<\/p>\n J. Dalek, B. Haselton, H. Noman, A. Senft, M. Crete-Nishihata\u00c2\u00a0(Citizen Lab)<\/i>, P. Gill\u00c2\u00a0(Citizen Lab\/Stony Brook University)<\/i>\u00c2\u00a0and R.J. Deibert\u00c2\u00a0(Citizen Lab)<\/i><\/p>\n URL filtering devices are extremely common in all kinds of networks and are very versatile, making them very difficult to study.<\/p>\n Why studying them is important? Censorship and policy impacts.<\/p>\n Challenges: having vantage points within each country of interest and personal risk in a lot of client measurement (esp. some countries)<\/p>\n Proposed methodology:\u00c2\u00a0Locate deployments (SHODAN - looks interesting by the way), validate whether installation is live (because SHODAN data might be out of date - use WhatWeb) and confirming scope of deployment (site submission and in-country testing. Generate and submit test-sites to URL filter vendors, then using tester in the field and a remote server to fetch and compare results: page is blocked if pages are not the same).<\/p>\n Both SmartFilter and BlueCoat on Etisalat in\u00c2\u00a0UAE. SmartFilter in Saudi Arabia as well (Bayanet). Verified manually that SmartFilter is blocked by using an image of adult content from google image search :). Netweeper used in the Middle East; Netsweeper is peculiar in that it submits new domains automatically. Interestingly, in Yemennet pages were sometimes blocked and sometimes not, apparently because at the time they had a shortage of software user licenses.<\/p>\n Hope to cover larger datasets in the future.<\/p>\n <\/p>\n Peer-assisted Content Distribution in Akamai NetSession<\/a>\u00c2\u00a0- full paper<\/p>\n M. Zhao\u00c2\u00a0(University of Pennsylvania)<\/i>, P. Aditya\u00c2\u00a0(MPI-SWS)<\/i>, A. Chen\u00c2\u00a0(University of Pennsylvania)<\/i>, Y. Lin\u00c2\u00a0(Duke University)<\/i>, A. Haeberlen\u00c2\u00a0(University of Pennsylvania)<\/i>, P. Druschel\u00c2\u00a0(MPI-SWS)<\/i>, B. Maggs\u00c2\u00a0(Duke University\/Akamai)<\/i>, B. Wishon and M. Ponec\u00c2\u00a0(Akamai)<\/i><\/p>\n The goal is to better understand peer-assistend CDN systems (hybrid of P2P and infrastructure solutions).<\/p>\n Use data from Akamai's NetSession: 25 million users in 239 countries currently! Data of october 2012: logins, logouts, downloads - 4 billion log entries, 133 million unique IPs in all countries. Quite a long description of how NetSession works at high level (very similar to BitTorrent).<\/p>\n Confirmed that content popularity still follows power law... Peer assist is generally used for files of hundreds of MB.<\/p>\n 31% of users have uploading enabled. Likely affected by default settings: one version has it enabled by default and one disabled. More than 99% of users keep the default setting. Surprisingly, peers sent as 71.4% of data delivered by the CDN. Download rates only slightly lower from peers than from infrastructure CDN.<\/p>\n Risk: some ASes can upload a lot to others - potentially expensive. From the data, the traffic is generally balanced.<\/p>\n ... aaand run out of time :)<\/p>\n Analyzing the Potential Benefits of CDN Augmentation Strategies for Internet Video Workloads<\/a>\u00c2\u00a0- full paper<\/p>\n A. Balachandran\u00c2\u00a0(CMU)<\/i>, V. Sekar\u00c2\u00a0(Stoony Brook University)<\/i>, A. Akella\u00c2\u00a0(UW Madison)<\/i>\u00c2\u00a0and S. Seshan\u00c2\u00a0(CMU)<\/i><\/p>\n Data from Conviva - 2 months, 30 million video sessions, clients in US.<\/p>\n CDN infrastructure is being stressed because of the huge increase of video traffic - CDN streaming failures are becoming frequent.<\/p>\n Existing CDN augmentation efforts: hybrid P2P-CDN designs (Akamai NetSession, Chinca Cache LiveSky) and federated CDNs (Open Carrier Exchange).<\/p>\n The questions are:<\/p>\n Conventional wisdom: P2P will work for live, not for video on demand. Data makes the observations questionable to some extent. VOD for series can work very well after the initial release (not really surprising).<\/p>\n Their P2P CDN model for analysis: users are geographically close, watch the same chunk of a video and the size of the \"swarm\" of users is limited. BW savings: 98% for live and 87% VOD with 5 minute chunks and swarm size of up to 100. Especially good to use P2P to filter out \"early quitters\" (people watching only an initial fraction of a video).<\/p>\n Federated CDN: When is federation beneficial?<\/p>\n ISPs have varying regional presence and an ISP without significant coverage in an area can redirect customers to a federating ISP.<\/p>\n Regional interest in Live content typically correlates with population density, but occasionaly (e.g. sporting events with a team playing at home) there are changes.<\/p>\n Model as a resource allocation problem: minimize latency + number of session drops.<\/p>\n With country-wide federation sufficient to provision 0.8 of historical peak load for 100% availability (1.4 with regional federation).<\/p>\n Q: Have you looked at performance cost? E.g. serving data to west coast from east cost...<\/p>\n A: Not suggesting to spread around too widely, just showing that there is space for improvement due to time zone differences.<\/p>\n <\/p>\n by Pablo Rodriguez<\/p>\n IMC was started when drinking wine over the problem of not having a good venue to submit papers to :)<\/p>\n Pablo started his PhD in physics, counting photos in a basement... But got bored of that and got more interested in content distribution, which became a real problem when Victoria's Secret advert broke the Inernet!<\/p>\n Went to Microsoft and started working on P2P content distribution systems and immediately got blocked by IT department... Solution: go and have a chat with Bill Gates! Kept on working on the overlay content distribution system - Avalanche.<\/p>\n The big issue then became incentives: ISPs could not possibly be happy about that... Go back to science!<\/p>\n Fast-forward to moving to Telefonica: the same problem, rehashing the paper, changing the title, convincing people and putting P2P on set-top boxes. But in fact P2P started going down because of the cloud. In the long run it turned out it was cheaper and easier to do Cloud than P2P... But Pablo got promoted out of the whole problem...<\/p>\n Offering some insider information now: telcos have reached the end of one business period, have become a commodity business and revenues have flattened out while traffic is growing exponentially. Sadly, 60% of costs go to access - the cost that is not going to go down. This is why AT&T have decided to sell their cell towers and Telefonica and Vodafone are consolidating infrastructure.<\/p>\n What is the new business then?<\/p>\n Telco revenue worldwide is $2000 Billion while most internet businesses are a fraction of that.<\/p>\n Internet of Things<\/strong> and\u00c2\u00a0Big Data<\/strong><\/p>\n The largest social network? The phone network! Not very explicit, but a very valuable one. And is authenticated, has a call graph, billing, location, scale, universal trust and everything else!<\/p>\n Phone network data can help city planners, institutions and policy makers: socio-economic analysis, epidemic analysis, human migration, etc., etc.<\/p>\n A clash with privacy... The future is then Individual as the New Platform! Giving back data and control to the users.<\/p>\n Moving onto more peculiar fields... Food and fine dining. The story about ElBulli and the collaboration between ElBulli and Telefonica and how technology plays an important role.<\/p>\n The world has changed since the first IMC - the community has adapted well, but needs to keep adapting: huge amounts of data, environment changing continuously... Economics, incentives, sociology, policy, politics... But our community is doing well and can play an important role in changing the world :)<\/p>\n QA<\/p>\n Q: One of the problems is privacy of data measurements and repeatability... Solutions to that or ways of moving forward?<\/p>\n A: More and more data is becoming available already... Will probably just keep moving in that direction<\/p>\n Q: You raised the question 'Why' do one thing or another. There is a corporate and a personal why, which are not necessarily aligned - is the friction good or bad? Are companies too inflexible to realise the need or is it beneficial for individuals to try and convince others that their research is important?<\/p>\n A: There is only one why and that is yours: what makes you passionate about a problem and what will help you navigate around all the issues? It is important to feel in place<\/p>\n Q: (Bala): AT&T research is not closed! Only changed the name and fired a few people.<\/p>\n D-mystifying the D-Root Address Change\u00c2\u00a0<\/a>(<\/span>review<\/a>) (short)<\/span><\/p>\n M. Lentz, D. Levin, J. Castonguay, N. Spring and B. Bhattacharjee\u00c2\u00a0(University of Maryland)<\/i><\/p>\n <\/p>\n Understanding the Domain Registration Behavior of Spammers\u00c2\u00a0<\/a>(<\/span>review<\/a>) (long)<\/span><\/p>\n S. Hao\u00c2\u00a0(Georgia Institute of Technology)<\/i>, M. Thomas\u00c2\u00a0(Verisign, Inc.)<\/i>, V. Paxson\u00c2\u00a0(ICSI\/UC Berkeley)<\/i>, N. Feamster(Georgia Institute of Technology)<\/i>, C. Kreibich, C. Grier\u00c2\u00a0(ICSI)<\/i>\u00c2\u00a0and S. Hollenbeck\u00c2\u00a0(Verisign, Inc.)<\/i><\/p>\n <\/p>\n Domains are a valuable resource, but often abused by spammers. Any chance we could use domain registration information to predict spam before it happens rather than filter it at the time of use?<\/p>\n Typical lifecycle: 1-10 years active time, auto-renew grace of 45 days, redemption grace of 30 days, pending delete of 5 and removal.<\/p>\n For their research, they had to collect all the new domains in .com. Received data from Verisign:<\/p>\n What registrars are used by spammers? 70% of spammer domains from only 10 registrars. These registrars only contributed 20% of total domains in .com. However, number of non-spam and spam domains is correlated, hence most spammers use the most popular registrars that also host non-spam domains - no simple solution with registrar control.<\/p>\n Do spammers register domains in groups? Taking 5 minute epochs, only 20% of spammer domains were registered individually and most - in batches of 200 or more.<\/p>\n How can we identify \"abnormally large\" registration batches?<\/p>\n Spammers commonly re-register just deleted addresses when doing registrations in batches, but only 6.8% of domains that had previously been in blacklists.<\/p>\n Conclusion: registration patterns can help in distinguishing spammer domains, but they have not found a single accurate feature-set to do domain checking automatically.<\/p>\n Q: What about spelling variations and different zones?<\/p>\n A: Only focused on .com (no comment about spelling)<\/p>\n Q: why are non-spammer domains registered in bulks?<\/p>\n A: parking domains to get traffic, different kind of malicious...<\/p>\n Q: why do spammers register domains in bulk?<\/p>\n A: Hypothesis is bulk discounts and availability of APIs<\/p>\n <\/p>\n On Measuring the Client-side DNS Infrastructure\u00c2\u00a0<\/a>(<\/span>review<\/a>) (long)<\/span><\/p>\n K. Schomp, T. Callahan, M. Rabinovich\u00c2\u00a0(Case Western Reserve University)<\/i>\u00c2\u00a0and M. Allman\u00c2\u00a0(ICSI)<\/i><\/p>\n Chair suggest this to be a \"perfect IMC paper\" :)<\/p>\n DNS resolution path is complex and hidden: multiple layers of resolvers, controlled by different organisations - hard to say who's responsible when things go wrong...<\/p>\n Want to discover open resolvers and classify open resolvers (ODNS) that forward to recursive resolvers (RNDS) as forwarding dns (FDNS).<\/p>\n RDNS servers don't typically respond to direct probing, need to rely on FDNS resolvers. From the authoritative side do CNAME chaining: RDNS will frequently peer to other RDNS resolvers and the authoritative server sees the request.<\/p>\n Only probe own domain to have minimal effects on the network.<\/p>\n ODNS are short lived - 20% are available for less than 3 hours, so must experiment during discovery.<\/p>\n Measure FDNS using cache injection - origin asks FDNS for a domain, which queries RDNS making the result ambiguous. Doing the same request just after the FDNS does not forward anymore however in 7%-9% of cases.<\/p>\n To probe RDNS use coordinated probing - multiple FDNS servers simultaneously - relying on the fact that multiple FDNS servers use a small number of RDNS servers and FDNS use pools of RDNS (80% of FDNS use 3 or more RDNS servers).<\/p>\n 20% of FDNS are at least a 1000 miles from all of their RDNS servers and 20% of FDNS have 100ms or higher RTT to all of their RDNS. Some neat trickery on how the RTT is estimated - check paper.<\/p>\n Caching is problematic (shown before) - TTL ignored or violated. To check that, use majority reporting with coordinated probing. Small TTLs are commonly decreased and long ones are decreased. In aggregate, 30% of records are evicted before TTL while 10% are retained for longer than TTL.<\/p>\n More \"popular\" RDNS discovered early in the scan are more likely to be honest - something to do with the fact that RDNS is discovered through FDNS, naturally. FDNS dataset may not be representative though.<\/p>\n Q: What exactly do you need to send to FDNS to do an injection?<\/p>\n A: Simply send a response to port 53 on the devices and they accept it - the transaction ID does not matter and they accept an unsolicited response just out of the blue, scarily!<\/p>\n Q: any particular manufacturer doing that?<\/p>\n A: Not a single one for sure, but hard to say. Most of the vulnerable DNS servers run the same embedded web server, but not sure whether that's a good indication<\/p>\n Q: Local\/home resolvers?<\/p>\n A: The home ones are likely the cause - they simply forward.<\/p>\n Internet Nameserver IPv4 and IPv6 Address Relationships\u00c2\u00a0<\/a>(review<\/a>) (long) Interested in finding associated IPv6 and IPv4 nameservers. The why: IPv6 geolocation, security (DoS).<\/p>\n One technique: passive, opportunistic DNS technique - based on hierarchies and the first-level authoritative DNS returning requesting resolver's IPv4 address encoded in IPv6 response. The seen address can then be logged for matching. Simple technique, almost no modifications and used by Akamai.<\/p>\n Sometimes, although less common, the pairs are not 1-1. 674k pairs in the Akamai's dataset. The equivalence classes (types of mappings) do become quite large, sometimes up to 100s of addresses. 1-1 are 34%, aggregating the addresses by prefixes (\/64 for v6) that becomes ~50%.<\/p>\n <\/p>\n Active probing technique: glue in NS records alternates between AAAA and A. CNAMEs encode source addresses and at the response to the prober at the end contains TXT record with a nonce, the 3 addresses from CNAME plus the address from final query.<\/p>\n Validation: starting with the passive dataset, determined open resolvers with v6 access - 5300 ipv4 and only 1700 ipv6. Addresses in 1-1 equivalance class: 87%. More probes reduce the proportion with this technique though (reasons discussed in the paper), but the increments become marginal after certain numbers.<\/p>\n For validation, contacted 6 network operators; 3 responded that all the 1-1 associations were indeed the same machine.<\/p>\n Akamai uses the technique to bootstrap IPv6 geolocation<\/p>\n Q: 1000s in your dataset and millions in the previous talk - why is that the case?<\/p>\n A: Restricted size of the dataset to begin with, but what significantly cut down the proportion was requirement for IPv6<\/p>\n Q: geoip - techniques that give you finer-grain info?<\/p>\n A: further aggregation, but very importantly need more sophisticated filtering and data validation<\/p>\n <\/p>\n <\/b>Understanding IPv6 Internet Background Radiation\u00c2\u00a0<\/a>(review<\/a>) (long) <\/p>\n <\/b>Speedtrap: Internet-Scale IPv6 Alias Resolution\u00c2\u00a0<\/a>(review<\/a>) (short) How is the router-level structure of IPv6 internet evolving with deployment? Need traceroute and alias resolution, but so far no internet-scale alias resolution technique.<\/p>\n Speedtrap uses IP-ID to fingerprint IPv6 routers; trying to send the minimum number of packets given the lack of counter velocity. Technique:\u00c2\u00a0obtains an ID field by sending a router an ICMP packet too big message (PTB) with an MTU field smaller than the size of the pack- ets solicited from it... Details in the paper.<\/p>\n <\/p>\n Sorry about the lack of detail in the very last session... Anyway, done for today!<\/p>\n","protected":false},"excerpt":{"rendered":" Beautiful and warm morning in Barcelona! I’m here today with a whole bunch of ex-SRG people: Narseo Vallina-Rodriguez, Ilias Leontiadis and Nishanth Sastry. I will do my best to liveblog as much of the event as I can.<\/p>\n","protected":false},"author":37,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[],"_links":{"self":[{"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/posts\/1579"}],"collection":[{"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/users\/37"}],"replies":[{"embeddable":true,"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/comments?post=1579"}],"version-history":[{"count":16,"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/posts\/1579\/revisions"}],"predecessor-version":[{"id":1595,"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/posts\/1579\/revisions\/1595"}],"wp:attachment":[{"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/media?parent=1579"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/categories?post=1579"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/tags?post=1579"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\n
\n
\n
\n
\n
Keynote<\/strong><\/h2>\n
Names and Domains<\/strong><\/h2>\n
\n
V4 and V6<\/strong><\/h2>\n
\nA. Berger\u00c2\u00a0(MIT CSAIL\/Akamai)<\/i>, N. Weaver\u00c2\u00a0(ICSI\/UC San Diego)<\/i>, R. Beverly\u00c2\u00a0(Naval Postgraduate School)<\/i>\u00c2\u00a0and L. Campbell\u00c2\u00a0(Larry Campb\u001cell)<\/i><\/p>\n
\nJ. Czyz, K. Lady, S. Miller, M. Bailey\u00c2\u00a0(University of Michigan)<\/i>, M. Kallitsis and M. Karir\u00c2\u00a0(Merit Network)<\/i><\/p>\n
\nM. Luckie\u00c2\u00a0(CAIDA\/UC San Diego)<\/i>, R. Beverly, W. Brinkmeyer\u00c2\u00a0(Naval Postgraduate School)<\/i>, and K. Claffy(CAIDA\/UC San Diego)<\/i><\/p>\n