rfc2993.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

             |    Host A     |   ---       ---   |    Host B      |
             |    10.1.1.1   |--|NAT|-----|NAT|--|  10.10.10.10   |
              ---------------    ---       ---    ----------------

                                --------
                             Illustration 6

 7.7.  Centralized data collection system report correlation

   It has been reported that NAT introduces additional challenges when
   intrusion detection systems attempt to correlate reports between
   sensors inside and outside the NAT.  While the details of individual
   systems are beyond the scope of this document, it is clear that a
   centralized system with monitoring agents on both sides of the NAT
   would also need access to the current NAT mappings to get this right.
   It would also be critical that the resulting data be indexed properly
   if there were agents behind multiple NATs using the same address
   range for the private side.

   This also applies to management data collected via SNMP.  Any time
   the data stream carries an IP address; the central collector or ALG
   will need to manipulate the data based on the current mappings in the



Hain                         Informational                     [Page 20]

RFC 2993           Architectural Implications of NAT       November 2000


   NAT.

8.  IPv6

   It has been argued that IPv6 is no longer necessary because NATs
   relieve the address space constraints and allow the Internet to
   continue growing.  The reality is they point out the need for IPv6
   more clearly than ever.  People are trying to connect multiple
   machines through a single access line to their ISP and have been
   willing to give up some functionality to get that at minimum cost.

   Frequently the reason for cost increases is the perceived scarcity
   (therefore increased value) of IPv4 addresses, which would be
   eliminated through deployment of IPv6.  This crisis mentality is
   creating a market for a solution to a problem already solved with
   greater flexibility by IPv6.

   If NAT had never been defined, the motivation to resolve the
   dwindling IPv4 address space would be a much greater.  Given that
   NATs are enabling untold new hosts to attach to the Internet daily,
   it is difficult to ascertain the actual impact to the lifetime of
   IPv4, but NAT has certainly extended it.  It is also difficult to
   determine the extent of delay NAT is causing for IPv6, both by
   relieving the pressure, and by redirecting the intellectual cycles
   away from the longer-term solution.

   But at the same time NAT functionality may be a critical facilitator
   in the deployment of IPv6.  There are already 100 million or more
   computers running IPv4 on data networks.  Some of these networks are
   connected to and thus part of the Internet and some are on private
   isolated networks.  It is inconceivable that we could have a "flag
   day" and convert all of the existing IPv4 nodes to IPv6 at the same
   time.  There will be a very long period of coexistence while both
   IPv4 and IPv6 are being used in the Internet and in private networks.
   The original IPv6 transition plan relied heavily on having new IPv6
   nodes also be able to run IPv4 - a "dual stack" approach. When the
   dual stack node looks up another node in the DNS it will get back a
   IPv4 or an IPv6 address in response.  If the response is an IPv4
   address then the node uses IPv4 to contact the other node. And if the
   response is an IPv6 address then IPv6 can be used to make the
   contact.  Turning the NAT into a 6to4 [13]router enables widespread
   deployment of IPv6 while providing an IPv4 path if IPv6 is
   unavailable.  While this maintains the current set of issues for IPv4
   connections, it reestablishes the end-to-end principle for IPv6
   connections.






Hain                         Informational                     [Page 21]

RFC 2993           Architectural Implications of NAT       November 2000


   An alternative methodology would be to translate the packets between
   IPv6 and IPv4 at the boarders between IPv4 supporting networks and
   IPv6 supporting networks.  The need for this functionality was
   recognized in [RFC 1752], the document that recommended to the IETF
   that IPv6 be developed and recommended that a set of working groups
   be established to work on a number of specific problems.  Header
   translation (i.e, NAT) was one of those problems.

   Of course, NATs in an IPv6 to IPv4 translation environment encounter
   all of the same problems that NATs encounter in a pure IPv4 and the
   environment and cautions in this document apply to both situations.

9.  Security Considerations

   NAT (particularly NAPT) actually has the potential to lower overall
   security because it creates the illusion of a security barrier, but
   does so without the managed intent of a firewall.  Appropriate
   security mechanisms are implemented in the end host, without reliance
   on assumptions about routing hacks, firewall filters, or missing NAT
   translations, which may change over time to enable a service to a
   neighboring host.  In general, defined security barriers assume that
   any threats are external, leading to practices that make internal
   breaches much easier.

   IPsec RFC-2401 [7] defines a set of mechanisms to support packet-
   level authentication and encryption for use in IP networks.  While
   this may be less efficient than application-level security but in the
   words of RFC-1752 [14] "support for basic packet-level authentication
   will provide for the adoption of a much needed, widespread, security
   infrastructure throughout the Internet."

   NATs break IPsec's authentication and encryption technologies because
   these technologies depend on an end-to-end consistency of the IP
   addresses in the IP headers, and therefore may stall further
   deployment of enhanced security across the Internet.  NATs raise a
   number of specific issues with IPsec.  For example;

   - Use of AH is not possible via NAT as the hash protects the IP
     address in the header.
   - Authenticated certificates may contain the IP address as part of
     the subject name for authentication purposes.
   - Encrypted Quick Mode structures may contain IP addresses and ports
     for policy verifications.
   - The Revised Mode of public key encryption includes the peer
     identity in the encrypted payload.






Hain                         Informational                     [Page 22]

RFC 2993           Architectural Implications of NAT       November 2000


   It may be possible to engineer and work around NATs for IPsec on a
   case-by-case basis, but at the cost of restricting the trust model,
   as discussed in section 4 above.  With all of the restrictions placed
   on deployment flexibility, NATs present a significant obstacle to
   security integration being deployed in the Internet today.

   As noted in the RFC-2694 [15], the DNS/ALG cannot support secure DNS
   name servers in the private domain.  Zone transfers between DNSsec
   servers will be rejected when necessary modifications are attempted.
   It is also the case that DNS/ALG will break any modified, signed
   responses.  This would be the case for all public side queries of
   private nodes, when the DNS server is on the private side.  It would
   also be true for any private side queries for private nodes, when the
   DNS server is on the public side.  Digitally signed records could be
   modified by the DNS/ALG if it had access to the source authentication
   key.  DNSsec has been specifically designed to avoid distribution of
   this key, to maintain source authenticity.  So NATs that use DNS/ALG
   to repair the namespace resolutions will either; break the security
   when modifying the record, or will require access to all source keys
   to requested resolutions.

   Security mechanisms that do not protect or rely on IP addresses as
   identifiers, such as TLS [16], SSL [17], or SSH [18] may operate in
   environments containing NATs.  For applications that can establish
   and make use of this type of transport connection, NATs do not create
   any additional complications.  These technologies may not provide
   sufficient protection for all applications as the header is exposed,
   allowing subversive acts like TCP resets.  RFC-2385 [19] discusses
   the issues in more detail.

   Arguments that NATs may operate in a secure mode preclude true End-
   to-End security, as the NAT becomes the security endpoint.
   Operationally the NAT must be managed as part of the security domain,
   and in this mode the packets on the unsecured side of the NAT are
   fully exposed.

10.  Deployment Guidelines

   Given that NAT devices are being deployed at a fairly rapid pace,
   some guidelines are in order.  Most of these cautionary in nature and
   are designed to make sure that the reader fully understands the
   implications of the use of NATs in their environment.

   - Determine the mechanism for name resolution, and ensure the
     appropriate answer is given for each address administration.
     Embedding the DNS server, or a DNS ALG in the NAT device will
     likely be more manageable than trying to synchronize independent
     DNS systems across administrations.



Hain                         Informational                     [Page 23]

RFC 2993           Architectural Implications of NAT       November 2000


   - Is the NAT configured for static one to one mappings, or will it
     dynamically manage them? If dynamic, make sure the TTL of the DNS
     responses is set to 0, and that the clients pay attention to the
     don't cache notification.
   - Will there be a single NAT device, or parallel with multiple paths?
     If single, consider the impact of a device failure.  If multiple,
     consider how routing on both sides will insure the packets flow
     through the same box over the connection lifetime of the
     applications.
   - Examine the applications that will need to traverse the NAT and
     verify their immunity to address changes.  If necessary provide an
     appropriate ALG or establish a VPN to isolate the application from
     the NAT.
   - Determine need for public toward private connections, variability
     of destinations on the private side, and potential for simultaneous
     use of public side port numbers.  NAPTs increase administration if
     these apply.
   - Determine if the applications traversing the NAPT or RSIP expect
     all ports from the public IP address to be the same endpoint.
     Administrative controls to prevent simultaneous access from
     multiple private hosts will be required if this is the case.
   - If there are encrypted payloads, the contents cannot be modified
     unless the NAT is a security endpoint, acting as a gateway between
     security realms.  This precludes end-to-end confidentiality, as the
     path between the NAT and endpoint is exposed.
   - Determine the path for name resolutions.  If hosts on the private
     side of a NAPT or RSIP server need visibility to each other, a
     private side DNS server may be required.
   - If the environment uses secure DNS records, the DNS/ALG will
     require access to the source authentication keys for all records to
     be translated.
   - When using VPNs over NATs, identify a clearinghouse for the private
     side addresses to avoid collisions.
   - Assure that applications used both internally and externally avoid
     embedding names, or use globally unique ones.
   - When using RSIP, recognize the scope is limited to individual
     private network connecting to the public Internet.  If other NATs
     are in the path (including web-server load-balancing devices), the
     advantage of RSIP (end-to-end address/port pair use) is lost.
   - For RSIP, determine the probability of TCP_Time_Wait collisions
     when subsequent private side hosts attempt to contact a recently
     disconnected public side service.









Hain                         Informational                     [Page 24]

RFC 2993           Architectural Implications of NAT       November 2000


11.  Summary

   Over the 6-year period since RFC-1631, the experience base has grown,
   further exposing concerns raised by the original authors.  NAT breaks
   a fundamental assumption of the Internet design; the endpoints are in
   control.  Another design principle, 'keep-it-simple' is being
   overlooked as more features are added to the network to work around
   the complications created by NATs.  In the end, overall flexibility
   and manageability are lowered, and support costs go up to deal with
   the problems introduced.

   Evangelists, for and against the technology, present their cases as
   righteous while downplaying any rebuttals.

   - NATs are a 'fact of life', and will proliferate as an enhancement
     that sustains the existing