The concept of Network Address Translation (NAT) goes back to the origin of the feared IP address shortage. An IP address shortage was a distinct possibility because, historically, huge address blocks were assigned, which were underutilized or were assigned inefficiently, in the early days before the classless interdomain routing (CIDR) and variable-length subnet masking (VLSM) of today's Internet. Today's address-assignment policies are much stricter, and registration authorities now try to free underutilized address aggregates by demanding them back for reassignment. Historically, most addresses were assigned to North America and Europe. NAT improves aggregation and scalability of enterprise routing, too, so it contributes to keeping the global Internet routing table "relatively" small.
From a "workaround" for address exhaustion, NAT has evolved into a flexible vehicle for enterprises and Internet service providers (ISPs). Although NAT per se is not a security vehicle, it arguably improves privacy. An attacker usually does not know which and how many addresses remain hidden (masqueraded) behind corporate NAT gateways. One can attack only the outside addresses of these gateways or the address pools deployed for NAT.
This chapter discusses UNIX NAT approaches, frequently used terminology, and caveats in context with NAT-incapable protocols. The chapter concludes by looking at future developments with regard to IPv4 NAT.
The NAT Foundation—Basic/Traditional NAT
NAT enables hosts with RFC 1918 addresses to access officially routed Internet IPv4 addresses, but it also can be deployed for migration scenarios with overlapping address space. RFC 3022 exhaustively describes the evolution of NAT variants and is highly recommended reading. In the most general case (basic NAT), inside RFC 1918 private address pools are mapped to outside address pools that are transparent to end users. The original approach featured a 1:1 mapping from internal to external addresses, which by itself did not provide address preservation. The introduction of Network Address Port Translation (NAPT or PAT) changed this picture in a way—that is, via TCP/UDP ports, many internal addresses can be mapped into one outside address. This is also referred to as port multiplexing.
NAT gateways store information that is relevant for mapping/reverse mapping in state tables. NAT/PAT mappings come in several flavors:
-
One-to-one or bidirectional mapping (1:1) (static mappings)
-
One-to-many (1:n) (single gateway address = NAPT/PAT/masquerading or dynamic NAT)
NAT, PAT(NAPT), Masquerading, and Port Mapping/Multiplexing
In the Linux world, the term IP masquerading often is used for historical reasons. In pre-iptables times, the masquerading engine was separate from the packet filter and stateful inspection engine. In a way, IP masquerading is a point of view that emphasizes the stealthy character of the procedure. In contrast, PAT describes the mechanism more accurately.
NAT gateways (NAT translators in Internet Engineering Task Force [IETF] parlance) internally operate as TCP/UDP port multiplexing/demultiplexing engines. This procedure also is referred to as mapping and reverse mapping. NAPT is IETF parlance for PAT.
You occasionally will find that Cisco differentiates between NAT and PAT. From the Cisco perspective, this is a differentiation of one-to-one and many-to-one/many-to-many mappings.
0 comments:
Post a Comment