‹ Back
Deploy360 30 January 2017

ION Islamabad: Pushing IPv6 and DNSSEC deployment in Pakistan

Kevin Meynell
By Kevin MeynellSenior Manager, Technical and Operational Engagement

The Deploy360 team was straight into action in 2017 with our first ION Conference of the year. This was held on 25 January 2017 at the Higher Education Commission Headquarters in Islamabad, Pakistan, and attracted 71 participants from across South Asia. The event was hosted by the Pakistan Telecommunications Authority and the Higher Education Commission of Pakistan, was sponsored by Afilias, and was co-located with the 29th South Asia Networking Operators Group (SANOG) meeting which was held over the previous two days.

The conference was chaired by Kevin Meynell from the Deploy360 team who opened proceedings with an overview of the Deploy360 programme, before handing over to Champika Wijayatunga (ICANN) 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 compromised such as cache poisoning and query interception. 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 and 87% of TLDs were now signed, although this unfortunately didn’t currently include the .pk TLD. However, this dropped to only 3% for Second-Level Domains (SLDs), which could be attributed to a lack of knowledge and interest in deploying DNSSEC, as well as a lack of support from registrars claiming a subsequent lack of demand.

Whilst the new ICANN registrar agreement requires registrars to support DNSSEC, organisations could increase deployment by signing their zones and turning on validation on their DNS resolvers. A number of DNSSEC management tools were available for BIND, NSD and PowerDNS, as well as DNS appliances offering fully automated key generation, signing and roll-over. Users should similarly request their ISPs to turn on validation, as it was in the interests of all Internet users for DNSSEC to be widely deployed.

Jan Žorž followed-up on another application of DNSSEC, whereby it can be used in conjunction with DNS-based Authentication of Name Entities (DANE) to validate digital certificates. These are commonly used by TLS to validate a remote site and provide encryption between a server and client, but are currently issued by Certificate Authorities (CAs) who can actually issue a certificate for any domain and may do so erroneously. DANE provides an alternative by allowing certificates to be stored in the DNS and signed with DNSSEC, enabling end users to validate that the correct certificate is being used.

Jan explained how he’d deployed and tested DANE in the Go6lab which has previously been covered in the Let’s Encrypt certificates for mail servers and DANE blogs. However, the message is that deployment can be straightforward and 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.

Following the break, Aftab Siddiqui 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. The Boundary Gateway Protocol (BGP) underpins the Internet routing system, but is substantially based on global trust and there is little validation of the legitimacy of routing updates. For example, there was a particularly well-known incident in 2008 whereby a local routing update in Pakistan resulted in YouTube becoming unavailable in large parts of the world.

There are some techniques that can be employed to improve trust such as IP prefix and AS-PATH filtering, RPKI, IRR, Whois and Peering databases, whilst BGPSEC is under development at the IETF. Nevertheless, these could be more effectively deployed, and a particular issue is that it’s only beneficial for network operators to take these if a significant number of others are also doing the same. MANRS therefore aims to promote a culture of collective responsibility through four actions that include filtering, anti-spoofing, coordination and address prefix validation.

90 network operators had already signed-up to MANRS, and a number of resources have been developed to help others implement the actions. This includes the MANRS Best Current Operational Practice which is a technical document providing step-by-step instructions, along with a set of online training modules. MANRS was currently looking for partners interested to include the modules within their own training curricula, as well as helping develop a MANRS certification programme. Network operators can sign-up for this on the Routing Resilience Manifesto website.

A major theme of any ION Conference is IPv6, and Pubudu Jayasinghe (APNIC) provided an overview of IPv6 adoption in the Asia-Pacific region. Over 48% of Internet users were located in the Asia-Pacific region, with China and India accounting for over a billion of the approximately 3.4 billion users globally. However, with over 3.5 billion potential users in the region, it was clear that IPv4 would be insufficient to meet future needs, and APNIC had less than 50% of its final /8 available.

Unfortunately, IPv6 deployment was lagging in South Asia, with just over 5% of users being IPv6 capable. Even this belied realities as India distorted the figures with a 15% capability, whereas all other countries bar Sri Lanka (2%) barely registered. Pakistan had a 0.1% deployment rate for IPv6, with Google (97%) being far ahead of the Pakistan Education and Research Network (0.66%) in second place.

Aftab then provided some additional information about the status of IPv6 in Pakistan. The country currently had around 5.3 million IPv4 addresses for a population of over 200 million, which effectively meant that even using Network Addressing Translation (NAT) techniques, current address allocations could serve a maximum of 1.5 sessions per user. This would simply be insufficient for a functional Internet, but it would simply not be possible to obtain any more IPv4 addresses in future.

Turning to IPv6 in Pakistan, there were currently 69 Local Internet Registries (LIRs) that had obtained IPv6 addresses. The interesting factor though, was that the most prolific deployers of IPv6 were smaller operators, whereas the larger operators other than PERN barely appeared in the figures. A conclusion that might be drawn is these smaller operators will have a competitive advantage over the others in future, which means they need to be planning for the transition to IPv6 by applying for addresses, sending technical staff to IPv6 training, and looking into how to provide IPv6 services to customers.

This theme continued during the lively panel session on IPv6 success stories that was moderated by Kevin with participation from Zaeem Arshad (Rapid Compute), Yoshinobu Matsuzaki (Internet Initiative Japan), Jawad Raza (PERN) and Jan. The discussion kicked-off with the IPv6 deployment experiences of the local network operators, and the reasons why there appeared to be reluctance to deploy IPv6 in Pakistan. The feeling was that local operators did not see it as a priority, combined with a concern that it might prove problematic. However, it was clear that NAT was causing significant performance and management issues, and neither could it accommodate future demand for IPv4 within Pakistan.

The panel added that all modern operating systems could support IPv6, and that hardly anyone would think of using older obsolete versions. The same consideration should apply to the IP protocols, especially as it was possible to ensure that IPv6 had backwards compatibility with IPv4 using NAT64 and DNS64. By employing these techniques, the user experience should not be worsened when accessing IPv4 services, but will provide a better service when using IPv6 natively. Many major services such as Google, Facebook and LinkedIn already support IPv6, and as more switch over, clients would automatically connect with IPv6 without the need for an intervening translation mechanism.

To conclude the day, Kevin talked about what was happening at the IETF and how to get involved. He pointed out that had been 1,042 participants from 52 countries at the last IETF in Seoul, but just 3 from Pakistan. There was clearly an active Internet community in Pakistan but limited engagement with the IETF, so he encouraged the local community to check out the IETF Fellowship and IETF Policy programmes.

Deploy360 would like to thank SANOG, the Pakistan Telecommunication Authority and the Higher Education Commission of Pakistan for hosting and supporting this ION. Thanks also to the speakers and everyone else who contributed towards making the event a successful and productive one.

Further Information

The proceedings from ION Islamabad are available here, and the webcast will  also be available on our YouTube channel shortly.

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.

‹ Back

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...