The RIPE-javik logs: Day 2

carsten@menandmice:~$ cat ~/ripe/ripejavik-day2.txt | blog-publish

The second day of RIPE 78 started with the plenary, and three presentations on the topic of Distributed Denial of Service (DDoS).

DDoS

DDoS attacks are an increasing risk on the Internet. Mattijs Jonker from the University of Twente explained how DDoS attacks work. His research has revealed that many businesses have all their Internet services (website, mailserver, etc.) in a single network. In case of a DDoS attack, all services are impacted. He counted 31 thousand websites, 3.5 thousand mailservers, and 323 DNS servers that are on a single network and would suffer in case of an attack. An alternative IP address from a different network (autonomous system/AS) would make the services more resilient.

Matthias Wichtlhuber from the German Internet Exchange DE-CIX found that DDoS attackers only use certain protocols for their amplification attacks:

• unspecified (Port 0)
• NTP (Port 123)
• LDAP (Port 389)
• DNS (Port 53)
• Chargen (Port 19)
• Memcache (Port 11211)

Filtering these ports (in transport networks) will stop most DDoS attacks. The problem is that most ISPs cannot do fine-grained filtering. Most can only filter on networks or IP addresses, which blocks all traffic from or to a certain machine. DE-CIX has developed a new fine-grained black-holing system for DDoS attacks that is currently in beta testing.

Koen van Hove, also from the University of Twente, presented the DDOS clearinghouse: a project to collect data of DDoS attacks in a central place. The aim is to be able to research DDoS attacks and develop fast responses to them. The DDoS clearinghouse collects network measurements, identifies DDoS attacks across networks with unique fingerprints, and stores this data in a database (DDoSDB). From the database, attack information and metadata can be retrieved to help users feed fingerprint signatures into their network systems to stop DDoS attacks.

DNS

After the morning break, the main topic was DNS. David Huberman from ICANN discussed the root server system. After talking about the history of the DNS root server system, he explained that there has been no process so far for selecting new root server operators.

With over 1.120 root server instances in the world, 340 of which are in the RIPE region, the root server system is stable and there is currently no need to add additional root server operators beyond the 12 that run the 13 logical root-server addresses. ICANN is not working on a defined governance model for the root server system.

OpenINTEL

Next on the stage was Roland van Rijswijk (NLnet Labs) presenting the OpenINTEL project he has contributed to. OpenINTEL is a massive active measurement system that sends 218 million DNS queries per day from several vantage points on the Internet, resolving a defined set of DNS names. The results will be collected in a big database (Big Data helps to get research funds these days), which so far contains 3.1 trillion results since the start of the project in 2015.

The OpenINTEL system allows researchers to search for various kinds of interesting data: parent-child TTL mismatches, distribution of authoritative DNS-Servers in different AS networks, or even silly things stored in DNS TXT records (like funny IPv6 addresses or private cryptographic keys). The project can be found at https://openintel.nl

KSK roll

Like always, Geoff Huston (APNIC) delivered a highly entertaining talk, this time about the KSK roll in October 2018.

Officially, there was no impact seen for the DNSSEC validating resolvers. But some operators, like EIR in Ireland, have missed all notices about the roll in the two years leading up to it and failed to change the trust anchor of their DNS resolvers which lead to a full-day outage of their DNS resolver services. Other smaller operators were affected as well, some of which fixed the issue by disabling DNSSEC. All except two have re-enabled DNSSEC after fixing their DNS resolver configurations. Geoff also noted that the DNSSEC trust state signaling (RFC 6975 and RFC 8145) does not work reliably to detect broken KSK rolls in the root zone.

Migration from IPv4 to IPv6

In "Get Ready for Mixed World: Economic Factors Affecting IPv6 Deployment", Brenden Kürbis and Milton Mueller from the Georgia Institute of Technology talked about the economics behind network migration from IPv4 to IPv6.

The problem of IPv6 is that it is not possible to switch off IPv4 right away. Instead, IPv4 must be kept enabled for some amount of time (dual stack deployment). The cost generated due to IPv4 depletion will stay, the cost of introducing IPv6 will come on top. Only after some years will the cost benefits be visible. Depending on the growth pattern of the company and the networks, the first cost savings can appear as early as 4 to 10 years. Larger companies will have more benefit from IPv6, while smaller companies will not see economic benefits. In the following Q&A session, people from the audience challenged some of the assumptions in the research that generated this report.

DNS flag day

In the last DNS talk of the day, Petr Špaček from CZ.NIC and Ondřej Surý from ISC gave some insight into the DNS flag day in February 2019.

DNS vendors (Bind 9, Knot, PowerDNS, Unbound, and others) and large DNS resolver operators (Google, Cloudflare, Quad9, etc.) disabled workarounds for broken EDNS implementations. The workarounds were developed to help with DNS servers on the internet that had faulty implementations of the DNS protocol. However, because the workarounds existed, the operators of these faulty servers had no motivation to fix their systems. The cost of developing and maintaining the workarounds fell to the vendors of the DNS products.

For the February 2019 flag day, there was an estimated breakage of 5.68% of all DNS servers. Two large DNS operators were responsible for 66% of this breakage. The flag day was considered a success, as the pressure generated compelled the operators to fix their systems, and no other significant breakage was reported on that day.

Motivated by the success of this first flag day, the DNS server vendors plan another in 2020. No exact date has been set at the moment. On the next flag day, new DNS software releases will change the default settings for EDNS buffer size from today's 4096 bytes to a value around 1220 bytes. The goal is to prevent fragmentation of IP packets, which is known to be broken in some networks and can be a security risk. For this change, authoritative servers and DNS resolvers must be able to operate over TCP in addition to UDP. The main problem is misconfigured firewalls that block DNS over port 53/TCP.

The flag day website will be updated with detailed information about the date and will include online tests so that DNS administrators can test their systems.

More tomorrow!

RIPE 78 is a busy event, with much more going on than we were able to report here. Do visit the session archives to check the other presentations - there are plenty more good talks to dig into. We’ll be back with more RIPE coverage tomorrow!