Essays academic service

Architecture for secure ipv4 ipv6 address translation

Thaler Request for Comments: Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http: Please review these documents carefully, as they describe your rights and restrictions with respect to this document. What is the problem? Homogenous Edge Network Configurations. Introduction In the past, the IAB has published a number of documents relating to Internet transparency and the end-to-end principle, and other IETF documents have also touched on these issues as well.

These documents articulate the general principles on which the Internet architecture is based, as well as the core values that the Internet community seeks to protect going forward.

Most recently, RFC 4924 [ RFC4924 ] reaffirms these principles and provides a review of the various documents in this area. Facing imminent IPv4 address space exhaustion, recently there have been increased efforts in IPv6 deployment. However, since late 2008 there have also been increased discussions about whether the IETF should standardize network address translation within IPv6.

People who are against standardizing IPv6 NAT argue that there is no fundamental need for IPv6 NAT, and that as IPv6 continues to roll out, the Internet should converge towards reinstallation of the end- to-end reachability that has been a key factor in the Internet's success. However, it also identifies several gaps remaining to be filled.

This document provides the IAB's current thoughts on this debate. We believe that the issue at hand must be viewed from an overall architectural standpoint in order to fully assess the pros and cons of IPv6 NAT on the global Internet and its future development. Network address translation is viewed as a architecture for secure ipv4 ipv6 address translation to achieve a number of desired properties for individual networks: However, renumbering is still quite painful today, as discussed in [ RFC5887 ].

Currently it requires reconfiguring devices that deal with IP addresses or prefixes, including DNS servers, DHCP servers, firewalls, IPsec policies, and potentially many other systems such as intrusion detection systems, inventory management systems, patch management systems, etc.

In practice today, renumbering does not seem to be a significant problem in consumer networks, such as home networks, where addresses or prefixes are typically obtained through DHCP and are rarely manually configured in any component.

However, in managed networks, renumbering can be a serious problem.

The use of PI addresses is inherent in today's Internet operations. However, in smaller managed networks that cannot get provider-independent IP address blocks, renumbering remains a serious issue. Regional Internet Registries RIRs constantly receive requests for PI address blocks; one main reason that they hesitate in assigning PI address blocks to all users is the concern about the PI addresses' impact on the routing system scalability.

Site Multihoming Another important requirement in many networks is site multihoming. A multihomed site essentially requires that its IP prefixes be present in the global routing table to achieve the desired reliability in its Internet connectivity as well as load balancing. In today's practice, multihomed sites with PI addresses announce their PI prefixes to the global routing system; multihomed sites with provider-allocated PA addresses also announce the PA prefix they obtained from one service provider to the global routing system through another service provider, effectively disabling provider- based prefix aggregation.

This practice makes the global routing table scale linearly with the number of multihomed user networks. Unfortunately, no solution except NAT has been deployed today that can insulate the global routing system from the growing number of multihomed sites, where a multihomed site simply assigns multiple IPv4 addresses one from each of its service providers to its exit router, which is an IPv4 NAT box.

Using address translation to facilitate multihoming support has one unique advantage: Intuitively, it also seems straightforward to roll the same solution into multihoming support in the IPv6 deployment. However, one should keep in mind that this approach brings all the drawbacks of putting a site behind a NAT box, including the loss of reachability to the servers behind the NAT box.

It is also important to point out that a multihomed site announcing its own prefix es achieves two important benefits that NAT-based multihoming support does not provide.

First, end-to-end communications can be preserved in face of connectivity failures of individual service providers, as long as the site remains connected through at least one operational service provider. Second, announcing one's prefixes also gives a multihomed site the ability to perform traffic engineering and load balancing. Homogenous Edge Network Configurations Service providers supporting residential customers need to minimize support costs e.

Often a key factor in minimizing support costs is ensuring customers have homogenous configurations, including the addressing architecture. Today, when IPv4 NATs are provided by a service provider, all customers get the same address space on their home networks, and hence the home gateway Thaler, et al.

From a customer-support perspective, this perhaps represents the most important property of NAT usage today.

In IPv6, link-local addresses can be used to ensure that all home gateways have the same address, and to provide homogenous addresses to any other devices supported by the service provider.

Unlike IPv4, having a globally unique address does not prevent the use of a homogenous address within the subnet. It is only in the case of multi-subnet customers that IPv6 NAT would provide some homogeneity that wouldn't architecture for secure ipv4 ipv6 address translation provided by link-local addresses. For multi-subnet customers e. It is currently unknown whether IPv6 link-local addresses provide sufficient homogeneity to minimize help desk calls.

Network Obfuscation Most network administrators want to hide the details of the computing resources, information infrastructure, and communications networks within their borders. This desire is rooted in the basic security principle that an organization's assets are for its sole use and architecture for secure ipv4 ipv6 address translation information about those assets, their operation, and the methods and tactics of their use are proprietary secrets.

Some organizations use their information and communication technologies as a competitive advantage in their industries. It is a generally held belief that measures must be taken to protect those secrets.

The first layer of protection of those secrets is preventing access to the secrets or knowledge about the secrets whenever possible. It is understandable why network administrators would want to keep the details about the hosts on their network, as well as the network infrastructure itself, private. They believe that NAT helps achieve this goal. Hiding Hosts As a specific measure of network obfuscation, network administrators wish to keep secret any and all information about the computer systems residing within their network boundaries.

  • If effective solutions can be deployed in time to allow assigning provider-independent IPv6 addresses to all user communities, the Internet can avoid the complexity and fragility and other unforeseen problems introduced by NAT;
  • It may be possible to infer some aspects of topological information from passively observing packets;
  • After much observation and correlation, the attacker could sometimes determine if an observed new connection in flight is from a familiar host;
  • Simple Security It is commonly perceived that a NAT box provides one level of protection because external hosts cannot directly initiate communication with hosts behind a NAT;
  • Hence, such an approach can adversely affect legitimate communication at all times, simply to raise the bar for an attacker;
  • In the remainder of this section, the term "reachability" is used with respect to wanted traffic.

Such computer systems include workstations, laptops, servers, function-specific end-points e. They want to prevent an external entity from counting the number of hosts on the network.

  1. This is not, however, a thorough mapping.
  2. An attacker might then use message contents to lump certain types of devices into logical clusters, and take educated guesses at attacks.
  3. Solutions can then be compared based on other aspects such as scalability and ease of deployment.

They also want to prevent host fingerprinting, i. For example, they want to hide the role of a host, as whether it is a user workstation, a finance server, a source code build server, or a printer. A second element of host-fingerprinting prevention is to hide details that could aid an attacker in compromising the host. Such details might include the type of operating system, its version number, any patches it may or may not have, the make and model of the device hardware, any application software packages loaded, those version numbers and patches, and so on.

With such information about hosts, an attacker can launch a more focused, targeted attack.

Operators want to stop both host counting and host fingerprinting. Where host counting is a concern, it is worth pointing out some of the challenges in preventing it. More complex NAT deployments, e. This observation follows the age-old axiom for networked computer systems: If fields such as fragment ID, TCP initial sequence architecture for secure ipv4 ipv6 address translation, or ephemeral port number are chosen in a predictable fashion e.

To prevent counting hosts by counting addresses, one might be tempted to use a separate IP address for each transport-layer connection. Such an approach introduces other architectural problems, however. Within the host's subnet, various devices including switches, routers, and even the host's own hardware interface often have a limited amount of state available before causing communication that uses a large number of addresses to suffer significant performance problems.

In addition, if an attacker can somehow determine an average number of connections per host, the attacker can still estimate the number of hosts based on the number of connections observed. Hence, such an approach can adversely affect legitimate communication at all times, simply to raise the bar for an attacker. The way that different hosts respond to different requests and sequences of events will indicate consistently the type of a host that it is, its OS, version number, and sometimes applications installed, etc.

Products exist that do this for network administrators as a service, as part of a vulnerability assessment. These scanning tools initiate connections of various types across a range of possible IP addresses reachable through that network. Architecture for secure ipv4 ipv6 address translation observe what returns, and then send follow-up messages accordingly until they "fingerprint" the host thoroughly. When run as part of a network assessment process, these tools are normally run from the inside of the network, behind the NAT.

If such a tool is set outside a network boundary as part of an external vulnerability assessment or penetration test along the path of packets, and is passively observing and recording connection exchanges, over time it can fingerprint hosts only if it has a means of determining which externally viewed connections are originating from the same internal host. With the internal hosts mapped to their external IP addresses and fingerprinted, the attacker can launch targeted attacks into those hosts, or reliably attempt to hijack those hosts' connections.

If the NAT uses a single external IP, or a pool of dynamically assigned IP addresses for each host, but does so in a deterministic and predictable way, then the operation of fingerprinting is more complex, but quite achievable. If the NAT uses dynamically assigned addresses, with short-term persistency, but no externally learnable determinism, then the problem gets harder for the attacker.

The observer may be able to fingerprint a host during the lifetime of a particular IP address mapping, and across connections, but once that IP mapping is terminated, the observer doesn't immediately know which new mapping will be that same host.

After much observation and correlation, the attacker could sometimes determine if an observed new connection in flight is from a familiar host. With that information, and a good set of man-in-the-middle attack tools, the attacker could attempt to compromise the host by hijacking a new connection of adequately long duration. If temporal persistency is not deployed on the NAT, then this tactic becomes almost impossible.

As the difficulty and cost of the attack increases, the number of attackers attempting to employ it decreases. And certainly the attacker would not be able to initiate a connection toward a host for which the attacker does not know the current IP address binding. So, the attacker is limited to hijacking observed connections thought to be from a familiar host, or to blindly initiating attacks on connections in flight.

This is why Thaler, et al. Topology Hiding It is perceived that a network operator may want to hide the details of the network topology, the size of the network, the identities of the internal routers, and the interconnection among the routers.

This desire has been discussed in [ RFC4864 ], Sections 4. However, the success of topology hiding is dependent upon the complexity, dynamism, and pervasiveness of bindings the NAT employs all of which were described above. The more complex, the more the topology will be hidden, but the less likely that complex connection types will successfully traverse the NAT barrier.

Secure network connections with IPsec

Thus, the trade- off is reachability across applications. Even if one can hide the actual addresses of internal hosts through address translation, this does not necessarily prove sufficient to hide internal topology. It may be possible to infer some aspects of topological information from passively observing packets.

For example, based on packet timing, delay measurements, the Hop Limit field, or other fields in the packet header, one could infer the relative distance between multiple hosts.

Once an observed session is believed to match a previously fingerprinted host, that host's distance from the NAT device may be learned, but not its exact location or particular internal subnet. Host fingerprinting is required in order to do a thorough distance mapping. An attacker might then use message contents to lump certain types of devices into logical clusters, and take educated guesses at attacks.

This is not, however, a thorough mapping. The simpler and more static the NAT, the more possible this is. The more complex and dynamic and non-persistent the NAT bindings, the more difficult.