The Deploy360 team has just returned from Romania where we held our third ION Conference of the year. This was organised jointly with RONOG 3 – the meeting of the Romanian Network Operators Group – on 12 October 2016 at the Novotel Bucharest Hotel, and attracted 85 participants from several countries.
Kevin Meynell opened the event with an overview of the Deploy360 programme, before handing over to Dan York who discussed Deploying DNSSEC. He outlined the problems that DNSSEC aims to solve, whereby end users are assured that information returned from a DNS query is the same as that provided by the domain name holder; running through examples of how the DNS can be hijacked. These assurances are established using cryptographic principles through a chain-of-trust originating from the root DNS servers, and propagated through signed Top-Level Domain (TLD) and subsequent sub-domain zones .
All major DNS resolvers support DNSSEC validation, although some require a configuration change, and around 15% of all global DNS queries are currently validated. Romania was actually significantly better with around 43% of DNS queries being validated overall, with some network operators even validating more than 90%.
A common question was why DNSSEC was required if TLS/SSL is being used. The answer is that whilst TLS can validate a remote site and provide encryption between a server and client, a Certificate Authority (CA) can actually issue a digital certificate for any domain and have done so erroneously in the past. Middle boxes such as firewalls can also re-sign sessions, so end users cannot guarantee that the presented certificate is actually the one the remote site intends them to use. This is where DNS-based Authentication of Name Entities (DANE) is beneficial, as it allows certificate information to be stored in the DNS and signed with DNSSEC to allow end users to validate that the correct certificate is being used. DANE is particularly useful for non-web applications such as SMTP (e-mail) and XMPP (Jabber) where it is difficult to visually identify the validity of a certificate.
Dan finally touched on new developments in DNS Privacy that aims to encrypt queries between clients and resolvers. These are currently sent in the clear, which means it is possible to determine which sites users are visiting. The IETF DPRIVE Working Group is therefore developing a standard to encrypt DNS queries using TLS, with implementations expected in the near future.
Jan Žorž followed-up on DANE adoption in more depth, and how he’d deployed it in the Go6lab. Information on how this was undertaken has previously been covered in the Let’s Encrypt certificates for mail servers and DANE blogs, but the message is that it can be straightforward and with the .ro domain supporting DNSSEC, there are no reasons not to deploy this significant enhancement to network security.
Catalin Leanca (ROTLD) then discussed how they had implemented DNSSEC for the .ro domain. ROTLD is a department of the National Institute for Research and Development in Informatics (ICI), which is a state-owned company coordinated by the Ministry of Communications. As such it is the IANA delegated ccTLD authority for .ro, and currently registered just under 849,000 domains.
ROTLD started experiments with DNSSEC back in 2012, testing different implementations of hardware and software, and then upgrading their registration and monitoring systems to support DNSSEC. This culminated in the signing of the .ro domain in May 2016, with general public availability being introduced in July 2016. At the present time, around 150 domains had been signed in .ro, and ROTLD were currently working to raise awareness through workshops organised for registrars and registrants.
Following the break, Kevin presented the MANRS initiative and Routing Resilience Manifesto which aims to help network operators around the world to improve the security and resilience of the global routing system through four actions that include filtering, anti-spoofing, coordination and address prefix validation.
Attention then turned to IPv6, with Alvaro Vives (RIPE NCC) making the case for why IPv6 should be deployed. 2016 has seen substantial uptake of IPv6 with global adoption (as measured by Google) having risen by nearly 50% since January. The leading region is North America (ARIN) with nearly 18%, with Europe (RIPE) coming in around 11% although Belgium leads the world with over 46% usage. The situation in Romania is actually quite positive at just under 7% usage, especially when compared to neighbouring countries, and whilst no Local Internet Registries (LIRs) currently qualified for the 5-star RIPEness rating, 32% of LIRs did qualify for a 4-star rating and just 17% employed no IPv6 at all.
This led into the lively panel session on IPv6 success stories moderated by Lucian Constantin (IDG News Service) and including Jan and Alvaro. The panel focused on the message that deploying IPv6 was not a complex or expensive process, but IPv4 addresses were a finite resource and were increasingly only obtainable through recovery and trading which would impose a real cost on network providers. The expected growth in mobile and IoT (Internet-of-Things) devices would further pressure existing IPv4 resources, and with major network operator and content providers now actively moving to IPv6, non-adopters would be gradually left behind.
There were questions from the audience about the perceived poorer performance of IPv6 (which we’ve covered in a previous post), as well as the maturity of the protocols. However, it was pointed out it was an unequal comparison as IPv6 peerings were not currently the same or as comprehensive as with IPv4, so connections were sometimes having to take different routes. Similarly, some IPv6 connections were having to traverse gateway or tunnels, but the indications were that under the same conditions, IPv6 performed as well or even better than IPv4. The issue was not the underlying protocol, and as more IPv6 was deployed it was expected that many of the currently observed differences in performance would diminish.
Rounding off the day, Kevin talked about what was happening at the IETF and how to get involved. He pointed out that had been 1,902 registered participants from 70 countries at the recent IETF in Berlin, but just 2 from Romania. There was clearly an active Internet community in Romania but limited engagement with the IETF, so he encouraged the local community to check out the IETF Fellows and Regulators to the IETF programmes.
Deploy360 would like to thank RONOG for hosting this ION, as well as Platinum Sponsors InterLan IX and InfoBlox, Gold Sponsors Tata Communications and IP Broker, Silver Sponsors Internet Society and RIPE NCC, Bronze Sponsor Starnet Media, and Streaming Sponsor Media Sat. Thanks also to the media partners, and to everyone else who contributed towards making the event a successful and productive one.
Further Information
The proceedings from ION Bucharest are available here, and the webcast is also available on our YouTube channel.
If you’re inspired by what you see and read, then please check out our Start Here page to understand how you can get started with DNSSEC, DANE and IPv6.