Security Model with Tunnel-mode IPsec for NAT Domains
RFC 2709

Document Type RFC - Informational (October 1999; No errata)
Author Pyda Srisuresh 
Last updated 2013-03-02
Stream Internent Engineering Task Force (IETF)
Formats plain text html pdf htmlized (tools) htmlized bibtex
Stream WG state WG Document
Document shepherd No shepherd assigned
IESG IESG state RFC 2709 (Informational)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
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.


   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

   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
Show full document text