Minutes for MAPRG at IETF-95
minutes-95-maprg-2

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!