Putting 'hijack' of IP addresses in the clear

newsmaker In its quest to serve the next billion Internet users, many of whom will are from Asia, the APNIC (Asia Pacific Network Information Centre) is aware it needs to continuously improve and invest, even under strained economic times.

The center provides registration services to support Internet addressing in the region, as well as supports technology and standardization efforts. It has spent much of this year touching on the need to prepare for and embrace IP version 6 (IPv6).

Geoff Huston, chief scientist at the APNIC, told ZDNet Asia in an e-mail interview that investment for the future also relates to considerable effort to understand the directions of technology evolution and the implications of such directions on the regional Internet and the players within our region.

The veteran discussed the APNIC's recently-launched Resource Certification program, and other issues the organization will be closely focusing on in the coming year.

Q: The APNIC introduced the resource certification last month. How does that work, and what do the APNIC members have to do?
Huston: Knowing that an Internet IP address is unique, and knowing which party has the exclusive "right-of-use" of each address, is fundamental to the integrity of the network itself.

In the same way that the telephone network would descend into chaos if telephone numbers were no longer unique, the Internet would also fail to work if IP addresses were no longer unique. So, the APNIC's public registry of address allocations and the comparable registries maintained by the other Regional Internet Registries (RIRs), is an essential part of the infrastructure of the network.

This address allocation database is conventionally published as a "whois" service, so that, for example, "whois -h whois.apnic.net 203.119.0.0" (or using the whois search at http://www/apnic.net) will display details of the current holder of the address block 203.119.0.0/24. But while this kind of textual publication is good for human users of the registry, it is not readily integrated into automated systems and from a strictly security perspective, this form of lookup and response is relatively insecure.

Resource certificates use digital certification technology. The APNIC certifies a resource allocation and publishes a digital certificate to that effect. This allows a resource holder to sign an attestation regarding its right-of-use of an address block in such a manner that the attestation can not be subsequently altered or tampered with and the digital signature can be used to verify the authenticity of the attestation.

For example, "Dear ISP, please route the address 203.119.0.0/24 to my connection" signed [by] a customer, is a request that many ISPs receive continually when they are asked to route a customer's IP address block. Authenticating that the customer has the appropriate right-of-use of that address can however be quite a difficult task at times. If the customer was able to sign such a request using a digital signature then the ISP could use the resource certificate system to verify the authenticity of the request and the customer's right to actually have the use of the address in question.

Digital signatures prevent tampering and can be used to authenticate both the identity of the author of the request and also the authority of the author in terms of the rights being conveyed by the request.

Generating digital certificates and using them to sign attestations has been enabled in the APNIC Member portal, MyAPNIC. Resource holders can maintain a collection of digital certificates and use the MyAPNIC portal system to digitally sign various forms of attestations about addresses and their use. In its basic form, no new systems or processes are required at the customer end. This is envisaged to match the requirements of the majority of users.

However, there are some large ISPs out there and these enterprises may want to place such security-related functions in-house rather than outsourcing them. For these enterprises there is open source resource certificate management software that allows an enterprise to manage these resource certificates themselves.

The digital certificate/PKI system is not invulnerable, is it?
In terms of the encryption that is currently available, it is very strong! Using a 2048-bit private key, a digital signature is relatively invulnerable to attack within the bounds of current technology and computer capability.

But tomorrow's environment will no doubt include greater computational capacity and at some stage the secure system will need to evolve to use keys with longer bit lengths, or perhaps move to an entirely different algorithm to generate the cryptographic keys used in these digital signatures. This is an issue for Internet security mechanisms.

What challenges does the APNIC, and/or its members, face in the implementation of Resource Certification? Is certification compulsory? What happens if there are uncertified parties?
It is early days in some respects. There are many possible uses for certification systems and no single use, or set of uses, has become "commonplace". Domain name certificates found a solid use case in securing Web sites, particularly in the finance sector. It may well be that address certificates will be used to make the routing subsystem of the Internet more secure, so that efforts to disrupt or attack the Internet via the injection of false information into the routing system can be reliably and rapidly detected through the use of resource certificates and a secure routing framework. If the routing information can be validated using address certificates, then attempts to falsely claim control over someone else's addresses or routes would be readily identifiable.

However, secure systems face many challenges, and the major one is the cost/benefit recognition on the part of the user community. Good security can be complex and requires adherence to procedures which entail some additional cost. The benefits can often be quite intangible, in that security is a risk mitigation exercise most distinct from a revenue raising activity. For this reason, we've attempted to design a security system for IP addresses with the minimum possible overhead to the user of the system. We've tried to make it simple and effective.

Certification is by no means compulsory. Each address holder has the choice to certify their resources or not. Certification and the use of digital certificates, is a form of self-protection, in the same way that a homeowner secures the contents of their house with locks on the doors and windows. The locks are of course optional, but if they are not used then the assets are more exposed to risks of theft. In the same fashion, an address holder can chose not to certify their address holdings. This, in turn, can expose the address holder to unauthorized use of their addresses in a manner that is not readily detectable by others.

Certification of addresses does not prevent others from attempting to "hijack" addresses, but it does make the "hijack" readily detectable by everyone else. In other words, it is a risk mitigation exercise against a serious form of attack.

Now that we have built the framework for Resource Certification, we are continuing our work with the technical community to assist in the implementation of this technology. The next step for this project will be further work with the Internet Engineering Task Force (IETF), to assist with the creation of client-side code that can be integrated into network security applications.

Is this initiative available in other regions? How do routing parties ascertain the credibility of counterparts from other regions?
Comparable work is underway in the North American Internet Registry, ARIN, and in the Europe and the Middle East Registry, the RIPE NCC.

We have been standardizing the technology in the IETF (Internet Engineering Task Force), so we are confident that these systems are fully interoperable and that tools and procedures used in the context of verifying digital signatures using APNIC-issued certificates will also process certificates issued by ARIN and the RIPE NCC in the same way. The same toolset can verify digital signatures using certificates issued by any of the RIRs, so from the end user's perspective there is no distinction between the various regions in terms of resource certificates.

Given that it took eight years of work for the resource certification framework to be ready, realistically, how long will such a trusted ecosystem be in effect?
In some ways, the outcome depends on the urgency of the problem. While it is true that the original motivation of improving the security of the routing system has proved to be a motivation that has not generated any particular sense of urgency in the broader industry to date, the relevant consideration here is that resource certificates do have a broader application than just routing security.

In a couple of years, the existing supply channels for IPv4 will be exhausted. However, it is also the case that there is a very strong need for more IPv4 addresses at present and it seems unlikely that this demand will simply stop once the existing supply systems are exhausted. While many folk will move on an IPv6 strategy, it is still the case that IPv4 will be in demand for many years to come.

Once the unallocated IPv4 address pool is exhausted the only way that demand will be met will be via a party-to-party address transfer mechanism. If so, how can each party verify the bona-fides of the other party? Are those addresses really under the control of the potential disposer? How can the transfer the verified?

Resource Certificates can answer these questions with ease, as they are all questions about title and the "right-of-use" of an address. Resource certificates can have a central role in assuring the integrity of any address transfer framework, and allow assertions about addresses and their current use to be formally verified using strong cryptography. While securing routing may not be seen by the broader Internet industry as an urgent problem, the transfer of IPv4 addresses does have a strong imminent timing given the estimated two years only remaining for the current IPv4 address supply mechanism and the evident need to support the IPv4 address transfer mechanism thereafter.

The resource certification involves the use of the AS system. How will the introduction of four-byte or 32-bit AS numbers by default from Jan. 1 impact the framework?
The system was designed with 4-byte AS number in mind. This will not impact the framework at all.

The APNIC said in July that network operators need to upgrade routers and network management software to handle the increased distribution of four-byte AS numbers. What is your current assessment of the region’s upgrading work, and what implications would that have on the routing on Internet traffic?
The story with the introduction of 4-byte AS numbers is not straightforward. At one level the introduction of 4-byte AS numbers is entirely transparent to the existing network, and network operators need do nothing at all. Sixteen of these 4-byte AS numbers are on the Internet already and no one has had to alter anything at all for this to happen. This is because the 4-byte implementation is entirely backward-compatible with the existing infrastructure.

However, this is not entirely the full story, and some network management systems use AS numbers as the "lookup key" for their customers. For this sub-class of networks the issues with the introduction of 4-byte AS numbers will present some challenges. In this environment, the network will see the new 4-byte AS numbers using their 2-byte common equivalent value, namely 23456. In other words there is the risk that each new customer with a 4-byte AS number will appear to be an existing customer who is using AS 23456.

This is the aspect of the network operational environment that will need to be addressed, and, by all reports, this has been somewhat tardy, not just in the Asia-Pacific region, but across the entire Internet.

The second consideration is for new networks. These networks will be allocated 4-bytes AS numbers by default, and the routers used in these new networks will need to recognize 4-bytes AS numbers.

So not all networks has to change, only new networks, and a number of customer support systems that have 2-byte limitations in their AS number support. This is of course a much smaller subset of the network, and this will not have any major impact on the network's ability to route traffic.