📄 rfc2993.txt
字号:
When packet header integrity is not an issue, this type of virtual
host requires no modifications to the remote applications since the
end client is unaware of the mapping activity. While the virtual
host has the CPU performance characteristics of the total set of
machines, the processing and I/O capabilities of the NAT/ALG device
bound the overall performance as it funnels the packets back and
forth.
6. Problems with NATs
- NATs break the flexible end-to-end model of the Internet.
- NATs create a single point where fates are shared, in the device
maintaining connection state and dynamic mapping information.
- NATs complicate the use of multi-homing by a site in order to
increase the reliability of their Internet connectivity. (While
single routers are a point of fate sharing, the lack of state in a
router makes creating redundancy trivial. Indeed, this is on of
the reasons why the Internet protocol suite developed using a
connectionless datagram service as its network layer.)
- NATs inhibit implementation of security at the IP level.
- NATs enable casual use of private addresses. These uncoordinated
addresses are subject to collisions when companies using these
addresses merge or want to directly interconnect using VPNs.
- NATs facilitate concatenating existing private name spaces with
the public DNS.
Hain Informational [Page 10]
RFC 2993 Architectural Implications of NAT November 2000
- Port versions (NAPT and RSIP) increase operational complexity when
publicly published services reside on the private side.
- NATs complicated or may even invalidate the authentication
mechanism of SNMPv3.
- Products may embed a NAT function without identifying it as such.
By design, NATs impose limitations on flexibility. As such, extended
thought about the introduced complications is called for. This is
especially true for products where the NAT function is a hidden
service, such as load balancing routers that re-write the IP address
to other public addresses. Since the addresses may be all in
publicly administered space these are rarely recognized as NATs, but
they break the integrity of the end-to-end model just the same.
NATs place constraints on the deployment of applications that carry
IP addresses (or address derivatives) in the data stream, and they
operate on the assumption that each session is independent. However,
there are applications such as FTP and H.323 that use one or more
control sessions to set the characteristics of the follow-on sessions
in their control session payload. Other examples include SNMP MIBs
for configuration, and COPS policy messages. Applications or
protocols like these assume end-to-end integrity of addresses and
will fail when traversing a NAT. (TCP was specifically designed to
take advantage of, and reuse, the IP address in combination with its
ports for use as a transport address.) To fix how NATs break such
applications, an Application Level Gateway needs to exist within or
alongside each NAT. An additional gateway service is necessary for
each application that may imbed an address in the data stream. The
NAT may also need to assemble fragmented datagrams to enable
translation of the application stream, and then adjust TCP sequence
numbers, prior to forwarding.
As noted earlier, NATs break the basic tenet of the Internet that the
endpoints are in control of the communication. The original design
put state control in the endpoints so there would be no other
inherent points of failure. Moving the state from the endpoints to
specific nodes in the network reduces flexibility, while it increases
the impact of a single point failure. See further discussion in
Illustration 1 below.
In addition, NATs are not transparent to all applications, and
managing simultaneous updates to a large array of ALGs may exceed the
cost of acquiring additional globally routable addresses. See
further discussion in Illustration 2 below.
While RSIP addresses the transparency and ALG issues, for the
specific case of an individual private host needing public access,
there is still a node with state required to maintain the connection.
Hain Informational [Page 11]
RFC 2993 Architectural Implications of NAT November 2000
Dynamic NAT and RSIP will eventually violate higher layer assumptions
about address/port number reuse as defined in RFC-793 [10] RFC-1323
[11]. The TCP state, TCP_TIME_WAIT, is specifically designed to
prevent replay of packets between the 4-tuple of IP and port for a
given IP address pair. Since the TCP state machine of a node is
unaware of any previous use of RSIP, its attempt to connect to the
same remote service that its neighbor just released (which is still
in TCP_TIME_WAIT) may fail, or with a larger sequence number may open
the prior connection directly from TCP_TIME_WAIT state, at the loss
of the protection afforded by the TCP_TIME_WAIT state (further
discussion in 2.6 of RFC-2663 [3]).
For address translators (which do not translate ports) to comply with
the TCP_TIME_WAIT requirements, they must refrain from assigning the
same address to a different host until a period of 2*MSL has elapsed
since the last use of the address, where MSL is the Maximum Segment
Lifetime defined in RFC-793 as two minutes. For address-and-port
translators to comply with this requirement, they similarly must
refrain from assigning the same host/port pair until 2*MSL has
elapsed since the end of its first use. While these requirements are
simple to state, they can place a great deal of pressure on the NAT,
because they temporarily reduce the pool of available addresses and
ports. Consequently, it will be tempting or NAT implementers to
ignore or shorten the TCP_TIME_WAIT requirements, at the cost of some
of TCP's strong reliability. Note that in the case where the strong
reliability is in fact compromised by the appearance of an old
packet, the failure can manifest itself as the receiver accepting
incorrect data. See further discussion in Illustration 3 below.
It is sometimes argued that NATs simply function to facilitate
"routing realms", where each domain is responsible for finding
addresses within its boundaries. Such a viewpoint clouds the
limitations created by NAT with the better-understood need for
routing management. Compartmentalization of routing information is
correctly a function of routing protocols and their scope of
application. NAT is simply a means to distribute address allocation
authority and provide a mechanism to map addresses from one address
realm into those of another realm.
In particular, it is sometimes erroneously believed that NATs serve
to provide routing isolation. In fact, if someone were to define an
OSPF ALG it would actually be possible to route across a NAT
boundary. Rather than NAT providing the boundary, it is the
experienced operators who know how to limit network topology that
serve to avoid leaking addresses across a NAT. This is an
operational necessity given the potential for leaked addresses to
introduce inconsistencies into the public infrastructure.
Hain Informational [Page 12]
RFC 2993 Architectural Implications of NAT November 2000
One of the greatest concerns from the explosion of NATs is the impact
on the fledgling efforts at deploying network layer end-to-end IP
security. One fundamental issue for IPSec is that with both AH and
ESP, the authentication check covers the TCP/UDP checksum (which in
turn covers the IP address). When a NAT changes the IP address, the
checksum calculation will fail, and therefore authentication is
guaranteed to fail. Attempting to use the NAT as a security boundary
fails when requirement is end-to-end network layer encryption, since
only the endpoints have access to the keys. See further discussion
in Illustration 4 below.
Finally, while the port multiplexing variants of NAT (popular because
they allow Internet access through a single address) work modestly
well for connecting private hosts to public services, they create
management problems for applications connecting from public toward
private. The concept of a well-known port is undermined because only
one private side system can be mapped through the single public-side
port number. This will affect home networks, when applications like
multi-player Internet games can only be played on one system at a
time. It will also affect small businesses when only one system at a
time can be operated on the standard port to provide web services.
These may sound like only medium-grade restrictions for the present,
but as a basic property of the Internet, not to change years into the
future, it is highly undesirable. The issue is that the public
toward private usage requires administrative mapping for each target
prior to connection. If the ISP chooses to provide a standardized
version of these to lower configuration options, they may find the
support costs of managing the ALGs will exceed the cost of additional
address space. See further discussion in Illustration 6 below.
7. Illustrations
7.1 Single point of failure
A characteristic of stateful devices like NATs is the creation of a
single point of failure. Attempts to avoid this by establishing
redundant NATs, creates a new set of problems related to timely
communication of the state, and routing related failures. This
encompasses several issues such as update frequency, performance
impact of frequent updates, reliability of the state update
transaction, a-priori knowledge of all nodes needing this state
information, and notification to end nodes of alternatives. (This
notification could be accomplished with a routing protocol, which
might require modifications to the hosts so they will listen.)
Hain Informational [Page 13]
RFC 2993 Architectural Implications of NAT November 2000
-------- --------
| Host A |-----| Host B |
-------- | --------
-----------------
| |
------ ------
| AD 1 | | AD 2 |
------ ------
\ /
--------
/Internet\
----------
--------
Illustration 1
In the traditional case where Access Device (AD) 1 & 2 are routers,
the single point of failure is the end Host, and the only effort
needed to maintain the connections through a router or link failure
is a simple routing update from the surviving router. In the case
where the ADs are a NAT variant there will be connection state
maintained in the active path that would need to be shared with
alternative NATs. When the Hosts have open connections through
either NAT, and it fails, the application connections will drop
unless the state had been previously moved to the surviving NAT. The
hosts will still need to acquire a routing redirect. In the case of
RSIP, the public side address pool would also need to be shared
between the ADs to allow movement. This sharing creates another
real-time operational complexity to prevent conflicting assignments
at connection setup. NAT as a technology creates a point fate
sharing outside the endpoints, in direct contradiction to the
original Internet design goals.
7.2. ALG complexity
In the following example of a proposed corporate network, each
NAT/ALG was to be one or more devices at each physical location, and
there were to be multiple physical locations per diagramed
connection. The logistics of simply updating software on this scale
is cumbersome, even when all the devices are the same manufacturer
and model. While this would also be true with routers, it would be
unnecessary for all devices to run a consistent version for an
application to work across an arbitrary path.
Hain Informational [Page 14]
RFC 2993 Architectural Implications of NAT November 2000
----------------------------------------
| Corporate Network |
| Asia |------| Americas |------| Europe |
------ ---------- --------
| | |
-------- -------- --------
|NAT/ALGs| |NAT/ALGs| |NAT/ALGs|
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -