MAPRG @ IETF 98, Chicago/USA, March 28, 2017 there were 14 proposed contributions for meeting presentations, 9 were chosen to present today in the meeting chairs showed brief update on IPv6 increases, and decrease in tunneling transition 1. Refreshing MLab - Matt Mathis - mix in the room of people familiar and not familiar with MLab - focus of MLab is on user access, open data, open platforms - global system - they are rebooting the experiment approval process and doing a platform refresh to update hardware - US and EU footprints will look more similar - in US you can do differential measurements between access and transit ISPs in same metro ???: looks good and looking forward to seeing what he can do with it, can you give some examples? Matt: focused on access measurement and infer things about equipment, connectivity, etc. Robert Kisteleki: we are already using this data in RIPEstat and there is collaboration work, thank you, it is useful data 2. LE codepoint - Gorry Fairhurst - trying to show 3 tools and 4 results withing 6 minutes - in TSVWG, trying to select a codepoint for new PHB for low effort traffic class - PATHspider.net - setting DSCP 0 & 2 did not cause packets to be blackholed - PATHscope - expanding ring search using TTL to check in ICMP if DSCP changed - 81% of paths unchanged, 19% remarked, most to 0 (Best Effort), and no differnce between TCP and UDP - ~17% of routers bleached the upper three bits of DSCP to 0 - openssh uses codepoints 2 and 4, there is a bug report for that - see trace.erg.abdn.ac.uk for tool Matt Mathis: home router equipment vendors using Linux kernel don't bleach, but use inverted semantics; can't measure that with this technique Gorry: incorrect PHB being used Matt: any cases where 2 got inverted to higher priority? Gorry: 2 became 0 Matt: trying to imagine a case where this would be more disruptive ... if 41 was marked to LE, receiver might be inclined to complain to ISP Joe Ishac: have you looked at both IPv4 and v6 Gorry: need to take that one offline, TOS-bleaching of top 3 bits is most common, but also degrading of EF 3. TCP ECN - Padma Bhooma - experience at Apple enabling ECN on the Internet - negotiation enabled in iOS and macOS on 5% of randomly selected connections, then up to 50% on later releases - no problems reported from customers after using ECN on 50% of connections on all Apple devices - some heuristics are used to detect anomalies from middleboxes that treat ECN-enabled packets differently and disable ECN for a limited time 1. after an anomaly, ECN is disabled for about an hour on those network attachments where this is detected 2. CE marking on every packet was seen at ISP in Germany (even on non-ECN connections) 3. syn loss on more than 2 successive ECN negotiating SYNs trigger the heuristic (even if the loss is not due to ECN) 4. RST on first data packet - seen rarely, still need a metric to quantify impact 5. connection drop after multiple retransmissions on more than 4 successively established ECN connections - goal is to reach a state where broken middleboxes are fixed and everyone can use ECN effectively - high percentage of CE showing up in Argentina - marking mainly seen on uplink (expected due to asymmetric nature) - comparison date between ECN and non-ECN connections - ECN performs no worse than non-ECN Jim Roskind: on uplink/downlink congestion, is it possible that congestion points were not marking in down direction? Padma: don't have a metric to measure packet loss - have out of order bytes and retransmissions Stuart Cheshire: statement was towards marking and not congestion, there may be a home gateway in upstream, but ISP head end in downstream with different marking support Matt Mathis: any attempts to fingerprint these devices? in the past there were bugs due to one vendor, one product, even one keystroke Padma: can't drill down to the extent of a device Matt: does client inform the server if the heuristics are tripped to disable ECN? Padma: no, strictly client side Stuart: the test is not to some server controlled by Apple, it's on every TCP connection Matt: you could create custom version of traceroute to track down individual bugs and ISPs Stuart: we didn't really find anything that needs to be tracked down ... maybe in the case of the reordering heuristic 4. IPv6 support - Tommy Pauly - @ IETF 96, presented initial data from iOS and macOS happy eyeballs for IPv4/IPv6 - new data shows 3% of IPv6-only hosts which was not in previous data (e.g. could be due to NAT64) - data on IPv4 vs IPv6 winning happy eyeballs performance Matt Mathis: in IPv4, have had failures from using all ports in NAT, so dual-stack or v6 would have done better Tommy: don't have data to know if this is happening Matt: ISPs that have dual-stack should do much better in quality of experience Mark Towsley: what happened in February? Tommy: scale of NAT64 deployments may have changed, don't know details Lorenzo Colitti: racing v6 vs NAT64 is different than v6/v4, shouldn't race NAT64 and v6 Tommy: agreement 5. IPv6 scanning - Tobias Fiebig - want to observe IPv6 deployment by walking ip6.arpa tree - mentioned in RFC7707 - needed to use mixture of breadth and depth first search, parallelized - detecting auto-gen zones using a heuristic - for non RFC8020 compliance, used BGP view data to seed search - pretty hard to mitigatew without violating RFC 8020 - could work with wildcard records - tools and publication links Ben Schwartz: would you recommend that a cloud provider take any action to mitigate this? Tobias: personally believe in open security, so if topology is providing the attacker that advantage, then you should protect ???: walking can be detected via pattern matching on the scan queries, in an IDS 6. Let's Encrypt - Giovane Moura - more than half of web traffic is encrypted - goal to see if let's encrypt has been sucessful over first year - datasets: certificates, domain to IP mapping, organization mapping, registration info - growth in adoption (unique certified domains) - 98% are outside the Alexa 1M, but many certificates are issued within subdomains of top Alex sites - most used for web, 90% of domains are on shared hosting (lower-end market) - most certificates are correctly renewed - many "old" domains are getting certificates through let's encrypt - some may have deployment errors Lorenzo: this is a US system, and some people might prefer to use a European one? Ben: you hold the private key, let's encrypt doesn't see that, they are bound by certificate transparency, so it is a fairly safe system, they are vulnerable to some MITM attacks Lorenzo/Ben: they could serve you a bad certificate? 7. Broadcast data and privacy - Rolf Winter - listened to everything being broadcast or multicast on the network at 3 locations (including IETF Yokohama, eduroam on campus) - german data protection laws are very strict, made it difficult to look at data while preserving privacy - popular cloud storage provider application every 30 seconds broadcasts information for local data exchange - you can draw a community graph from this data - hostnames in mDNS, NetBIOS, LLMNR - often have people's names, device models, etc. - LDAP university directory matched against hostnames based on first, last, and full names - countermeasures - don't name device after yourself - restrict visible data in online - switching off broadcast/multicast impacts functionalities - be careful in protocol design Tim Chown: as a user they don't realize what is going to happen when they put a name in; DNS-SD later this afternoon will talk about privacy for DNS-SD and device pairing 8. weak keys in network devices - Marcella Hastings - some RSA keys on Internet could be factored, used weak RNGs, mostly small devices - looked at keys in TLS scans over 2010-2016, computed GCDs, identified vendors - aggregated data from 5 different sets - vendor names in certificates, or heuristic based on shared primes - data shown for several different vendors - only 16 of 42 vendors had discoverable contacts to notify of vulnerabilities, less responded with patches Stuart Cheshire: thank you for very interesting presentation on an important subject 9. censorship - Will Scott - OONI since 2012 for individuals to debug their connections, detect middleboxes, etc, mobile app - satellite using open DNS resolver - censys and scans.io are large repositories of HTTP and DNS probing - elections are common trigger for censorship in some ISPs; social media and closed platforms make some of the measurements less relevant - moving to common format in line-separated JSON ... room for standards in formatbb Jen Linkova blocking of local sites, russia officially publishes list of what should be blocked Will: other countries are publishing lists, country-specific lists in citizen lab hand curated list Tobias: accounting for load balancing, etc, in comparing DNS results? Will: using several characteristics of response to try to classify; about 60% of top sites respond the same way all the time, and 40% have geographic differences Dave Dolson: question on what you mean by blocking, specific URLs, etc? Will: yes, if they aren't public URLs, or things only observable within the application protocol, it is difficult to get data MAPRG is intending to meet in Prague new IRTF chair Allison Mankin, mentioned the new workshop and a lot of work shown here is eligible for that