IANA, ARIN, and the IPv4 run-out (Series - Part II of IV)

Posted by Michael H. Warfield on December 06, 2010 at 7:48 AM EST.

Problems now and on the horizon with IPv4 extensions

There are already problems which are being created by ongoing efforts to extend the life of IPv4.  In addition to operational and complexity problems some of these have impact on security and incident response in the enterprise, at the ISP and on law enforcement.

Quite some time ago, it was recognized that the address space in IPv4 would be too limited and eventually run out. Many consumers wanted multiple devices in the home and ISPs were unwilling to provide blocks of addresses to individual end consumers or wanted premium prices for these addresses. In response to this, the technique of Network Address Translation, NAT, was developed to allow multiple computers on private addresses to share a single public IP address. Consumers could then have multiple devices in the home with only one public address and without incurring the ongoing expense of multiple addresses. NAT, also called Masquerading in some earlier products, proved to be highly successful and very popular. The vast majority of wireless routers and broadband routers have this facility.

While it did prove to be popular, NAT also brought with it a large share of problems. A number of protocols simply did not work or worked poorly behind NAT. Other protocols and helpers had to be created to work around the deficiencies in NAT. NAT also had the problem in that most, in particularly the most popular, forms of NAT involve some sort of "state engine" to manage the NAT tables and which very closely resembles a stateful firewall. Most often, devices implementing NAT, implement it as part of the firewall logic. In particularly, the Linux operating system, used in a large percentage of wireless routers and NAT devices, implements NAT as a component of its "iptables" firewall logic. Because of this tight association with stateful firewalls, the misconception that the NAT itself provides some sort of security benefit has grown up and become a popular, common, belief that is difficult to dispel. NAT itself was not designed with security as a feature, that wasn't the problem set they were trying to address. There have been some attacks against NAT devices and certainly NAT has provided no impediment to malware, botnets, and "reverse shells" any more than a good stateful firewall. Some forms of NAT, simply mapping blocks of addresses onto other blocks of addresses, may provide no inherent firewalling and provide no added security benefit. At the same time, NAT makes accountability more difficult by breaking the end to end addressing. Tracing based on IP address can only take you back to the NAT device and very few NAT devices log or track NAT state table changes. This was fine as long as the NAT device was in the home or at an end client enterprise. This form of NAT is referred to in some networking circles as NAT44 because it is NATing IPv4 to IPv4.

Things have become significantly more complicated with the impending IPv4 address run-out. Now it's not going to merely be the end users who can not obtain sufficient addresses at a reasonable price but even the ISPs who will be short on supplies of addresses. Still, they do not want to deny addresses to their customers or break their customers' applications or access to services. Enter Carrier Grade NAT, or CGN. This is sometime called LSN for Large Scale NAT, or NAT444 for NAT IPv4 to IPv4 to IPv4, or sometimes CGNAT. Whatever you call it, it amounts to basically the same thing and that's NAT at the ISP where multiple customers with receive specially reserved addresses behind the NAT and share a more limited pool of public addresses. Since most customers will also be using NAT44 devices, these amount to NAT behind NAT and the end consumer NAT44 devices will not be receiving public addresses but CGN private addresses. These addresses will be in a different prefix than the private addresses normally used by NAT44 devices to avoid collisions and conflicts. This is going to create multiple problems for usability and security, even for those not operating behind CGN at their ISP.

For end users, this will break a number of applications in a number of unpredictable ways. Some network based games are known not to work or work unpredictably behind this sort of setup and vendors are going to have to adapt. Certain VPNs, ones which depend on a NAT bypass, are not going to work as soon as they are placed behind an additional layer of NAT lacking that bypass and mapping. Many NAT44 devices have the ability to share their "public" address with one or more devices behind them. That will not work when that address is not "public". Some enterprises may find that their "road warrior" or remote employees begin to have difficulty connecting to company resources and this breakage will be difficult to diagnose if it's not recognized as a GGN problem. With the explosion of mobile devices and mobile computing, these are most likely to become the first that are impacted by this, due to both their number and their newness.

For security and incident response the problem of accountability comes in. The IP address now will only take you back to the ISP. Even assuming the ISP is tracking and logging and preserving all the dynamic state table changes in their CGN devices, it will still require the IP address, the port number, and the precise time of day in order to track an incident back through the ISP to an end customer. In some extreme cases, it may even require both addresses and both port numbers. This also depends on both the enterprise and the ISP maintaining accurate timebases on all their devices to make it possible to correlate time stamps. This rapidly has an impact on any enterprise concerned about incident response because it will be impossible to tell when the other end device is behind a CGN device or not, so this tracking information has to be accurately and precisely gathered and kept, regardless, or the information can become unpredictably useless. It can be expected that the criminal elements will recognize this as well and find some way to take advantage of this new layer of anonymity.

This situation becomes only more complicated for law enforcement and investigations. Now you may have multiple players and they have to collect and correlate an increasing amount of data and depend on the accuracy and precision of all the reporting and investigative parties. This already has some in law enforcement concerned as shown by some of the comments by the attendees at the ARIN conference. IANA and the RIRs are aware of these concerns and aware that law enforcement may be strongly inclined to impose new tracking and logging requirements in order to address some of these issues.

For the ISP, they're caught between a rock and a hard place. They want to provide service to their customers without disruption and CGN is one way to address that. They already have some requirements regarding log retention, depending on their region. But now, the requirements may expand the amount of data they have to collect and retain by an order of magnitude or more. Where once they could log login/ppp/line information and dhcp leases for their clients, now they will have to log source and destination addresses and ports along with time stamps of the state changes. While dhcp leases may vary every few days or weeks or even months, NAT tables can change minute to minute. The simpler form of CGN will simply map a customer CGN address to one of their addresses in their public pool. That's simple to track and will change more often than dhcp or ppp but not excessively at first. It gets worse when the number of active customers exceed that pool and customers are then sharing public addresses and are mapped based on port number and/or destination address and port and those start to change with more frequency.

Even where strict formal legal requirements for data retention are not present, ISPs may be expected to present log data and dhcp data in response to subpoena either from a law enforcement organization, LEO, or in the case of lawsuits.  These sorts of cases are already taking place in both criminal and civil legal settings.  NAT state table data is not normally something which has ever been tracked or logged in the first place and this situation is going to complicate those legal situations.  It's foreseeable that this could result in situations mandating retention of this data under court order.  So the capacity to track this information and retain it is going to have to exist sooner or later.

The run out of IPv4 addresses will have an impact on enterprises before they are ever actually subject to an inability to obtain addresses for themselves. The scene is not pretty.