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