Intro & Overview Dave Plonka and Mirja Kühlewind --------------------------------------------------- MAPRG is derived from the HOPS (How Ossified Is the Protocol Stack) BOF. Charter is up on https://datatracker.ietf.org/group/maprg/charter/ Internet conditions exist that were unforeseen when many of the protocols were written and standardized. As protocols need to get update, redesigned, and new ones get written, they should be informed by recent measurements on the Internet to understand the current conditions. We should: 1) Discuss measurement techniques of existing protocols 2) Presentation of measurement results of above These should be linked to protocols already in some IETF working group. Connect academia and engineers to share data, provide an open meeting place as a resource to all. Discuss charter on mailing list. ICANN Testbed for Middleboxes Paul Hoffman --------------------------------------------------- Paul is setting up a testbed for middleboxes. People say many things about middleboxes without data. Trying to get hundreds of various middleboxes: small CPEs and big Cisco routers, modems, phones, etc. Anything that can be between a client device and the Internet that may think it's helping will be analyzed. ICANN controls the top level of DNS names. People say middleboxes will break certain DNS changes or extensions, but we need more data to back that up. Are they a few boxes that affect many? Or many boxes? Etc. Dozens of DNS tests already running, but it's easy to add more tests to the test harness. The layout will be published so people can propose new tests to run on this testbed. The plan is to run this for years to study the changes in middleboxes over time. Aaron Falk (Akamai): Very cool! Questions: are you planning on testing that uses the Internet, or mainly lab? Paul H: Mainly lab, less Internet. But will look at Internet-specific for special cases. And we’ll test open recursives, for instance. Aaron: Are you using DNS as a criterion in selecting middleboxes? Paul H: No, it's just one part. It doesn't have to use DNS at all. Buying modems, routers, firewalls, etc. Aaron: Your software or existing stuff? Paul H: My own Giovane Moura: Will this be published similarly to Atlas that other people can deploy? Paul H: No plans for that as of now. I’ll run it, but I’ll run it for you. Could even privately add your middlebox if you want. A Characterization of IPv6 Network Security Policy Mark Allman --------------------------------------------------- Broad range of existing measurements for IPv6, which is being used to understand use of security in IPv6. Presented at NDSS a month ago. IPv6 is gaining a lot of traction in recent years. Going up to above 10% by Google's graphs. As it is becoming prevalent, we need to think about the security implications. IPv6 is not inherently more or less secure than IPv4, and since the IPv6 ecosystem is less mature, it may be less secure and provides a second path for attacks in a dual-stack environment. Often IPv6 gets enabled without the typical access controls enabled for IPv4. These discrepancies can happen, and we believe they happen, but we want to know numbers on when and where they do happen in the real Internet. We probe dual-stack devices with both IPv4 and IPv6 and see how the probes fare differently for each protocol. Found dual-stack devices by getting a large list of hosts (trace route data, etc) and use DNS to create connections between IP addresses that point to the same hosts. This may not be accurate for many reasons, but sanity-checking makes this reasonably accurate (check SSH keys, etc). Paper has full details. Ended up with 25K dual stack routers and 520K servers. Used scamper to probe all of the hosts with basic probes (for example, send a SYN) and trace route-style probes (same probes with growing TTLs). The assumption is that if there is a different outcome between IPv4 and IPv6, there is some policy difference (probably unintentional) between IPv4 and IPv6. Presents results. Generally, IPv6 more open. HTTPS is 40% more open of v6 than v4. Are these policies just on an end host, or are they systematic by network? Mapped results by routed prefix. Policies are generally systematic to a network based on these results. There is more active blocking (TCP RST, etc.) with IPv6 than IPv4, meaning that there is more errors from IPv4 later on in the host. Routers are more imbalanced in this than end servers. Were these results accurate? Were the policies intentional? Got responses from 12 network operator that the results were correct, and they were unintentional differences. This seems to agree with the original thesis that IPv6 networks are less mature than IPv4 networks. Jana Iyengar: How do you measure the percentage of "passive other than IPv6" failures, since you get nothing back. How do you know this is the host? Mark: This is because of the trace route style probes. We can tell which hop the probe dies on. Jana: This points out that IPv6 is less mature, but it also seems that the paths are not being used for attacks yet. Do operators expect the attacks to come? Mark: I can't speak for operators. I think based on their reactions that these were mistakes they were eager to fix. Aaron: The DNS trick to identify the hosts is a cool trick, but it misses a large category of hosts. How do we get those? Mark: Can you specify what I'm missing. Anything not in the DNS? Aaron: Yes, residential, mobile, and enterprise hosts without DNS names. Mark: We are missing a bunch of things, but how important are those? Aaron: Those are all the ones I work on. Mark: Right, they're not important [General laughter] More seriously, we'd like to know the answer to this, but it is hard to measure, and we hope the data we have is representative. Aaron: Suggestion to use this research group's resources by having operators do some of the measurements and feed data back in. IPv6 Prefix Intelligence Dave Plonka (Akamai) --------------------------------------------------- What prefix length should be used to rate-limit clients that are abusing the network? This is a class of study that fits the research group looking at a protocol (IPv6) and how to classify traffic. Proposal is to use some prefix intelligence around IPv6 classification. Rate limiting based on 64 bit prefixes for IPv6 attacks may have a lot of collateral damage to other hosts on that prefix. RFC 7136 says the low 64 bits should be opaque. However, this leads to some pain in reality. If it is opaque, then there many be thousands of hosts that get affected behind that single /64. Focusing on client addresses, but this also applies to routers and services. Privacy addresses seem like good candidates for /64, since they seem to have the liberty to choose their own address within the /64. One can do stateless analysis of IPv6 addresses to classify them. However, we can go beyond that. Some examples show slowly incrementing addresses, others show random privacy addresses. Both examples are universities. The in addition to the address, take note of the "discriminating prefix length" to find the unique prefix in common between addresses; and the number of days that a particular address is stable and re-used. This allows us to tell if a prefix uses SLAC or not. If it does, treat the /64 as one entity. If not, use the /128, for example. See research paper published by Akamai for more details. (“Temporal and Spatial IPv6 Address Classification”) What if there are operators or CDNs that want to tell us what length is used for grouping, to make sure that people mitigating attacks make the right choice for prefix length? Mirja: Do people find this interesting? (yes, people raise hands). Do people want to work on this actively? (Less response) Let's go the list. Support of IPv6 Extension Headers in the IPv6 Internet Eric Vyncke (Cisco) --------------------------------------------------- An issue with IPv6 extension headers is that routers need to pass along the headers they don't care about, since they may matter to other boxes. If we try IPv6 addresses of many of the top websites, then these often go through the same common paths of the Internet. We want to know if service providers drop based on headers, less so if the end hosts drop the packets. Methodology is simple: get common IPv6 addresses, do a TCP trace route with and without extension headers. Got the Alexa addresses, and also tried ::1 on BGP-advertised prefixes to get probes into the AS. Going to add ESP and AH to tests in next round to cover IPSec. Asking for help to map IPv6 addresses to ISP and AS. Running these tests send a huge amount of DNS and 'weird-looking' packets. Takes about a week to run. Otherwise, tests have been blocked as looking 'hostile' due to the amount of traffic. Some results: DO (decision option) is generally passed. HbH is dropped more. The longer the extension header, the more they are dropped. Things seemed to have improved in 2016 compared to 2015. This means there is some reaction/fixes being made. Can we run the Internet over UDP? Brian Trammell --------------------------------------------------- Can we run the internet over UDP.... Yes! Okay, it's not that simple. Why do want to do this? Mainly encapsulation for new protocols, mostly get through NAT and middleboxes. Better than adding more IP protocols. Easier to implement in userspace. Lots of current work in IETF: WebRTC, QUIC, SPUD, gaming protocols, etc. We reframe the question as: what different treatment arises due to merely the presence of a UDP header (instead on TCP)? Today, we can use RIPE Atlas measurements to get info. It generally works fine in many situations. It's the edges of the network that usually have problems. Atlas has many probes, is a bit biased towards network geeks, so it is more clean that it would be otherwise. It doesn't get you arbitrary TCP/UDP packets, but it's a start. 2240 probes did UDP-based trace routes in 2015, and 3.6% (82) never had successful UDP traffic. These are networks with bad connectivity anyhow, perhaps behind an HTTP proxy. Under representing enterprise and mobile networks. A couple cases have much much slower UDP than TCP, especially in Asia/Oceania. It seems that the problems are localized to access networks, not up the path. IPv6 is more stable than otherwise. Are larger UDP packets dropped more than others? No. More blocking of ICMP around 512 and 1024, not really after, but the UDP blocking curve is flat with respect to packet size. Again, 3.6% of probes seem to be blocked for UDP. This means that trivial fallback mechanisms will buy you a lot in general when you choose UDP first. See https://mami-project.eu for updates. Jana: We see slightly less success for UDP. There is also some behavior that kicks in later on in the exchange of packets, not just the initial packets. Geoff Huston: When you "yes, this is viable", that doesn't take into account IPv4 NATs which idle timeout much much sooner. There may be some kill switch too on NATs. If you try again after various times, does it still work? At what point do NATs tear down the mapping? Brian: read draft-kuelhewind-spud-use-cases section 4. That’s why we’re looking at use cases, to give newer NATs a signal about lifetime. Ian Swett: QUIC does use a 30 second NAT timeout. Ability to re-open NAT helps if the protocol supports it. Awesome data. Awesome data, but I think your 3% is a little low, and 5% is more likely. Also, what about rate limiting? Would be hard for you to detect. Brian: We don’t know how to do this without abusing the network. Ian: More pathological, instead of giving you a new port it might blackhole you forever. Very rare. Brian: We’re cataloging all the ways UDP can break. Let’s talk more and share info. Jana: NAT timeout doesn’t matter if you’re not using the 4-tuple as identifier. Open Discussion --------------------------------------------------- Are people interested in meeting next time in Berlin? (A good show of hands) Please participate on the mailing list!