Chapter 7. Firewalls and Network Address Translation (NAT)

Perhaps ironically, the development and eventual widespread use of NAT has contributed to significantly slow the adoption of IPv6. TCPv1

Many security problems (attacks) were caused by bugs or unplanned protocol operations in the software implementations of Internet hosts. Fixing the problem would have required a way to control the Internet traffic to which the end hosts were exposed. Today, this is provided by a firewall, a type of router that restricts the types of traffic it forwards. [p299]

As firewalls are being deployed, another problem was becoming important: the number of available IPv4 addresses was diminishing, with a threat of exhaustion. One of the most important mechanisms developed to deal with this, aside from IPv6, is called Network Address Translation (NAT). With NAT, Internet addresses need not be globally unique, but can be reused in different parts of the Internet, called address realms. This greatly eased the problem of address exhaustion.

Firewalls

Given the enormous management problems associated with trying to keep end system software up-to-date and bug-free, the focus of resisting attacks expanded

Today, several different types of firewalls have evolved.

The two major types of firewalls commonly used include proxy firewalls and packet-filtering firewalls. The main difference between them is the layer in the protocol stack at which they operate, and consequently the way IP addresses and port numbers are used. The packet-filtering firewall is an Internet router that drops datagrams that (fail to) meet specific criteria. The proxy firewall operates as a multihomed server host from the viewpoint of an Internet client. That is, it is the endpoint of TCP and UDP transport associations; it does not typically route IP datagrams at the IP protocol layer.

Packet-Filtering Firewalls

Packet-filtering firewalls act as Internet routers and filter (drop) some traffic. They can generally be configured to discard or forward packets whose headers meet (or fail to meet) certain criteria, called filters.

Popular filters involve:

Stateless and stateful:

[p300]

A typical packet-filtering firewall is shown below.

In this figure

A typical packet-filtering firewall configuration. The firewall acts as an IP router between an “inside” and an “outside” network, and sometimes a third “DMZ” or extranet network, allowing only certain traffic to pass through it. A common configuration allows all traffic to pass from inside to outside but only a small subset of traffic to pass in the reverse direction. When a DMZ is used, only certain services are permitted to be accessed from the Internet.

Proxy Firewalls

Proxy firewalls are not really Internet routers. They are essentially hosts running one or more application-layer gateways (ALGs), hosts with more than one network interface that relay traffic of certain types between one connection/association and another at the application layer.

The figure below illustrates a proxy firewall:

The proxy firewall acts as a multihomed Internet host, terminating TCP connections and UDP associations at the application layer. It does not act as a conventional IP router but rather as an ALG. Individual applications or proxies for each service supported must be enabled for communication to take place through the proxy firewall.

This type of firewall can be quite secure at the cost of brittleness and lack of flexibility:

The two most common forms of proxy firewalls are HTTP proxy firewalls and SOCKS firewalls.

Network Address Translation (NAT)

NAT is a mechanism that allows the same sets of IP addresses to be reused in different parts of the Internet. With NAT as a common use, all incoming and outgoing traffic passes through a single NAT device that partitions the inside (private) address realm from the global Internet address realm, all the internal systems can be provided Internet connectivity as clients using locally assigned, private IP addresses. [p303]

NAT was introduced to solve two problems: address depletion and concerns regarding the scalability of routing. NAT was initially suggested as a stopgap, temporary measure to be used until the deployment of some protocol with a larger number of addresses (IPv6) became widespread. Routing scalability was being tackled with the development of Classless Inter-Domain Routing (CIDR, Chapter 2)

NAT is popular because:

  1. It reduces the need for globally routable Internet addresses
  2. It offers some degree of natural firewall capability and requires little configuration.

Perhaps ironically, the development and eventual widespread use of NAT has contributed to significantly slow the adoption of IPv6. Among its other benefits, IPv6 was intended to make NAT unnecessary.

NAT has several drawbacks:

Despite its shortcomings, NATs are very widely used, and most network routers support it; NAT supports the basic protocols (e.g., e-mail, Web browsing) that are needed by millions of client systems accessing the Internet every day.

A NAT works by rewriting the identifying information in packets transiting through a router. Most commonly NAT involves rewriting the source IP address of packets as they are forwarded in one direction and the destination IP addresses of packets traveling in the reverse direction. This allows the source IP address in outgoing packets to become one of the NAT router’s Internet-facing interfaces instead of the originating host’s. Thus, to a host on the Internet, packets coming from any of the hosts on the privately addressed side of the NAT appear to be coming from a globally routable IP address of the NAT router.

Most NATs perform both translation and packet filtering, and the packet-filtering criteria depend on the dynamics of the NAT state. The choice of packet-filtering policy may have a different granularity. For example, the treatment of unsolicited packets (those not associated with packets originating from behind the NAT) received by the NAT may depend on source and destination IP address and/or source and destination port number. [p305]

Traditional NAT: Basic NAT and NAPT

Traditional NAT includes both:

See the following figure for the distinction between basic NAT and NAPT:

A basic IPv4 NAT (left) rewrites IP addresses from a pool of addresses and leaves port numbers unchanged. NAPT (right), also known as IP masquerading, usually rewrites address to a single address. NAPT must sometimes rewrite port numbers in order to avoid collisions. In this case, the second instance of port number 23479 was rewritten to use port number 3000 so that returning traffic for 192.168.1.2 could be distinguished from the traffic returning to 192.168.1.35.

The addresses used in a private addressing realm "behind" (or "inside") a NAT are not enforced by anyone other than the local network administrator. It is possible and acceptable for a private realm to make use of global address space. However, local systems in the private realm would most likely be unable to reach the public systems using the same addresses because the close proximity of the local systems would effectively "mask" the visibility of the farther-away systems using the same addresses. To avoid this, three IPv4 address ranges are reserved for use with private addressing realms: 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16, which are often used as default values for address pools in embedded DHCP servers

NAT provides some degree of security, similar to a firewall [p306]:

The following subsections discusses how NAT behaves with each major transport protocol and how it may be used in mixed IPv4/IPv6 environments. [p306]

NAT and TCP

When a TCP connection starts, an "active opener" or client usually sends a synchronization (SYN) packet to a "passive opener" or server. The server responds with its own SYN packet, which also includes an acknowledgment (ACK) of the client’s SYN. The client then responds with an ACK to the server. This “three-way handshake” establishes the connection. A similar exchange with finish (FIN) packets is used to gracefully close a connection. The connection can also be forcefully closed right away using a reset (RST) packet. The behavioral requirements for traditional NAT with TCP relate primarily to the TCP three-way handshake.

Referring to the figure below, consider a TCP connection initiated by the wireless client at 10.0.0.126 destined for the Web server on the host www.isoc.org (IPv4 address 212.110.167.157). With the format "(source IP:source port; destination IP:destination port)", the packet initiating the connection on the private segment might be addressed as (10.0.0.126:9200; 212.110.167.157:80).

A NAT isolates private addresses and the systems using them from the Internet. Packets with private addresses are not routed by the Internet directly but instead must be translated as they enter and leave the private network through the NAT router. Internet hosts see traffic as coming from a public IP address of the NAT.

[p307]

Session state is removed if FINs are exchanged. The NAT must also remove "dead" mappings (identified by lack of traffic or RST) that are left stale in the NAT's memory, such when a client host is simply turned off.

Most NATs include a simplified TCP connection establishment procedures and can distinguish between connection success and failure:

A TCP connection can be configured to send "keepalive" packets (Chapter 17), and the default rate is one packet every 2 hours, if enabled. Otherwise, a TCP connection can remain established indefinitely. While a connection is being set up or cleared, however, the maximum idle time is 4 minutes. Consequently, [RFC5382] requires (REQ-5) that a NAT wait at least 2 hours and 4 minutes before concluding that an established connection is dead and at least 4 minutes before concluding that a partially opened or closed connection is dead.

There are tricky problems for TCP NAT. [p308] See Doubts and Solutions

NAT and UDP

Besides issues when performing NAT on TCP, the NAT on UDP has other issues due to:

To handle these issues, UDP NATs use a mapping timer to clear NAT state if a binding has not been used "recently". The "recently" may mean different values. [RFC4787] requires the timer to be at least 2 minutes and recommends that it be 5 minutes. Timers can be refreshed when packets travel from the inside to the outside of the NAT (NAT outbound refresh behavior). [p309]

With IP fragmentation, an IP fragment other than the first one does not contain the port number information needed by NAPT to operate properly. This also applies to TCP and ICMP. Thus, fragments cannot be handled properly by simple NATs or NAPTs. [p309]

NAT and Other Transport Protocols (DCCP, SCTP)
NAT and ICMP

The Internet Control Message Protocol (ICMP) provides status information about IP packets and can also be used for making certain measurements and gathering information about the state of the network.

ICMP has two categories of messages: informational and error: [p310]

NAT and Tunneled Packets

When tunneled packets (Chapter 3) are to be sent through a NATs, not only must a NAT rewrite the IP header, but it may also have to rewrite the headers or payloads of other packets that are encapsulated in them. One example of this is the Generic Routing Encapsulation (GRE) header used with the Point-to-Point Tunneling Protocol (PPTP). [p310]

NAT and Multicast

NATs can be configured to support multicast traffic (Chapter 9), although this is rare. [p310]

NAT and IPv6

There is staunch resistance to supporting the use of NAT with IPv6 based on the idea that saving address space is unnecessary with IPv6 and that other desirable NAT features (firewall-like functionality, topology hiding, and privacy) can be better achieved using Local Network Protection (LNP) [RFC4864]. LNP represents a collection of techniques with IPv6 that match or exceed the properties of NATs.

Aside from its packet-filtering properties, NAT supports the coexistence of multiple address realms and thereby helps to avoid the problem of a site having to change its IP addresses when it switches ISPs. [p310-311]

Address and Port Translation Behavior

One of the primary goals of the BEHAVE working group in IETF was to clarify the common behaviors and set guidelines. [p311]

See the following figure as a generic NAT mapping example:

A NAT’s address and port behavior is characterized by what its mappings depend on. The inside host uses IP address:port X:x to contact Y1:y1 and then Y2:y2. The address and port used by the NAT for these associations are X1′:x1′ and X2′:x2′, respectively. If X1′:x1′ equals X2′:x2′ for any Y1:y1 or Y2:y2, the NAT has endpoint-independent mappings. If X1′:x1′ equals X2′:x2′ if and only if Y1 equals Y2, the NAT has address-dependent mappings. If X1′:x1′ equals X2′:x2′ if and only if Y1:y1 equals Y2:y2, the NAT has addressand port-dependent mappings. A NAT with multiple external addresses (i.e., where X1′ may not equal X2′) has an address pooling behavior of arbitrary if the outside address is chosen without regard to inside or outside address. Alternatively, it may have a pooling behavior of paired, in which case the same X1 is used for any association with Y1.

In this figure:

A NAT’s address and port behavior is characterized by what its mappings depend on. The inside host uses IP address:port X:x to contact Y1:y1 and then Y2:y2. The address and port used by the NAT for these associations are X1′:x1′ and X2′:x2′, respectively.

A NAT with multiple external addresses (i.e., where X1′ may not equal X2′) has an address pooling behavior of arbitrary if the outside address is chosen without regard to inside or outside address. Alternatively, it may have a pooling behavior of paired, in which case the same X1 is used for any association with Y1.

The figure above and the table below summarize the various NAT port and address behaviors based on definitions from [RFC4787]. The table also gives filtering behaviors that use similar terminology.

For all common transports, including TCP and UDP, the required NAT address- and port-handling behavior is endpoint-independent. The purpose of this requirement is to help applications that attempt to determine the external addresses used for their traffic to work more reliably. This is detailed in NAT traversal.

Behavior Name Translation Behavior Filtering Behavior
Endpoint-independent X1′:x1′ = X2′:x2′ for all Y2:y2 (required) Allows any packets for X1:x1 as long as any X1′:x1′ exists (recommended for greatest transparency)
Address-dependent X1′:x1′ = X2′:x2′ iff Y1 = Y2 Allows packets for X1:x1 from Y1:y1 as long as X1 has previously contacted Y1 (recommended for more stringent filtering)
Address-and port-dependent X1′:x1′ = X2′:x2′ iff Y1:y1 = Y2:y2 Allows packets for X1:x1 from Y1:y1 as long as X1 has previously contacted Y1:y1
NAT address pool *

A NAT may have several external addresses available to use. The set of addresses is typically called the NAT pool or NAT address pool. Note that NAT address pools are distinct from the DHCP address pools discussed in Chapter 6, although a single device may need to handle both NAT and DHCP address pools.

Address pairing or not? *

When a single host behind the NAT opens multiple simultaneous connections, is each assigned the same external IP address (called address pairing) or not?

A NAT’s IP address pooling behavior is said to be arbitrary if there is no restriction on which external address is used for any association. It is said to be paired if it implements address pairing. Pairing is the recommended NAT behavior for all transports. If pairing is not used, the communication peer of an internal host may erroneously conclude that it is communicating with different hosts. For NATs with only a single external address, this is obviously not a problem.

Port overloading *

Port overloading is a type of NAT that overloads not only addresses but also ports, where the traffic of multiple internal hosts may be rewritten to the same external IP address and port number. This is a dangerous because if multiple hosts associate with a service on the same external host, it cannot determine the appropriate destination for traffic returning from the external host. For TCP, this is a consequence of all four elements of the connection identifier (source and destination address and port numbers) being identical in the external network among the various connections. Such behavior is now disallowed.

Port parity *

Some NATs implement a special feature called port parity. Such NATs attempt to preserve the "parity" (evenness or oddness) of port numbers. Thus, if x1 is even, x1′ is even and vice versa. Although not as strong as port preservation, such behavior is sometimes useful for specific application protocols that use special port numberings (e.g., the Real-Time Protocol, abbreviated RTP, has traditionally used multiple ports, but there are proposed methods for avoiding this issue).

Port parity preservation is a recommended NAT feature but not a requirement. It is also expected to become less important over time as more sophisticated NAT traversal methods become widespread.

Filtering Behavior

When a NAT creates a binding for a TCP connection, UDP association, or ICMP traffic, not only does it establish the address and port mappings, but it must also determine its filtering behavior for the returning traffic if it acts as a firewall, which is the common case. The type of filtering a NAT performs, though logically distinct from its address- and port-handling behavior, is often related and the same terminology is used.

A NAT’s filtering behavior is usually related to whether it has established an address mapping. A NAT lacking any form of address mapping is unable to forward any traffic it receives from the outside to the inside because it would not know which internal destination to use. For the most common case of outgoing traffic, when a binding is established, filtering is disabled for relevant return traffic:

The difference between the last two is that the last form takes the port number y1 into account.

Servers behind NATs

A system that wishes to provide a service from behind a NAT is not directly reachable from the outside. In Figure 7-3, if the host with address 10.0.0.3 is to provide a service to the Internet, it cannot be reached without participation from the NAT, for at least two reasons:

  1. The NAT is acting as the Internet router, so it must agree to forward the incoming traffic destined for 10.0.0.3.
  2. The IP address 10.0.0.3 is not routable through the Internet and cannot be used to identify the server by hosts in the Internet. Instead, the external address of the NAT must be used to find the server, and the NAT must arrange to properly rewrite and forward the appropriate traffic to the server so that it can operate. This process is most often called port forwarding or port mapping.
Port forwarding *

With port forwarding, incoming traffic to a NAT is forwarded to a specific configured destination behind the NAT. This allows servers to provide services to the Internet even though they may be assigned private, nonroutable addresses.

Port forwarding typically requires static configuration of the NAT with the address of the server and the associated port number whose traffic should be forwarded. The port forwarding directive acts like an always-present static NAT mapping. If the server’s IP address is changed, the NAT must be updated with the new addressing information.

Port forwarding also has the limitation that it has only one set of port numbers for each of its (IP address, transport protocol) combinations. Thus, if the NAT has only a single external IP address, it can forward only a single port of the same transport protocol to at most one internal machine (e.g., it could not support two independent Web servers on the inside being remotely accessible using TCP port 80 from the outside).

Hairpinning and NAT Loopback

An interesting issue arises when a client wishes to reach a server and both reside on the same, private side of the same NAT. NATs that support this scenario implement so-called hairpinning or NAT loopback.

A NAT that implements hairpinning or NAT loopback allows a client to reach a server on the same side of the NAT using the server’s external IP address and port numbers. That is, X1 can reach X2:x2 using the addressing information X2′:x2′

Referring to the figure above, assume that host X1 attempts to establish a connection to host X2. If X1 knows the private addressing information, X2:x2, there is no problem because the connection can be made directly. However, in some cases X1 knows only the public address information, X2′:x2′. In these cases, X1 attempts to contact X2 using the NAT with destination X2′:x2′. The hairpinning process takes place when the NAT notices the existence of the mapping between X2′:x2′ and X2:x2 and forwards the packet to X2:x2 residing on the private side of the NAT. At this point a question arises as to which source address is contained in the packet heading to X2:x2: X1:x1 or X1′:x1′?

If the NAT presents the hairpinned packet to X2 with source addressing information X1′:x1′, the NAT is said to have "external source IP address and port" hairpinning behavior. This behavior is required for TCP NAT [RFC5382]. The justification for requiring this behavior is for applications that identify their peers using globally routable addresses. In our example, X2 may be expecting an incoming connection from X1′ (e.g., because of coordination from a third-party system).

NAT Editors

Service Provider NAT (SPNAT) and Service Provider IPv6 Transition

NAT Traversal

Doubts and Solutions

Verbatim

p308 on TCP NAT:

One of the tricky problems for a TCP NAT is handling peer-to-peer applications operating on hosts residing on the private sides of multiple NATs [RFC5128]. Some of these applications use a simultaneous open whereby each end of the connection acts as a client and sends SYN packets more or less simultaneously. TCP is able to handle this case by responding with SYN + ACK packets that complete the connection faster than with the three-way handshake, but many existing NATs do not handle it properly. [RFC5382] addresses this by requiring (REQ-2) that a NAT handle all valid TCP packet exchanges, and simultaneous opens in particular. Some peer-to-peer applications (e.g., network games) use this behavior. In addition, [RFC5382] specifies that an inbound SYN for a connection about which the NAT knows nothing should be silently discarded. This can occur when a simultaneous open is attempted but the external host’s SYN arrives at the NAT before the internal host’s SYN. Although this may seem unlikely, it can happen as a result of clock skew, for example. If the incoming external SYN is dropped, the internal SYN has time to establish a NAT mapping for the same connection represented by the external SYN. If no internal SYN is forthcoming in 6s, the NAT may signal an error to the external host.

Some other NAT drawbacks: