rfc2709.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 620 行 · 第 1/2 页

Network Working Group                                       P. Srisuresh
Request for Comments: 2709                           Lucent Technologies
Category: Informational                                     October 1999


         Security Model with Tunnel-mode IPsec for NAT Domains

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

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

Abstract

   There are a variety of NAT flavors, as described in [Ref 1]. Of the
   domains supported by NATs, only Realm-Specific IP clients are able to
   pursue end-to-end IPsec secure sessions. However, all flavors of NAT
   are capable of offering tunnel-mode IPsec security to private domain
   hosts peering with nodes in external realm. This document describes a
   security model by which tunnel-mode IPsec security can be architected
   on NAT devices. A section is devoted to describing how security
   policies may be transparently communicated to IKE (for automated KEY
   exchange) during Quick Mode. Also outlined are applications that can
   benefit from the Security Model described.

1. Introduction and Overview

   NAT devices provide transparent routing to end hosts trying to
   communicate from disparate address realms, by modifying IP and
   transport headers en-route. This solution works best when the end
   user identifier (such as host name) is different from the address
   used to locate end user.

   End-to-end application level payload security can be provided for
   applications that do not embed realm-specific information in payloads
   that is meaningless to one of the end-users. Applications that do
   embed realm-specific information in payload will require an
   application level gateway (ALG) to make the payload meaningful in
   both realms. However, applications that require assistance of an ALG
   en-route cannot pursue end-to-end application level security.






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


   All applications traversing a NAT device, irrespective of whether
   they require assistance of an ALG or not, can benefit from IPsec
   tunnel-mode security, when NAT device acts as the IPsec tunnel end
   point.

   Section 2 below defines terms specific to this document.

   Section 3 describes how tunnel mode IPsec security can be recognized
   on NAT devices. IPsec Security architecture, format and operation of
   various types of security mechanisms may be found in [Ref 2], [Ref 3]
   and [Ref 4].  This section does not address how session keys and
   policies are exchanged between a NAT device acting as IPsec gateway
   and external peering nodes. The exchange could have taken place
   manually or using any of known automatic exchange techniques.

   Section 4 assumes that Public Key based IKE protocol [Ref 5] may be
   used to automate exchange of security policies, session keys and
   other Security Association (SA) attributes. This section describes a
   method by which security policies administered for a private domain
   may be translated for communicating with external nodes. Detailed
   description of IKE protocol operation may be found in [Ref 5] and
   [Ref 6].

   Section 5 describes applications of the security model described in
   the document. Applications listed include secure external realm
   connectivity for private domain hosts and secure remote access to
   enterprise mobile hosts.

2. Terminology

   Definitions for majority of terms used in this document may be found
   in one of (a) NAT Terminology and Considerations document [Ref 1],
   (b) IP security Architecture document [Ref 2], or (c) Internet Key
   Enchange (IKE) document [Ref 5]. Below are terms defined specifically
   for this document.

2.1. Normal-NAT

   The term "Normal-NAT" is introduced to distinguish normal NAT
   processing from the NAT processing used for secure packets embedded
   within an IPsec secure tunnel. "Normal-NAT" is the normal NAT
   processing as described in [Ref 1].

2.2. IPsec Policy Controlled NAT (IPC-NAT)

   The term "IPsec Policy Controlled NAT" (IPC-NAT, for short) is
   defined to describe the NAT transformation applied as an extension of
   IPsec transformation to packets embedded within an IP-IP tunnel, for



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


   which the NAT node is a tunnel end point. IPC-NAT function is
   essentially an adaptation of NAT extensions to embedded packets of
   tunnel-mode IPsec. Packets subject to IPC-NAT processing are
   beneficiaries of IPsec security between the NAT device and an
   external peer entity, be it a host or a gateway node.

   IPsec policies place restrictions on what NAT mappings are used.  For
   example, IPsec access control security policies to a peer gateway
   will likely restrict communication to only certain addresses and/or
   port numbers. Thus, when NAT performs translations, it must insure
   that the translations it performs are consist with the security
   policies.

   Just as with Normal-NAT, IPC-NAT function can assume any of NAT
   flavors, including Traditional-NAT, Bi-directional-NAT and Twice-NAT.
   An IPC-NAT device would support both IPC-NAT and normal-NAT
   functions.

3. Security model of IPC-NAT

   The IP security architecture document [Ref 2] describes how IP
   network level security may be accomplished within a globally unique
   address realm. Transport and tunnel mode security are discussed. For
   purposes of this document, we will assume IPsec security to mean
   tunnel mode IPsec security, unless specified otherwise. Elements
   fundamental to this security architecture are (a) Security Policies,
   that determine which packets are permitted to be subject to Security
   processing, and (b) Security Association Attributes that identify the
   parameters for security processing, including IPsec protocols,
   algorithms and session keys to be applied.

   Operation of tunnel mode IPsec security on a device that does not
   support Network Address Translation may be described as below in
   figures 1 and 2.

            +---------------+  No  +---------------------------+
            |               | +--->|Forward packet in the Clear|
   Outgoing |Does the packet| |    |Or Drop, as appropriate.   |
   -------->|match Outbound |-|    +---------------------------+
   Packet   |Security       | |    +-------------+
            |Policies?      | |Yes |Perform      | Forward
            |               | +--->|Outbound     |--------->
            +---------------+      |Security     | IPsec Pkt
                                   |(Tunnel Mode)|
                                   +-------------+

   Figure 1. Operation of Tunnel-Mode IPsec on outgoing packets.




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


   IPsec packet +----------+          +----------+
   destined to  |Perform   | Embedded |Does the  | No(Drop)
   ------------>|Inbound   |--------->|Pkt match |-------->
   the device   |Security  | Packet   |Inbound SA| Yes(Forward)
                |(Detunnel)|          |Policies? |
                +----------+          +----------+

   Figure 2. Operation of Tunnel-Mode IPsec on Incoming packets

   A NAT device that provides tunnel-mode IPsec security would be
   required to administer security policies based on private realm
   addressing. Further, the security policies determine the IPsec tunnel
   end-point peer. As a result, a packet may be required to undergo
   different type of NAT translation depending upon the tunnel end-point
   the IPsec node peers with. In other words, IPC-NAT will need a unique
   set of NAT maps for each security policy configured. IPC-NAT will
   perform address translation in conjunction with IPsec processing
   differently with each peer, based on security policies.  The
   following diagrams (figure 3 and figure 4) illustrate the operation
   of IPsec tunneling in conjunction with NAT. Operation of an IPC-NAT
   device may be distinguished from that of an IPsec gateway that does
   not support NAT as follows.

        (1) IPC-NAT device has security policies administered using
            private realm addressing. A traditional IPsec gateway will
            have its security policies administered using a single realm
            (say, external realm) addressing.

        (2) Elements fundamental to the security model of an IPC-NAT
            device includes IPC-NAT address mapping  (and other NAT
            parameter definitions) in conjunction with Security policies
            and SA attributes. Fundamental elements of a traditional
            IPsec gateway are limited only to Security policies and SA
            attributes.


            +---------------+      +-------------------------+
            |               |  No  | Apply Normal-NAT or Drop|
   Outgoing |Does the packet| +--->| as appropriate          |
   -------->|match Outbound |-|    +-------------------------+
   Packet   |Security       | |    +---------+  +-------------+
   (Private |Policies?      | |Yes |Perform  |  |Perform      |Forward
    Domain) |               | +--->|Outbound |->|Outbound     |-------->
            +---------------+      |NAT      |  |Security     |IPsec Pkt
                                   |(IPC-NAT)|  |(Tunnel mode)|
                                   +---------+  +-------------+

   Figure 3. Tunnel-Mode IPsec on an IPC-NAT device for outgoing pkts



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


   IPsec Pkt +----------+          +---------+  +----------+
   destined  |Perform   | Embedded |Perform  |  |Does the  |No(Drop)
   --------->|Inbound   |--------->|Inbound  |->|Pkt match |-------->
   to device |Security  | Packet   |NAT      |  |Inbound SA|Yes(Forward)
   (External |(Detunnel)|          |(IPC-NAT)|  |Policies? |
    Domain)  +----------+          +---------+  +----------+

   Figure 4. Tunnel-Mode IPsec on an IPC-NAT device for Incoming pkts

   Traditional NAT is session oriented, allowing outbound-only sessions
   to be translated. All other flavors of NAT are Bi-directional.  Any
   and all flavors of NAT mapping may be used in conjunction with the
   security policies and secure processing on an IPC-NAT device. For
   illustration purposes in this document, we will assume tunnel mode
   IPsec on a Bi-directional NAT device.

   Notice however that a NAT device capable of providing security across
   IPsec tunnels can continue to support Normal-NAT for packets that do
   not require IPC-NAT. Address mapping and other NAT parameter
   definitions for Normal-NAT and IPC-NAT are distinct. Figure 3
   identifies how a NAT device distinguishes between outgoing packets
   that need to be processed through Normal-NAT vs. IPC-NAT. As for
   packets incoming from external realm, figure 4 outlines packets that
   may be subject to IPC-NAT. All other packets are subject to Normal-
   NAT processing only.

4. Operation of IKE protocol on IPC-NAT device.

   IPC-NAT operation described in the previous section can be
   accomplished based on manual session key exchange or using an
   automated key Exchange protocol between peering entities. In this
   section, we will consider adapting IETF recommended Internet Key
   Exchange (IKE) protocol on a IPC-NAT device for automatic exchange of
   security policies and SA parameters. In other words, we will focus on
   the operation of IKE in conjunction with tunnel mode IPsec on NAT
   devices. For the reminder of this section, we will refer NAT device
   to mean IPC-NAT device, unless specified otherwise.

   IKE is based on UDP protocol and uses public-key encryption to
   exchange session keys and other attributes securely across an address
   realm. The detailed protocol and operation of IKE in the context of
   IP may be found in [Ref 3] and [Ref 4]. Essentially, IKE has 2
   phases.

   In the first phase, IKE peers operate in main or aggressive mode to
   authenticate each other and set up a secure channel between
   themselves. A NAT device  has an interface to the external realm and
   is no different from any other node in the realm to negotiate phase I



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


   with peer external nodes. The NAT device may assume any of the valid
   Identity types and authentication methodologies necessary to
   communicate and authenticate with peers in the realm. The NAT device
   may also interface with a Certification Authority (CA) in the realm
   to retrieve certificates  and perform signature validation.

   In the second phase, IKE peers operate in Quick Mode to exchange
   policies and IPsec security proposals to negotiate and agree upon
   security transformation algorithms, policies, keys, lifetime and
   other security attributes. During this phase, IKE process must
   communicate with IPsec Engine to (a) collect secure session
   attributes and other parameters  to negotiate with peer IKE nodes,
   and to (b) notify security parameters agreed upon (with peer) during
   the negotiation.

   An IPC-NAT device, operating as IPsec gateway, has the security
   policies administered based on private realm addressing. An ALG will
   be required to translate policies from private realm addressing into
   external addressing, as the IKE process needs to communicate these
   policies to peers in external realm. Note, IKE datagrams are not
   subject to any NAT processing. IKE-ALG simply translates select
   portions of IKE payload as per the NAT map defined for the policy
   match. The following diagram illustrates how an IKE-ALG process
   interfaces with IPC-NAT to take the security policies and IPC-NAT