rfc2663.txt

NAT协议完整源代码

   For example, a private network connected to a business partner
   through a VPN could employ traditional NAT to communicate with the
   partner. Likewise, it is possible to employ twice NAT, if the
   partner's address space overlapped with the private network.  There
   could be a NAT device on one end of the tunnel or on both ends of the
   tunnel. In all cases, traffic across the VPN can be encrypted for
   security purposes. Security here refers to security for traffic
   across VPNs alone. End-to-end security requires trusting NAT devices
   within private network.

6.2. Backbone partitioned private Networks

   There are many instances where a private network (such as a corporate
   network) is spread over different locations and use public backbone
   for communications between those locations. In such cases, it is not
   desirable to do address translation, both because large numbers of
   hosts may want to communicate across the backbone, thus requiring
   large address tables, and because there will be more applications
   that depend on configured addresses, as opposed to going to a name
   server. We call such a private network a backbone-partitioned private
   network.

   Backbone-partitioned stubs should behave as though they were a non-
   partitioned stub. That is, the routers in all partitions should
   maintain routes to the local address spaces of all partitions. Of
   course, the (public) backbones do not maintain routes to any local
   addresses. Therefore, the border routers must tunnel (using VPNs)
   through the backbones using encapsulation.  To do this, each NAT box
   will set aside a global address for tunneling.

   When a NAT box x in stub partition X wishes to deliver a packet to
   stub partition Y, it will encapsulate the packet in an IP header with
   destination address set to the global address of NAT box y that has
   been reserved for encapsulation. When NAT box y receives a packet
   with that destination address, it decapsulates the IP header and
   routes the packet internally.  Note, there is no address translation
   in the process; merely transfer of private network packets over an
   external network tunnel backbone.







Srisuresh & Holdrege         Informational                     [Page 22]

RFC 2663           NAT Terminology and Considerations        August 1999


7.0. NAT operational characteristics

   NAT devices are application unaware in that the translations are
   limited to IP/TCP/UDP/ICMP headers and ICMP error messages only.  NAT
   devices do not change the payload of the packets, as payloads tend to
   be application specific.

   NAT devices (without the inclusion of ALGs) do not examine or modify
   transport payload. For this reason, NAT devices are transparent to
   applications in many cases. There are two areas, however, where NAT
   devices often cause difficulties: 1) when an application payload
   includes an IP address, and 2) when end-to-end security is needed.
   Note, this is not a comprehensive list.

   Application layer security techniques that do not make use of or
   depend on IP addresses will work correctly in the presence of NAT
   (e.g., TLS,  SSL and ssh). In contrast, transport layer techniques
   such as IPSec transport mode or the TCP MD5 Signature Option RFC 2385
   [Ref 17] do not.

   In IPSec transport mode, both AH and ESP have an integrity check
   covering the entire payload. When the payload is TCP or UDP, the
   TCP/UDP checksum is covered by the integrity check. When a NAT device
   modifies an address the checksum is no longer valid with respect to
   the new address. Normally, NAT also updates the checksum, but this is
   ineffective when AH and ESP are used.  Consequently, receivers will
   discard a packet either because it fails the IPSec integrity check
   (if the NAT device updates the checksum), or because the checksum is
   invalid (if the NAT device leaves the checksum unmodified).

   Note that IPsec tunnel mode ESP is permissible so long as the
   embedded packet contents are unaffected by the outer IP header
   translation. Although this technique does not work in traditional NAT
   deployments (i.e., where hosts are unaware that NATs are present),
   the technique is applicable to Realm-Specific IP as described in
   Section 5.0.

   Note also that end-to-end ESP based transport mode authentication and
   confidentiality are permissible for packets such as ICMP, whose IP
   payload content is unaffected by the outer IP header translation.

   NAT devices also break fundamental assumptions by public key
   distribution infrastructures such as Secure DNS RFC 2535 [Ref 18] and
   X.509 certificates with signed public keys. In the case of Secure







Srisuresh & Holdrege         Informational                     [Page 23]

RFC 2663           NAT Terminology and Considerations        August 1999


   DNS, each DNS RRset is signed with a key from within the zone.
   Moreover, the authenticity of a specific key is verified by following
   a chain of trust that goes all the way to the DNS root.  When a DNS-
   ALG modifies addresses (e.g., as in the case of Twice-NAT),
   verification of signatures fails.

   It may be of interest to note that IKE (Session key negotiation
   protocol) is a UDP based session layer protocol and is not protected
   by network based IPsec security. Only a portion of the individual
   payloads within IKE are protected. As a result, IKE sessions are
   permissible across NAT, so long as IKE payload does not contain
   addresses and/or transport IDs specific to one realm and not the
   other. Given that IKE is used to setup IPSec associations, and there
   are at present no known ways of making IPSec work through a NAT
   function, it is a future work item to take advantage of IKE through a
   NAT box.

   One of the most popular internet applications "FTP" would not work
   with the definition of NAT as described. The following sub-section is
   devoted to describing how FTP is supported on NAT devices.  FTP ALG
   is an integral part of most NAT implementations. Some vendors may
   choose to include additional ALGs to custom support other
   applications on the NAT device.

7.1. FTP support

   "PORT" command and "PASV" response in FTP control session payload
   identify the IP address and TCP port that must be used for the data
   session it supports. The arguments to the PORT command and PASV
   response are an IP address and a TCP port in ASCII. An FTP ALG is
   required to monitor and update the FTP control session payload so
   that information contained in the payload is relevant to end nodes.
   The ALG must also update NAT with appropriate data session tuples and
   session orientation so that NAT could set up state information for
   the FTP data sessions.

   Because the address and TCP port are encoded in ASCII, this may
   result in a change in the size of packet.  For instance,
   10,18,177,42,64,87 is 18 ASCII characters, whereas
   193,45,228,137,64,87 is 20 ASCII characters. If the new size is same
   as the previous, only the TCP checksum needs adjustment as a result
   of change of data. If the new size is less than or greater than the
   previous, TCP sequence numbers must also be changed to reflect the
   change in length of FTP control data portion.  A special table may be
   used by the ALG to correct the TCP sequence and acknowledge numbers.
   The sequence number and acknowledgement correction will need to be
   performed on all future packet of the connection.




Srisuresh & Holdrege         Informational                     [Page 24]

RFC 2663           NAT Terminology and Considerations        August 1999


8.0. NAT limitations

8.1. Applications with IP-address Content

   Not All applications lend themselves easily to address translation by
   NAT devices. Especially, the applications that carry IP address (and
   TU port, in case of NAPT) inside the payload. Application Level
   Gateways, or ALGs must be used to perform translations on packets
   pertaining to such applications. ALGs may optionally utilize address
   (and TU port) assignments made by NAT and perform translations
   specific to the application. The combination of NAT functionality and
   ALGs will not provide end-to-end security assured by IPsec.  However,
   tunnel mode IPsec can be accomplished with NAT router serving as
   tunnel end point.

   SNMP is one such application with address content in payload. NAT
   routers would not translate IP addresses within SNMP payloads. It is
   not uncommon for an SNMP specific ALG to reside on a NAT router to
   perform SNMP MIB translations proprietary to the private network.

8.2. Applications with inter-dependent control and data sessions

   NAT devices operate on the assumption that each session is
   independent.  Session characteristics like session orientation,
   source and destination IP addresses, session protocol, and source and
   destination transport level identifiers are determined independently
   at the start of each new session.

   However, there are applications such as H.323 that use one or more
   control sessions to set the characteristics of the follow-on sessions
   in their control session payload. Such applications require use of
   application specific ALGs that can interpret and translate the
   payload, if necessary. Payload interpretation would help NAT be
   prepared for the follow-on data sessions.

8.3. Debugging Considerations

   NAT increases the probability of mis-addressing. For example, same
   local address may be bound to different global address at different
   times and vice versa. As a result, any traffic flow study based
   purely on global addresses and TU ports could be confused and might
   misinterpret the results.

   If a host is abusing the Internet in some way (such as trying to
   attack another machine or even sending large amounts of junk mail or
   something) it is more difficult to pinpoint the source of the trouble
   because the IP address of the host is hidden in a NAT router.




Srisuresh & Holdrege         Informational                     [Page 25]

RFC 2663           NAT Terminology and Considerations        August 1999


8.4. Translation of fragmented FTP control packets

   Translation of fragmented FTP control packets is tricky when the
   packets contain "PORT" command or response to "PASV" command.
   Clearly, this is a pathological case. NAT router would need to
   assemble the fragments together first and then translate prior to
   forwarding.

   Yet another case would be when each character of packets containing
   "PORT" command or response to "PASV" is sent in a separate datagram,
   unfragmented. In this case, NAT would simply have to let the packets
   through, without translating the TCP payload. Of course, the
   application will fail if the payload needed to be altered. The
   application could still work in a few cases, where the payload
   contents can be valid in both realms, without modifications enroute.
   For example, FTP originated from a private host would still work
   while traversing a traditional NAT or bi-directional NAT device, so
   long as the FTP control session employed PASV command to establish
   data sessions. The reason being that the address and port number
   specified by FTP server in the PASV response (sent as multiple
   unfragmented packets) is valid to the private host, as is. The NAT
   device will simply view the ensuing data session (also originating
   from private host) as an independent TCP session.

8.5. Compute intensive

   NAT is compute intensive even with the help of a clever checksum
   adjustment algorithm, as each data packet is subject to NAT lookup
   and modifications.  As a result, router forwarding throughput could
   be slowed considerably. However, so long as the processing capacity
   of the NAT device exceeds line processing rate, this should not be a
   problem.

9.0. Security Considerations

   Many people view traditional NAT router as a one-way (session)
   traffic filter, restricting sessions from external hosts into their
   machines. In addition, when address assignment in NAT router is done
   dynamically, that makes it harder for an attacker to point to any
   specific host in the NAT domain. NAT routers may be used in
   conjunction with firewalls to filter unwanted traffic.

   If NAT devices and ALGs are not in a trusted boundary, that is a
   major security problem, as ALGs could snoop end user traffic payload.
   Session level payload could be encrypted end to end, so long as the
   payload does not contain IP addresses and/or transport identifiers
   that are valid in only one of the realms. With the exception of RSIP,
   end-to-end IP network level security assured by current IPsec



Srisuresh & Holdrege         Informational                     [Page 26]

RFC 2663           NAT Terminology and Considerations        August 1999


   techniques is not attainable with NAT devices in between. One of the
   ends must be a NAT box. Refer section 7.0 for a discussion on why
   end-to-end IPsec security cannot be assured with NAT devices along
   the route.

   The combination of NAT functionality, ALGs and firewalls will provide
   a transparent working environment for a private networking domain.
   With the exception of RSIP, end-to-end network security assured by
   IPsec cannot be attained for end-hosts within the private network
   (Refer section 5.0 for RSIP operation). In all other cases, if you
   want to use end-to-end IPsec, there cannot be a NAT device in the
   path. If we make the assumption that NAT devices are part of a
   trusted boundary, tunnel mode IPsec can be accomplished with NAT
   router (or a combination of NAT, ALGs and firewall) serving as tunnel
   end point.

   NAT devices, when combined with ALGs, can ensure that the datagrams
   injected into Internet have no private addresses in headers or
   payload. Applications that do not meet these requirements may be
   dropped using firewall filters. For this reason, it is not uncommon
   to find NAT, ALG and firewall functions co-exist to provide security
   at the borders o