Deploy360 18 October 2016

ENOG 12 in Yerevan

By Kevin MeynellFormer Senior Manager, Technical and Operational Engagement

The 12th Eurasia Network Operator’s Group (ENOG 12) that was held on 3-4 October 2016 in Yerevan, Armenia featured 251 participants from the host country, the Commonwealth of Independent States and Eastern Europe who came together to discuss operational issues and share expertise about evolving the Internet in the region. This was the second event of the year and was supported by the Armenian Internet Exchange, the RIPE NCC, Ucom, ARPINET, the Internet Society, the Internet Society of Armenia, and UITE.

Richard Lamb (ICANN) had a couple of presentations in the programme, but it’s particularly worth highlighting the one on DNSSEC implementation considerations and risk analysis. He talked about the risks to the DNS and provided some examples of hijacks and man-in-the-middle attacks that had happened in the past years. DNSSEC was arguably the biggest security upgrade to Internet infrastructure in over 20 years, and was now deployed by 1,340 of approximately 1,500 TLDs which essentially means 89% of all domain names have the potential to be secured. However, only 3% of second level domains have currently deployed it, which pointed to a lack of awareness and expertise.

richard-lambNot deploying DNSSEC is no longer an option though. Everyone needs to take responsibility for improving the security of the Internet, and DNSSEC is now widely supported by DNS operators, operating systems and software solutions. Richard then ran through some cost benefit analyses that had been undertaken by various organisations, before outlining some best practices with respect to zone signing and key rollover.

Paul Vixie (Farsight Security) also outlined how the DNS can be used as a defence vector. Many things on the Internet rely on the DNS, and this includes cybercrime. He therefore outlined measures that can be taken to prevent the DNS being abused, and for monitoring the DNS to detect when it is being abused.

Alexandra Kulikova (ICANN) then provided a update on the plans for rolling the Root Zone DNSSEC Key Signing Key. ICANN in its role as the IANA Functions Operator, manages the Key Signing Key (KSK) used to sign the Root Zone Signing Key (ZSK) which is managed by VeriSign and changed every quarter. The current KSK has been used since the Root Zone was first signed in 2010, and whilst it does not have any expiry date, it’s good practice to change keys, the DNSSEC Practice Statement calls for the KSK to be rolled, and ICANN wish to try this exercise under normal rather than emergency conditions (such as a key compromise).

alexandra-kulikovaThe rollover plan is outlined in five documents, with a view to generating the new KSK in the 4th quarter of 2016, adding it to the root zone on 11 July 2017 (in parallel with the old KSK), and then signing the DNSKEY RRset starting from 11 October 2017. The old KSK will be revoked on 11 January 2018, but will remain in the root zone.

Richard Lamb (ICANN) continued to discuss the importance of DNSSEC during his second presentation on the Internet-of-Things (IoT). Lack of a security was a well known concern with IoT, and along with the potential for massive distributed denial-of-service attacks if compromised, many devices also have physical safety implications. DNSSEC can therefore not only provide assurances about what devices were connecting to, but can also support DANE to validate the establishment of secure communication channels.

Changing subjects, Hisham Ibrahim (RIPE NCC) then discussed how IPv6 has been adopted in the ENOG region. There were currently 2,227 Local Internet Registries (LIRs) in the region, of which nearly 34% were announcing IPv6 in the routing table. Another 38% have unannounced IPv6 allocations, with 28% having no IPv6 at all. Russia not unexpectedly leads the way in IPv6 deployment numbers, but Ukraine was ahead in percentage terms of LIRs announcing IPv6. Four countries though, still had no IPv6 deployment at all.

Whilst no LIRs currently qualified for the 5-star RIPEness rating in the region, 21% did qualify for a 4-star rating which was on par with the rest of the RIPE service area. Armenia was even further ahead with 12 LIRs (50%) having achieved a 4-star rating, and just 3 (12%) having no IPv6 at all.

Hisham highlighted a couple of RIPE documents that can help with IPv6 deployment: ripe-554: Requirements for IPv6 in ICT Equipment and ripe-631: IPv6 Troubleshooting for Residential ISP Helpdesks (both co-authored by Deploy360 team member Jan Žorž), as well as referring to a case study where T-Mobile US deployed 464XLAT and IPv6 only. In fact, this case study can be found on the Internet Society’s Deploy360 website.

It’s also worth mentioning that Anton Baskov also 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.

iana-transitionA significant part of the programme was devoted to the IANA transition. Along with presentations on  the NTIA Stewardship Transition from Michael Yakushev (ICANN) and an evaluation of the process and outcomes for the Internet community from Oleg Demidov (PIR Center), there was a round table discussion involving Anton Baskov (Moderator), Oleg Demidov and Michael Yakushev, as well as Dmitry Burkov (RIPE NCC Executive Board), Dmitry Kohmanuk (Hostmaster Ltd) and Axel Pawlik (RIPE NCC).

There was an excellent analysis of connectivity within the Caucasus region from Alexander Azimov who measured connectability and reliability of AS numbers. Armenia, Azerbaijan, Georgia and adjacent Russia should be within 30ms of each other, yet observed latencies were often significant higher than this. It suggests that connections and routing are not as optimal as they could be, and there’s significant room for improvement.

George Gotoshia (Newtelco) also announced the launch of the first Georgian Internet Exchange (GIX) , that had just been founded in Tbilisi by eight ISPs. This was supplemented by a presentation from Timothy Denton (Hurricane Electric) on how to think about IXPs if you are a telecom regulator.

Finally, Kevin Meynell from the Deploy360 team spoke about the case for national Computer Security and Incident Response Teams (CSIRTs). Whilst not a usual Deploy360 topic, he had previous involvement with the CSIRT community which was less well developed in many of the ENOG countries. CSIRTs were important elements in responding to cyberattacks and dealing with IT security compromises, but they usually served particular constituencies and many security incidents required a cross-constituency or international approach. National CSIRTs provided an official point of contact in each country, as well as mechanism to coordinate incident response.

Kevin outlined the basic requirements for a CSIRT, and the various types of reactive, proactive and security quality services that can be offered. He also outlined the different types of model for running a national CSIRT, how CSIRTs are recognised by the international CSIRT community, and the types of training that’s available for CSIRT personnel.

All the presentations from the meeting can be found on the ENOG website. The next ENOG meeting will be held on 23-24 May 2017 in St. Petersburg, Russia.

Disclaimer: Viewpoints expressed in this post are those of the author and may or may not reflect official Internet Society positions.

Related articles

Improving Technical Security 15 March 2019

DNS Privacy Frequently Asked Questions (FAQ)

We previously posted about how the DNS does not inherently employ any mechanisms to provide confidentiality for DNS transactions,...

Improving Technical Security 14 March 2019

Introduction to DNS Privacy

Almost every time we use an Internet application, it starts with a DNS (Domain Name System) transaction to map...

Improving Technical Security 13 March 2019

IPv6 Security for IPv4 Engineers

It is often argued that IPv4 practices should be forgotten when deploying IPv6, as after all IPv6 is a...