• 沒有找到結果。

Inbound session problem in NAT environments

2.1.1 NAT

Network Address Translation (NAT) [1] is a technique that can translate one IP address to another while providing transparent routing to hosts. It is widely deployed by many Internet services providers (ISP) to solve the IP address depletion problem of IPv4. In an NAT1 network that uses private IP addresses, there will be an NAT router with two networks interface, an internal interface to the NAT network and an external interface to the public network. The internal interface of the NAT router and hosts in the NAT network (henceforth referred to as internal host) use Internet- non-routable private IP addresses to communicate with each other. On the other hand, internal hosts communicate with hosts external to the NAT network (henceforth referred to as external host) via the external interface of the NAT router, which uses public IP address(s). When packets pass through the NAT router, the NAT router transparently translates an Internet-non-routable private IP addresses used by internal hosts to an Internet-routable public IP address of the external interface. Therefore, a private IP address can be reused by another NAT network and the IP address depletion problem can be solved.

In the following, we first explain two types of traditional NAT: Basic NAT and NAPT (Network Address and Port Translation).

Basic NAT : With Basic NAT, the NAT router reserves a pool of public IP addresses for address translation. When an internal host originates a session to an external host, the NAT router selects an address from the reserved IP addresses and creates an address binding between the private address of the internal host and the selected public address.

Afterward, packets of the session can be translated and routed according to the created

1 Although NAT is restricted to translation between a private address realm and a public address realm, in this thesis we focus only on using NAT to translate between a private address realm and a public address realm.

Therefore, we will use NAT network, private network, and NAT private network in interchange throughout this

address binding. For packets outbound from the NAT network, the NAT router changes the source IP addresses from private addresses to public ones; for inbound packets, the NAT router replaces their destination IP address in reverse from public addresses to private ones.

NAPT: NAPT extends the translation further by also translating the transport identifier, e.g., TCP and UDP port numbers, or ICMP query identifiers. With this extension, transport identifiers of a number of private hosts are multiplexed into transport identifiers of a single public address. Thus NAPT allows multiple hosts to share a single public address for saving public addresses. Therefore most current NAT routers adopt NAPT for address translation.

Figure 2-1. NAPT operation

There are many variations of NAT that lend themselves to different applications. IETF has defined terminology, consideration, and variations of NAT in RFC 2663 [4] and RFC3489 [5].

In reality, each vendor may implement NAT in its own way. For example, Iptables [6], an implementation of NAPT in Linux operating system, classifies binding entries into two categories: Source NAT (SNAT) and Destination NAT (DNAT). In Iptables, an NAT router

checks SNAT entries for each outbound IP packet and DNAT entries for each inbound IP packet. Figure 2-1 illustrates the NAPT operations performed by an NAT router for SNAT translation. A host (PN) in a private network with private IP (192.168.0.3) is communicating with another host (CN) in the Internet. PN sends outbound packets with IP:port as 192.168.0.3:1234 which are routed to the NAT Router. The NAT Router then finds that the source IP:port of the received packet matches an SNAT entry in the NAT table, and therefore translates the packet’s source IP: port into 140.113.1.1:2345 according to the matched entry.

After the translation, the translated IP packets are routed to the Internet according to the routing table of the NAT router. Afterward, when the CN receives translated packets, it can reply PN by simply using the source IP:port of the received translated packets as the destination IP:port of the replied packets. Upon receiving inbound packets from CN, the NAT router knows, by examining DNAT entries, how to replace the destination IP:port with an internal IP:port for the packets. Consequently, PN receives the translated inbound packets destined for PN’s internal private IP from the specified port on which PN is expecting to receive the inbound packets.

Besides, RFC3489 [5] further classifies NAT as full cone, restricted cone, port-restricted cone, and symmetric ones. In full cone NAT, all packets from the same internal IP address and port are mapped to the same external IP address and port. Furthermore, any external host can then send a packet to the internal host, by sending a packet to the mapped external address and/or port. In restricted cone NAT, all packets from the same internal IP address and port are mapped to the same external IP address and port. Unlike a full cone NAT, an external host (with IP address X) can send then a packet to the internal host only if the internal host had previously sent a packet to IP address X. As for port restricted cone NAT, it is like a restricted cone NAT, but the restriction includes port numbers. Specifically, an external host can send a packet, with source IP address X and source port P, to the internal host only if the internal host had previously sent a packet to IP address X and port P. In symmetric NAT, all requests from the same internal IP address and port, to a specific destination IP address and a specific port, are mapped to the same external IP address and port. If the same internal host

sends a packet with the same source address and port, but to a different destination, a different mapping is used. Furthermore, only the external host that receives a packet from a specific port on a specific internal host can then send a packet back to the specific port on the specific internal host.

2.1.2 Inbound session problem

Figure 2-2. Inbound session problem

However, an external host cannot originate a session to an internal host behind an NAT router unless the NAT router has established NAT binding entry(s) for the internal host. Figure 2-2 illustrates the inbound session problem. Assume that there is no binding entry for port 80 (used by HTTP service) on the NAT router’s external IP address and an Internet host (CN) wishes to initiate an HTTP session with PN1, a host in the NAT network. CN should first issue a DNS [7-8] request to learn PN1’s IP address. The DNS request is then replied by a DNS server with the external IP address of PN1’s NAT router. Afterward, CN sends a connection request to port 80 on the NAT router’s external IP address. However, when the

NAT router receives the connection request packet, it would find no match in the NAT table and it won’t know which host in the private network is the desired destination host.

2.1.3 Information pushing service

Among current mobile Internet connectivity techniques, GPRS and 802.11 family wireless networks are most popularly adopted. GPRS and 802.11 family are superior to traditional dial- up Internet access in providing inexpensive and fast continuous Internet connectivity. With continuous Internet connectivity, mobile devices are kept online so that the mobile devices can be reached by other nodes even the mobile devices have no ongoing connections with any other nodes. Therefore, contents about real-time information, e.g. stock information and surveillance alerts, can be pushed to subscribers without subscribers’ probing.

Delivering information by pushing is better than traditional ways, e.g., email or SMS, since subscribers will not need to probe for non-periodically produced information. However, it is difficult to push information to mobile users in GPRS networks and 802.11 family wireless networks since many of these networks provide private IP addresses to mobile users and utilize NAT to connect to the Internet.

2.1.4 Our approach -- DCNAT

Many researchers have proposed approaches to resolve the inbound session problem.

However, these approaches suffer from wasting IP addresses, being unable to support dynamically open ports by PN, being unable to support lots of PNs, or lack of inflexibility.

Therefore, we propose a dynamically configurable NAT (DCNAT) approach to solve the inbound session problem as well as the problem of information pushing to NAT networks.

The proposed DCNAT approach uses an add-on NAT Agent on an NAT router and a Binding Entry Request procedure so that an Internet host or its agent can request the NAT router to create dynamic NAT binding entries. After creation of binding entries, packets sent from the Internet host can pass through the NAT router and reach their desired destination host.

DCNAT can support general inbound sessions as well as information pushing to a private

network. Compared with previous proposals, DCNAT is more scalable and flexible because it can support inbound accesses to lots private hosts and ports/services opened dynamically by private hosts by using just a single or few IP addresses.