Skip to main content

Minutes IETF98: maprg

Meeting Minutes Measurement and Analysis for Protocols (maprg) RG Snapshot
Date and time 2017-03-28 14:00
Title Minutes IETF98: maprg
State Active
Other versions plain text
Last updated 2017-04-21

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

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 - - 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 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:

5. IPv6 scanning - Tobias Fiebig
- want to observe IPv6 deployment by walking 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
  - 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

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