rfc2709.txt

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

   maps and generates security policies that IKE could communicate
   during quick mode to peers in the external realm.

   Policies in quick mode are exchanged with a peer as a combination of
   IDci and IDcr payloads. The combination of IDs (policies) exchanged
   by each peer must match in order for the SA parameters on either end
   to be applied uniformly. If the IDs are not exchanged, the assumption
   would be that the Quick mode negotiated SA parameters are applicable
   between the IP addresses assumed by the main mode.

   Depending on the nature of security policies in place(ex: end-to-end
   sessions between a pair of nodes vs. sessions with an address range),
   IKE-ALG may need to request NAT to set up address bindings and/or
   transport bindings for the lifetime (in seconds or Kilo-Bytes) the
   sessions are negotiated. In the case the ALG is unable to setup the
   necessary address bindings or transport bindings, IKE-ALG will not be
   able to translate security policies and that will result in IKE not
   pursuing phase II negotiation for the effected policies.

   When the Negotiation is complete and successful, IKE will communicate
   the negotiated security parameters directly to the IPC-NAT gateway
   engine as described in the following diagram.





Srisuresh                    Informational                      [Page 6]

RFC 2709                Security for NAT Domains            October 1999


                                        +---------+
                                        |         |
        Negotiated Security Parameters  |  IKE    |
       +--------------------------------| Process |
       |(including session Keys)        |         |
       |                                +---------+
       |                                   ^   ^
       |                         Translated|   |
       |                             Secure|   |Security
       |                           Policies|   |Proposals
       v                                   |   |
   +---------+ Security Policies, based +---------+
   |         |------------------------->|         |
   |         | on Pvt. realm addressing |         |
   | IPC-NAT |                          |         |
   | (IPsec  | IPC-NAT MAPs             | IKE-ALG |
   | Gateway)|------------------------->|         |
   |         |                          |         |
   |         | Security Proposals       |         |
   |         |------------------------->|         |
   |         |                          |         |
   |         |  NAT Control exchange    |         |
   |         |<------------------------>|         |
   +---------+                          +---------+

   Figure 5. IKE-ALG translates Security policies, using NAT Maps.


5. Applications of IPC-NAT security model

   IPC-NAT operational model described thus far illustrates how a NAT
   device can be used as an IPsec tunnel end point to provide secure
   transfer of data in external realm. This section will attempt to
   illustrate two applications of such a model.

5.1. Secure Extranet Connectivity

   IPC-NAT Model has a direct application of being able to provide clear
   as well as secure connectivity with external realm using a NAT
   device. In particular, IPC-NAT device at the border of a private
   realm can peer with an IPsec gateway of an external domain to secure
   the Extranet connection. Extranet refers to the portion of the path
   that crosses the Internet between peering gateway nodes.








Srisuresh                    Informational                      [Page 7]

RFC 2709                Security for NAT Domains            October 1999


5.2. Secure Remote Access to Mobile Users of an Enterprise

   Say, a node from an enterprise moves out of the enterprise, and
   attempts to connect to the enterprise from remote site, using a
   temporary service provider assigned address (Care-of-Address). In
   such a case, the mobile user could setup an IPsec tunnel session with
   the corporate IPC-NAT device using a user-ID and authentication
   mechanism that is agreed upon. Further, the user may be configured
   with enterprise DNS server, as an extension of authentication
   following IKE Phase I. This would allow the user to access enterprise
   resources by name.

   However, many enterprise servers and applications rely on source IP
   address for authentication and deny access for packets that do not
   originate from the enterprise address space. In these scenarios,
   IPC-NAT has the ability (unlike a traditional IPsec gateway) to
   perform Network Address Translation (NAT) for remote access users, so
   their temporary address in external realm is translated into a
   enterprise domain address, while the packets are within private
   realm. The flavor of IPC-NAT performed would be traditional NAT
   (i.e., assuming mobile-user address space to be private realm and
   Enterprise address space to be external realm), which can either be
   Basic NAT (using a block of enterprise addresses for translation) or
   NAPT(using a single enterprise address for translation).

   The secure remote access application described is pertinent to all
   enterprises, irrespective of whether an enterprise uses IANA
   registered addresses or not.

   The secure remote access application described is different from
   Mobile-IP in that, the mobile node (described in this application)
   does not retain the Home-Network address and simply uses the Care-
   Of-address for communication purposes. It is conceivable for the
   IPC-NAT Gateway to transparently provide Mobile-IP type connectivity
   to the Mobile node by binding the mobile node's Care-of-Address with
   its Home Address. Provision of such an address mapping to IPC-NAT
   gateway, however, is not within the scope of this document.

6. Security Considerations

   If NATs and ALGs are not in a trusted boundary, that is a major
   security problem, as ALGs snoop end user traffic payload.
   Application 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 Realm-Specific IP, end-to-end IP network level security
   assured by current IPsec techniques is not attainable with NATs in
   between. The IPC-NAT model described in this document outlines an



Srisuresh                    Informational                      [Page 8]

RFC 2709                Security for NAT Domains            October 1999


   approach by which network level security may be obtained within
   external realm.

   NATs, 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 that
   IPC-NATs, ALGs and firewalls co-exist to provide security at the
   border of a private network.

REFERENCES

   [1]  Srisuresh, P. and M. Holdrege, "IP Network Address Translator
        (NAT) Terminology and Considerations", RFC 2663, August 1999.

   [2]  Kent, S. and R. Atkinson, "Security Architecture for the
        Internet Protocol", RFC 2401, November 1998

   [3]  Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
        (ESP)", RFC 2406, November 1998

   [4]  Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
        November 1998.

   [5]  Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
        RFC 2409, November 1998.

   [6]  Piper, D., "The Internet IP Security Domain of Interpretation
        for ISAKMP", RFC 2407, November 1998.

   [7]  Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address
        Behavior Today", RFC 2101, February 1997.

   [8]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot G. and E.
        Lear, "Address Allocation for Private Internets", BCP 5, RFC
        1918, February 1996.















Srisuresh                    Informational                      [Page 9]

RFC 2709                Security for NAT Domains            October 1999


Author's Address

   Pyda Srisuresh
   Lucent technologies
   4464 Willow Road
   Pleasanton, CA 94588-8519
   U.S.A.

   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]








































Srisuresh                    Informational                     [Page 10]

RFC 2709                Security for NAT Domains            October 1999


Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Srisuresh                    Informational                     [Page 11]