Network address translation and port address translation (NAT/PAT) originally were solutions for the depletion of the IPv4 addresses, and now are used by growing corporations to securely expand their Internet access. The basic NAT/PAT functionality multiplexes traffic from many users on an internal network and presents it to the Internet as if it was coming from a smaller range of assigned IP addresses.
Analogous to the firewall access control list (ACL), NAT/PAT implementations track TCP/IP or UDP/IP clients on a per-connection basis and remove them from the translation table as soon as the connection is closed. This becomes very difficult when the TCP port and IP address information to be translated is embedded inside the application payload. Furthermore, translating all packets related to dynamic protocols poses the same technology hurdles that firewall designers have traditionally faced. As with the firewall, the application must be identified, so that all flows associated with the application can be coherently translated.
Since most firewalls extend their access control functionality to include NAT/PAT, the solutions involve the same three technologies: packet filtering, application-level gateway, and secure flow processing (SFP) technologies.
In an article last month (to view the article, click here), we explored how stateful flow classifiers, called secure flow processors (SFPs), enhance security and performance, while lowering cost of firewall equipment versus packet filtering solutions. Now we'll extend this analysis to NAT/PAT. Specifically, we'll illustrate that when adding NAT functionality to firewalls, SFP enhances the capability of NAT routers, while increasing performance and lowering cost.
Quick Review
As a review, stateless packet classifiers only inspect one packet at a time, they can only identify well-known connections and cannot identify all the (dynamically negotiated) ephemeral connections that emerge as the network application evolves, nor preserve the relationship between protocols of an application.
Conversely, stateful flow classifiers (also called SFPs) maintain the state of the packets of a connection in order to identify all packets in all connections that are related to an application. The relationships are tracked as one TCP connection dynamically negotiates another TCP connection at a different ephemeral TCP port.
Accelerating NAT Functions
SFP accelerates NAT/PAT by recognizing the application, identifying critical packets that contain the relevant address and port information associated with each application, and locating where inside the application's payload are the relevant IP address and TCP/UDP port information (Figure 1). This makes it possible to track connectionless UDP traffic, as well as tracking all dynamic ('ephemeral') connections that are associated with an application.
Click here for larger image of Figure 1
Figure 1: NAT/PAT visibility into application payload using SFP.
It is relatively simple for a packet filter to recognize "PORT" in ASCII for every packet destined to port 21, or "CONNECT" in ASN.1 for every packet destined to port 1720, and translate the embedded IP addresses and TCP ports. As discussed in the previous article, in H.323, the address and port information to be translated for all the ephemeral real-time protocol (RTP) and real-time control protocol (RTCP) streams are embedded in the H.245 payloads, which themselves comprise an ephemeral connection. Packet filters cannot relate all the ephemeral RTP/RTCP streams to the ephemeral H.245 connection, so in that case an application gateway must be used.
Complex protocols may prevent the packet-filtering NAT from performing address translation in the data plane. Similar to the access control case, the NAT/PAT may proxy the application in an application-layer gateway. The application-level gateway terminates the application from the outside, untrusted network in one address domain and regenerates the application to the internal protected network in another address domain. This form of NAT/PAT will translate all packets associated with an application, but is the most expensive in performance and unit cost.
Alternatively, SFP combines the protocol-aware intelligence of application-level gateways and speed of packet filters. Today's stateful, complex media-rich protocols require the NAT/PAT to either proxy the application or perform SFP. SFP enables the NAT/PAT to translate the address and port of every packet in every application without the need to use an application gateway.
The Real-World: NAT and SFP Edition
The following example illustrates a NAT/PAT translating the addresses and ports of two workstations as they both perform active-mode FTP. This rather simple example illustrates the issues that require packet filter NAT/PAT to proxy more complex applications. For example, the H.323 protocol does not feature a passive mode to circumvent searching for embedded application payloads that contain address and port information for inbound connections.
Figure 2 illustrates a small office LAN with two workstations sharing a single global IP address assigned by the Internet service provider (ISP). In this case, without use of NAT/PAT, both workstations cannot access the Internet at the same time since there is only one global IP address. The NAT/PAT device used in this example multiplexes the internal TCP and UDP port numbers and uses the single external IP address.
Click here for larger image of Figure 2
Figure 2: Small office router delivering NAT/PAT functionality.
As each workstation creates a new FTP connection, the NAT/PAT must dynamically maintain a list of IP address and TCP (or UDP) port mappings of internal systems to external connections, so that the NAT/PAT knows where to forward inbound response packets.
Figure 3 illustrates how the NAT/PAT device might map the two internal workstations to a single external IP address when they are both performing FTP downloads. The left-hand side of Figure 3 shows the four-tuple that each workstation's FTP client forms, and the right-hand side shows how NAT/PAT translates the internal source IP addresses and source TCP ports to appear on the external Internet.
Click here for larger image of Figure 3
Figure 3: NAT/PAT translation table.
In order to facilitate the data download, the FTP client establishes a control connection to the FTP server. Workstation #1's FTP client picks a TCP source port of 12001, and sends a TCP SYN packet to the FTP server at TCP port 21 (the well-known port number for FTP control channel).
The NAT/PAT translates workstation #1's source port number 12001 in the TCP header to 14001, as it translates workstation #1's internal IP address to the single shared external IP address 64.33.104.180. When the FTP server responds to workstation #1 it replies to destination IP address 64.33.104.180, port 14001, and the NAT/PAT translates this back to 192.168.2.1, port 12001 and forwards the packet to the workstation #1.
Next, workstation #1 sends the PORT command to the FTP server requesting that the server initiate an FTP data connection to the client's IP address 192.168.2.1 and port 12001 (FTP Port command). NAT/PAT implementations, which have little or no application level visibility, forwards this packet to the server with only addresses and ports in IP and TCP headers translated.
The FTP protocol specifies that the client's control request contains its source IP address and port number embedded in the FTP control packet PORT command payload, formatted in ASCII. If the NAT/PAT does not perform this additional translation inside the FTP control payload, then the FTP server will not send the data to IP address 64.33.104.180, port 14000, rather it will send the packet to 192.168.2.1, port 12000, which is what workstation #1's FTP client specified in the control request it sent to the FTP server. Since the FTP client's IP address is non-routable, the FTP will fail.
The NAT/PAT makes an entry in the translation table (the first row of Figure 3) when translating the FTP PORT command packet, so the NAT/PAT knows how to translate the packets of the file received from the FTP server. That is, the ephemeral port used for the FTP data connection must be associated with the FTP control connection to ensure successful FTP operation through the NAT/PAT.
The problem illustrated in this simple example is magnified with H.323. In this case, the Q.931 connection dynamically negotiates the H.245 connection with TCP port numbers embedded in the Q.931 application payloads. Then the H.245 connection dynamically negotiates eight or more RTP/RTCP streams with UDP port numbers embedded in the H.245 application payloads. Critical packets must be identified on the fly, critical payloads located within, and protocols statefully tracked by the NAT/PAT for coherent translation to each workstation. This complication relegates the packet filter NAT/PAT to use an application gateway to proxy the H.323 application.
The SFP Advantage
SFP provides several advantages over today's packet filter and application gateway solutions. The following secure flow processor benefits allow moving NAT/PAT functionality into the data plane to enable multi-gigabit NAT/PAT performance.
- SFP provides visibility to address and port information contained in payload.
- SFP reduces or eliminates application gateway proxy computing needs (and cost).
- SFP allows volume traffic to be processed in the data plane at line speed.
- SFP eliminates policy look-up latency for bulk of flow traffic.
- SFP eliminates packet decode for processing.
As Figure 1 above points out, high-speed packet filtering implementations lack the ability that SFPs have to recognize complex applications, identify the critical packets, locate the IP address and TCP/UDP ports embedded in the payloads, and read ASCII or ASN.1. SFPs identify the ephemeral address and port information embedded in critical packets to accelerate NAT/PAT transformations for all applications.
Application level gateways could proxy this simple FTP example application by connecting as the server to the workstation in the 192.168.2.x address domain, and connecting as the client to the FTP server using the 64.33.104.180 assigned IP address. Proxying requires separate control processors that degrade performance and add cost and power to a NAT/PAT system. In addition to performing the application proxy function and two passes through the TCP/IP (or UDP/IP) stack, packets must be passed over the slower control bus (e.g. PCI) rather than keeping all packets on the high-speed data bus (e.g. POS PHY Level 3).
A better solution involves SFP, which moves the application-level gateway functionality and processing requirements into the data plane allowing all traffic to be transformed at multi-gigabit line speed, as illustrated in Figure 4. Incorporating SFP technology into a firewall's access control and NAT/PAT functions enables the firewall to process all packets from all applications in the data plane and in one touch of the packet.
Click here for larger image of Figure 4
Figure 4: Firewall with NAT/PAT block diagram.
Another significant SFP performance advantage is that the NAT/PAT policy engine may not have to perform a policy rule look-up on every packet. Since the SFP can associate every packet with a flow, and hence a policy, it can provide the NAT/PAT translation engine with a pointer into the NAT/PAT translation table for every packet. That is, once the NAT/PAT engine determines the translation policy for the first packet of a flow, the NAT/PAT engine can program the secure flow processor to output this pointer for all future packets associated with this flow. This capability lowers the latency for NAT/PAT processing.
SFP also identifies and points to all IP and TCP/UDP headers in the packet to be transformed. This accelerates the NAT/PAT in computing the IP header checksums and TCP or UDP payload checksums.
Why SFP Wins
SFP combines the high performance and low cost of packet filters and the high security of application level gateways, as illustrated in Table 1.
Table 1
|
Security |
Performance |
Cost |
| Packet Filtering |
LOW |
HIGH |
LOW |
| Application-Level Gateway |
HIGH |
LOW |
HIGH |
| Secure Flow Processing |
HIGH |
HIGH |
LOW |
SFP can be used to identify all of today's complex, media-rich, hierarchical applications, locate dynamic packet content, and provide relational and stateful information to security policy engines at multi-gigabit line speed. In order to implement a robust, efficient security packet processing solution, it is no longer sufficient to inspect packet headers, one packet at a time. Nor is it efficient or cost-effective to proxy an application in a gateway.
Finally, SFP's all-in-one result per packet allows security equipment to extend SFP's protocol analysis to all security functions (firewall, NAT/PAT, VPN, IDS, DoS, virus detection, etc.) in one pass. SFP's protocol recognition allows extensibility to tomorrow's protocols thus providing the best flexibility, along with performance, for the price.
About the Author
Robert Friend is a senior staff technologist at Hifn. He is an active member of the IETF, co-authoring the RFC1967, RFC1974, and RFC2395 specifications. Robert received a BSEE from UCLA and can be reached at rfriend@hifn.com.
