Browse Prior Art Database

Security Model with Tunnel-mode IPsec for NAT Domains (RFC2709)

IP.com Disclosure Number: IPCOM000003303D
Original Publication Date: 1999-Oct-01
Included in the Prior Art Database: 2019-Feb-10
Document File: 11 page(s) / 15K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

P. Srisuresh: AUTHOR

Related Documents

10.17487/RFC2709: DOI

Abstract

This document describes a security model by which tunnel-mode IPsec security can be architected on NAT devices. This memo provides information for the Internet community.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 14% of the total text.

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...

Processing...
Loading...