< draft-gupta-ipsec-remote-access-02.txt   draft-gupta-ipsec-remote-access-03.txt >
INTERNET-DRAFT Vipul Gupta INTERNET-DRAFT Vipul Gupta
SUN Microsystems, Inc SUN Microsystems, Inc
Jun 7, 1999 Oct 22, 1999
Secure, Remote Access over the Internet using IPSec Secure Remote Access over the Internet using IPSec
<draft-gupta-ipsec-remote-access-02.txt> <draft-gupta-ipsec-remote-access-03.txt>
Status of this Memo Status of this Memo
This document is an Internet Draft and is in full conformance with This document is an Internet Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [Bra96]. Internet Drafts are all provisions of Section 10 of RFC2026 [Bra96]. Internet Drafts are
working documents of the Internet Engineering Task Force (IETF), its working documents of the Internet Engineering Task Force (IETF), its
areas, and working groups. Note that other groups may also distribute areas, and working groups. Note that other groups may also distribute
working documents as Internet Drafts. working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six months Internet Drafts are draft documents valid for a maximum of six months
skipping to change at page 1, line 45 skipping to change at page 2, line 5
This memo describes the use of IPSec [KeAt98a-c] for secure access to This memo describes the use of IPSec [KeAt98a-c] for secure access to
protected networks by authorized users connected to the Internet. An protected networks by authorized users connected to the Internet. An
example target scenario is a corporate employee on the road accessing example target scenario is a corporate employee on the road accessing
resources on his company's Intranet. It addresses firewall traversal, resources on his company's Intranet. It addresses firewall traversal,
user authentication, data confidentiality and the use of private user authentication, data confidentiality and the use of private
address spaces (the latter impacts routing and name lookups). A address spaces (the latter impacts routing and name lookups). A
comparison to other mechanisms such as those based on Layer-2 comparison to other mechanisms such as those based on Layer-2
tunneling or session layer security, is also included. tunneling or session layer security, is also included.
This memo draws upon several ideas from [Dora97,Mosk98] and would not
have been possible without the contributions of the IETF working
groups on IP Security (IPSec) and Network Address Translation (NAT).
1. Introduction: 1. Introduction:
Traditionally, corporate employees have accessed their protected Traditionally, corporate employees have accessed their protected
networks remotely by dialing into their company's modem pools. More networks remotely by dialing into their company's modem pools. More
recently, mechanisms that use the Internet (rather than the Public recently, mechanisms that use the Internet (rather than the Public
Switched Telephone Network (PSTN)) for their transport are gaining Switched Telephone Network (PSTN)) for their transport are gaining
popularity since they offer significant savings in infrastructure popularity since they offer significant savings in infrastructure
costs and toll charges along with greater flexibility. Clearly, costs and toll charges along with greater flexibility. Clearly,
security is an important concern in this situation. Strong security is an important concern in this situation. Strong
cryptographic mechanisms are required to ensure that only authorized cryptographic mechanisms are required to ensure that only authorized
skipping to change at page 5, line 35 skipping to change at page 5, line 35
establishment of "pay-as-you-go" connectivity slots at establishment of "pay-as-you-go" connectivity slots at
public places like airport terminals. By swiping their public places like airport terminals. By swiping their
credit cards or paying cash, users would be able to credit cards or paying cash, users would be able to
gain high speed (a megabit or more per second) access to gain high speed (a megabit or more per second) access to
the Internet. Once on the Internet, they'd be able to the Internet. Once on the Internet, they'd be able to
utilize mechanisms described in this memo to establish utilize mechanisms described in this memo to establish
a secure, virtual presence on their office network. a secure, virtual presence on their office network.
As IPSec standards mature, we expect client operating systems to As IPSec standards mature, we expect client operating systems to
bundle this functionality, greatly alleviating the challenge of bundle this functionality, greatly alleviating the challenge of
deploying IPSec at the user's end. deploying IPSec at the user's end. Almost all major operating system
vendors have announced plans to include IPSec in their OS offering
within the year (as of Oct 1999).
3. Operation Details: 3. Operation Details:
The basic operation is illustrated in the following diagram. Detailed The basic operation is illustrated in the following diagram. Detailed
security considerations are presented later. security considerations are presented later.
I N T E R N E T | P R O T E C T E D N E T I N T E R N E T | P R O T E C T E D N E T
| |
| |
(a) G_e IPSec G_i (b) (a) G_e IPSec G_i (b)
skipping to change at page 6, line 4 skipping to change at page 6, line 15
I N T E R N E T | P R O T E C T E D N E T I N T E R N E T | P R O T E C T E D N E T
| |
| |
(a) G_e IPSec G_i (b) (a) G_e IPSec G_i (b)
Remote --------> ------gateway------- ------> Internal Remote --------> ------gateway------- ------> Internal
computer (R) <------- (G) <------ host (H) computer (R) <------- (G) <------ host (H)
connected (d) | (c) connected (d) | (c)
via an ISP- | via an ISP- |
assigned | assigned |
address, R_e address, R_e
(a),(d) = This traffic is protected by an IPSec tunnel. R_e (a),(d) = This traffic is protected by an IPSec tunnel. R_e
and G_e appear as src/dst for this traffic. and G_e appear as src/dst for this traffic.
(b),(c) = This traffic is in the clear but external address (b),(c) = This traffic is in the clear but external address
R_e does not appear either as source or destination. R_e does not appear either as source or destination.
Figure 1: Operational overview. Figure 1: Operational overview.
In Figure 1, R is an IPSec-capable remote host connected to the In Figure 1, R is an IPSec-capable remote host connected to the
Internet using an ISP-assigned address R_e. G is an IPSec gateway at Internet using an ISP-assigned address R_e. G is an IPSec gateway at
the boundary of the protected network such that its "external" IP the boundary of the protected network such that its "external" IP
address G_e is reachable from the Internet. H denotes an internal address G_e is reachable from the Internet. H denotes an internal
host/server with which R wishes to communicate. The remote host host/server with which R wishes to communicate.
negotiates a tunnel-mode IPSec security association with the IPSec
gateway. This may be accomplished using IKE [HaCa98] or any other The remote host negotiates a tunnel-mode IPSec security association
means as long as it does not preclude the remote host using a with the IPSec gateway. This may be accomplished using IKE [HaCa98]
dynamically assigned address. Note that a minimally-compliant IKE or any other means as long as it does not preclude the remote host
implementation (that only implements Main mode with Pre-shared keys using a dynamically assigned address. Note that a minimally-compliant
for authentication in Phase I) cannot be used on a remote host with a IKE implementation (which only implements Main mode with Pre-shared
dynamically assigned address. The IKE responder (gateway) needs to keys for Phase I authentication) cannot be used on a remote host with
a dynamically assigned address. The IKE responder (gateway) needs to
look up the initaitor's (mobile node's) pre-shared key before it can look up the initaitor's (mobile node's) pre-shared key before it can
decrypt the latter's third main mode message (fifth overall in Phase decrypt the latter's third main mode message (fifth overall in Phase
I). Since the initiator's identity is contained in the encrypted I). Since the initiator's identity is contained in the encrypted
message, only its IP address is available for lookup and must be message, only its IP address is available for lookup and must be
predictable. Other Phase I combinations, such as Main mode with predictable. Other options, such as Main mode with digital
digital signatures or Aggressive mode with pre-shared keys, are signatures/RSA encryption and Aggressive mode, can accomodate IKE
better suited for the situation at hand. peers with dynamically assigned addresses.
Agressive mode is vulnerale to a denial-of-service (DOS) attack since
it requires the receiver to perform a costly Diffie-Hellman
computation before the sender has been authenticated. The use of
digital signatures or RSA encryption with Main mode requires that
certificates be issued and distributed to IKE entities. Deploying a
PKI in a closed system (like the one targetted here) requires only a
modest effort which is well worth the extra security offered by
certificate-based schemes over passphrase/password based mechanisms.
Still, some may view the effort as prohibitive. A new Phase I
exchange, called Base Mode [DaBi99] has been proposed for deployment
situations that need preshared-key based authentication but where the
DOS vulnerability of Aggressive mode is considered unacceptable. This
is achieved by sacrificing identity protection available with Main
mode.
Private addresses within the protected network are accommodated by: Private addresses within the protected network are accommodated by:
(a) Using a bi-directional IPSec tunnel between R_e and G_e so (a) Using a bi-directional IPSec tunnel between R_e and G_e so
internal addresses (e.g. H) are hidden from routers on the internal addresses (e.g. H) are hidden from routers on the
Internet, and Internet, and
(b) Mapping the remote host to an "internal presence" so that (b) Mapping the remote host to an "internal presence" so that
routers and hosts within the protected network perceive all routers and hosts within the protected network perceive all
communication as originating from and terminating at an communication as originating from and terminating at an
skipping to change at page 7, line 7 skipping to change at page 7, line 35
through default routing). Applications such as NFS through default routing). Applications such as NFS
use IP addresses for access control and internal NFS use IP addresses for access control and internal NFS
servers may have to be reconfigured to respond to servers may have to be reconfigured to respond to
external addresses.] external addresses.]
There are two ways to map a remote host to an "internal There are two ways to map a remote host to an "internal
presence". presence".
(i) Network Address and Port Translation (NAPT) (i) Network Address and Port Translation (NAPT)
After verifying an incoming packet's source, After verifying an incoming packet's source,
decrypting its payload and removing the tunnel decrypting its payload and removing the tunnel
header, the IPSec gateway overwrites the source header, the IPSec gateway overwrites the source
R_e with G_i. Since multiple remote hosts may be R_e with G_i. Since multiple remote hosts may be
simultaneously connected to the protected network simultaneously connected to the protected network
via G, additional state (e.g. UDP/TCP port via G, additional state (e.g. UDP/TCP port
information or ICMP sequence numbers) is maintained information or ICMP sequence numbers) is maintained
and used for demultiplexing responses returned to and used for demultiplexing responses returned to
G_i. It is also possible to use a range of internal G_i. It is also possible to use a range of internal
addresses (rather than G_i alone) for NAPT. Details addresses (rather than G_i alone) for NAPT. Details
of the translation process are described in [SrEg98]. of the translation process are described in [SrEg98].
skipping to change at page 7, line 39 skipping to change at page 8, line 18
within the protected network. This packet can be within the protected network. This packet can be
forwarded to H without any address/port translation. forwarded to H without any address/port translation.
Unlike the NAPT-based approach, this one requires a Unlike the NAPT-based approach, this one requires a
pool of internal addresses to be set aside for pool of internal addresses to be set aside for
remote hosts. The size of this pool must be as large remote hosts. The size of this pool must be as large
as the number of simultaneously supported remote as the number of simultaneously supported remote
users (similar to what is done for conventional PPP- users (similar to what is done for conventional PPP-
based access). Within the protected network, G must based access). Within the protected network, G must
advertise reachability to these addresses. advertise reachability to these addresses.
Packet formats corresponding to these two approaches are Packet formats corresponding to these two approaches are shown in
shown in Appendix A and Appendix B, respectively. The Appendix A and Appendix B, respectively. The first approach requires
first approach requires fewer infrastructure changes but fewer infrastructure changes but NAPT can break certain applications
NAPT can break certain applications (see [HoSr99] and (see [HoSr99] and Appendix C) causing them to fail silently (and
Appendix C). However, early experience indicates that mysteriously from a naive user's perspective). The second approach is
enough applications can be supported to make this a useful more general and preferable over the first even though it requires
alternative. The second approach is more general but additional mechanisms so remote hosts can acquire temporary internal
requires additional mechanisms so remote hosts can acquire addresses and other configuration information.
temporary internal addresses and other configuration
information. The next section explores two possible
alternatives for acquiring such information.
4. Alternatives for Obtaining "Internal" Network Information: 4. Alternatives for Obtaining "Internal" Network Information:
Presently, there are two proposals for letting a remote host obtain Presently, there are two proposals for letting a remote host obtain
configuration information corresponding to its virtual presence on configuration information corresponding to its virtual presence on
the internal network (the Intranet in our previous example). This the internal network (the Intranet in our previous example). This
section presents high-level overview of each proposal and discusses section presents high-level overview of each proposal and discusses
their tradeoffs. Operational details on each proposal are available their tradeoffs. Operational details on each proposal are available
in [Pate98] and [PeAP98]. in [PAKG99] and [PeAP99].
4.1 The ISAKMP Configuration Method 4.1 The ISAKMP Configuration Method
The internet draft [PeAP98] proposes a new ISAKMP exchange that may The internet draft [PeAP99] proposes a new ISAKMP exchange that may
be used to "push" or "pull" configuration information such as an IP be used to "push" or "pull" configuration information such as an IP
address, a netmask, a DNS server, a DHCP server among others. The address, a netmask, a DNS server, a DHCP server among others. The
mechanism is extensible and can be extended to communicate arbitrary mechanism is extensible and can be extended to communicate arbitrary
configuration options. configuration options.
With this approach, a remote host, R, connected to the Internet would With this approach, a remote host, R, connected to the Internet would
go through the following steps in establishing a secure, virtual, go through the following steps in establishing a secure, virtual,
presence on a private network hidden from the general Internet behind presence on a private network hidden from the general Internet behind
an IPSec gateway, G. an IPSec gateway, G.
skipping to change at page 9, line 19 skipping to change at page 9, line 43
approach is that R can no longer view IDcr as an accurate approach is that R can no longer view IDcr as an accurate
representation of all the nodes it can communicate with representation of all the nodes it can communicate with
successfully.] successfully.]
4. Once the appropriate set of Phase II security associations 4. Once the appropriate set of Phase II security associations
has been established, R can exchange traffic with internal has been established, R can exchange traffic with internal
hosts using the packet formats shown in Appendix B. hosts using the packet formats shown in Appendix B.
4.2 Dynamic VPN Configuration using DHCP 4.2 Dynamic VPN Configuration using DHCP
Another alternative which is described in [Pate98] suggests that the Another alternative which is described in [PAKG99] suggests that the
remote host reuse DHCP to obtain all necessary configuration remote host reuse DHCP to obtain all necessary configuration
information. DHCP [Drom97] provides an extensible framework for information. DHCP [Drom97] provides an extensible framework for
passing configuration information to hosts on a TCP/IP network. passing configuration information to hosts on a TCP/IP network.
With this approach, a remote host, R, connected to the Internet would With this approach, a remote host, R, connected to the Internet would
go through the following steps in establishing an on-demand VPN. go through the following steps in establishing an on-demand VPN.
1. [Same as Step 1 in Section 4.1] 1. [Same as Step 1 in Section 4.1]
2. R uses a Phase II (Quick Mode) exchange to establish a 2. R uses a Phase II (Quick Mode) exchange to establish a
tunnel mode security association which would be used to tunnel mode security association which would be used to
carry DHCP traffic between R and a DHCP server on the carry DHCP traffic between R and a DHCP server on the
private network. private network.
3. R acquires an internal address R_i and related configuration 3. R acquires an internal address R_i and related configuration
parameters through DHCP. parameters through DHCP.
4a. [Same as Step 3 in Section 4.1] 4a. [Same as Step 3 in Section 4.1]
4b. The DHCP security association is no longer needed and 4b. The DHCP security association is no longer needed and
may be destroyed at this point. may be destroyed at this point.
5. [Same as Step 4 in Section 4.1] 5. [Same as Step 4 in Section 4.1]
4.3 A Comparison of the two Approaches: 4.3 A Comparison of the two Approaches:
Neither approach has a clear advantage over the other. The DHCP The DHCP approach is attractive because it reuses an existing
approach is attractive because it reuses an existing protocol rather protocol rather than add further complexity to IKE. However, it does
than add further complexity to IKE. However, it does require an require an additional Phase II exchange (in Step 2) for establishing
additional Phase II exchange (in Step 2) for establishing a DHCP a DHCP security association which is discarded soon thereafter. While
security association which is discarded soon thereafter. While the the IKE configuration exchange takes one roundtrip (and involves two
IKE configuration exchange takes one roundtrip (and involves two
messages -- REQUEST, REPLY), DHCP negotiation may require upto two messages -- REQUEST, REPLY), DHCP negotiation may require upto two
roundtrips (and four messages -- DHCPDISCOVER, DHCPOFFER, DHCPREQUEST roundtrips (and four messages -- DHCPDISCOVER, DHCPOFFER, DHCPREQUEST
and DHCPACK). and DHCPACK).
The IPSec for Remote Access [IPSRA] group (this is currently not a The IPSec for Remote Access [IPSRA] group (this is currently not a
formal IETF working group) has not yet reached a decision as to which formal IETF working group) has not yet reached a decision as to which
of these approaches will be stadardized. Each solution is being of these approaches will be stadardized. Each solution is being
prototyped by one or more vendors. prototyped by one or more vendors.
5. Security Considerations: 5. Security Considerations:
skipping to change at page 11, line 20 skipping to change at page 11, line 42
Internet (e.g. the CNN website or the Intuit stock server) is always Internet (e.g. the CNN website or the Intuit stock server) is always
directed through G (Figure 1). This indirection is likely to have an directed through G (Figure 1). This indirection is likely to have an
adverse impact on performance but may be attractive to security adverse impact on performance but may be attractive to security
administrators since it gives G greater control over policy administrators since it gives G greater control over policy
enforcement. Some special situations may require R to exchange enforcement. Some special situations may require R to exchange
traffic with another host without going through G. For example, if an traffic with another host without going through G. For example, if an
ISP uses DHCP for address allocation and lease renewals, the remote ISP uses DHCP for address allocation and lease renewals, the remote
host must be allowed to exchange DHCP traffic directly with its DHCP host must be allowed to exchange DHCP traffic directly with its DHCP
server. server.
Any secret authenticators (such as a pre-shared key or a private Any secret authenticators (such as an pre-shared key or a private
DSA/RSA key) used in IKE Phase I must not be stored in the clear on DSA/RSA key) used in IKE Phase I must not be stored in the clear on
the remote host. This provision is necessary to minimize the chance the remote host. Unless user input is required to provide the remote
of a security breach if the remote host is stolen. Some host's IKE daemon with access to this authenticator, only the device,
implementations may decide to store this information in encrypted not the user, is authenticated. This increases the chance of a
form protected by a password. Others may store sensitive information security breach should the device be lost or stolen. User input may
on removable media like smartcards. take several forms. Some implementations may choose to store the
authenticator information in encrypted form protected by a password.
Others may require sensitive information be stored on removable media
like smartcards which the user could carry separately from the
portable computer. There is also interest within the IPSec community
to support the use of legacy mechanisms like SecureID or Enigma token
cards for user authentication [KeKA99], [PeBe99].
5. Other Issues: 6. Other Issues:
In most instances, host names within the protected network would not In most instances, host names within the protected network would not
be known to external DNS resolvers. In such a situation, the remote be known to external DNS resolvers. In such a situation, the remote
host must direct all DNS queries to an appropriate resolver within host must direct all DNS queries to an appropriate resolver within
the protected network. The resolver's IP address may be manually the protected network. The resolver's IP address can be acquired as
configured or learned as part of the key negotiation process part of the configuration process described in Section 4. DNS traffic
[PeAP98]. DNS traffic (including internal host names) will be (including internal host names) will be automatically protected like
automatically protected like any other traffic to/from the protected any other traffic to/from the protected network. When the VPN is
network. terminated, the DNS configuration must be changed back to use the
ISP's DNS server reachable on the general Internet.
This note does not address how a remote host discovers the IPSec This note assumes that the remote host knows the IP address of the
gateway guarding its protected network. This information may be IPSec gateway guarding its protected network. This information may be
supplied by the remote user (our testbed uses manual configuration). supplied by the remote user via manual configuration or obtained
If the protected network does not use private addresses, the automatically from DNS through A, KX or SRV records.
gateway's IP address may be published through DNS [Atki97].
6. Acknowledgments 6. Acknowledgments
The author would like to thank Naganand Doraswamy, Gabriel The author would like to thank Naganand Doraswamy, Scott Kelly,
Montenegro, and Pyda Srisuresh for their feedback on an early version Gabriel Montenegro, and Pyda Srisuresh for their feedback on previous
of this document. versions of this document.
7. Revision History 7. Revision History
Version Date Comments Version Date Comments
------- ---- -------- ------- ---- --------
00 Jul 17, 1998 Created initial version. 00 Jul 17, 1998 Created initial version.
01 Nov 17, 1998 Added a reference to [Aziz98] in 01 Nov 17, 1998 Added a reference to [Aziz98] in
Section 1.1. In Section 3, added Section 1.1. In Section 3, added
a brief discussion on the suitability a brief discussion on the suitability
skipping to change at page 12, line 26 skipping to change at page 13, line 4
Added Section 7 titled "Revision Added Section 7 titled "Revision
History". History".
02 Jun 7, 1999 Added a new section (Section 4) to 02 Jun 7, 1999 Added a new section (Section 4) to
discuss available alternatives for discuss available alternatives for
configuring the remote host. Added configuring the remote host. Added
text in Section 2 to emphasize the text in Section 2 to emphasize the
importance of a trust model that does importance of a trust model that does
not require trusting the Internet not require trusting the Internet
service provider. Updated references. service provider. Updated references.
03 Oct 22, 1999 Added a disussion on Base mode and
the need to authenticate users rather
than portable devices. Several
additional updates/clarifications.
References References
[Atki97] R. Atkinson, "Key Exchange Delegation Record for the [Atki97] R. Atkinson, "Key Exchange Delegation Record for the
DNS", RFC 2230, Nov. 1997. DNS", RFC 2230, Nov. 1997.
[Aziz98] A. Aziz, Personal communication. A writeup describing
a vulnerability in the use of passwords over HTTPS is
available at
http://playground.sun.com/~vgupta/browser-attack.html
[Dora97] N. Doraswamy, "Implementation of Virtual Private [Aziz98] A. Aziz, Personal communication.
Networks (VPNs) with IP Security", Internet draft <draft-
ietf-ipsec-vpn-00.txt>, work in progress, Mar. 1997 or its [DaBi99] Y. Dayan, S. Bitan, "IKE Base Mode", Internet draft
successor. <draft-ietf-ipsec-ike-base-mode-00.txt>, work in progress,
Jun. 1999 or its successor.
[GRIC] See http://www.gric.com/. [GRIC] See http://www.gric.com/.
[HaCa98] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", [HaCa98] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, Nov. 1998. RFC 2409, Nov. 1998.
[HLFT94] S. Hanks, T. Li, D. Farinacci, P. Traina, "Generic [HLFT94] S. Hanks, T. Li, D. Farinacci, P. Traina, "Generic
Routing Encapsulation (GRE)", RFC 1701, Oct. 1994. Routing Encapsulation (GRE)", RFC 1701, Oct. 1994.
[HoSr99] M. Holdrege, P. Srisuresh, "Protocol Complications [HoSr99] M. Holdrege, P. Srisuresh, "Protocol Complications
with the IP Network Address Translator (NAT)", Internet with the IP Network Address Translator (NAT)", Internet
draft <draft-ietf-nat-protocol-complications-00.txt>, draft <draft-ietf-nat-protocol-complications-00.txt>,
work in progress, Feb. 1999 or its successor. work in progress, Feb. 1999 or its successor.
[iPass] See http://www.ipass.com/. [iPass] See http://www.ipass.com/.
[KeKA99] S. Kelly, J. Knowles, B. Aboba, "User-level
Authentication Mechanism for IPSec", Internet draft <draft-
kelly-ipsra-userauth-00.txt>, work in progress, Oct. 1999
or its successor.
[KeAk98a] S. Kent and R. Atkinson, "Security Architecture for the [KeAk98a] S. Kent and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, Nov. 1998. Internet Protocol", RFC 2401, Nov. 1998.
[KeAk98b] S. Kent and R. Atkinson, "IP Authentication Header", [KeAk98b] S. Kent and R. Atkinson, "IP Authentication Header",
RFC 2401, Nov. 1998. RFC 2401, Nov. 1998.
[KeAk98c] S. Kent and R. Atkinson, "IP Encapsulating Security [KeAk98c] S. Kent and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, Nov. 1998. Payload (ESP)", RFC 2406, Nov. 1998.
[Mosk98] R. G. Moskowitz, "Network Address Translation issues [PAKG99] B. V. Patel, B. Aboba, S. Kelly and V. Gupta, "Dynamic
with IPsec", Internet draft <draft-moskowitz-net66-vpn- Configuration of IPSEC VPN host using DHCP", Internet draft
00.txt>, work in progress, Feb. 1998 or its successor. <draft-ietf-ipsec-dhcp-03.txt>, work in progress, Oct. 1999
or its successor.
[Pate98] B. V. Patel, "Dynamic Configuration of IPSEC VPN host
using DHCP", Internet draft <draft-ietf-ipsec-dhcp-01.txt>,
work in progress, Dec. 1998 or its successor.
[PeAP98] R. Pereira, S. Anand and B. Patel, "The ISAKMP [PeAP99] R. Pereira, S. Anand and B. Patel, "The ISAKMP
Configuration Method", Internet draft <draft-ietf-ipsec- Configuration Method", Internet draft <draft-ietf-ipsec-
isakmp-mode-cfg-04.txt>, work in progress, May. 1998 or isakmp-mode-cfg-05.txt>, work in progress, Aug. 1999 or
its successor. its successor.
[PeBe99] R. Pereira, S. Beaulieu, "Extended Authentication Within
ISAKMP/Oakley", Internet draft <draft-ietf-ipsec-isakmp-
xauth-05.txt>, work in progress, Sep. 1999 or its successor.
[SrEg98] P. Srisuresh and K. Egevang, "Traditional IP Network [SrEg98] P. Srisuresh and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", Internet draft Address Translator (Traditional NAT)", Internet draft
<draft-ietf-nat-traditional-01.txt>, work in progress, <draft-ietf-nat-traditional-01.txt>, work in progress,
Oct. 1998 or its successor. Oct. 1998 or its successor.
[VHRK98] A. Valencia et al., "Layer Two Tunneling Protocol [VHRK98] A. Valencia et al., "Layer Two Tunneling Protocol
(L2TP)", Internet draft <draft-ietf-pppext-l2tp-15.txt>, (L2TP)", Internet draft <draft-ietf-pppext-l2tp-15.txt>,
work in progress, May. 1999 or its successor. work in progress, May. 1999 or its successor.
[YlKS97] T. Ylonen, T. Kivinen, M, Saarinen, "SSH Protocol [YlKS97] T. Ylonen, T. Kivinen, M, Saarinen, "SSH Protocol
skipping to change at page 13, line 48 skipping to change at page 14, line 36
tecture-03.txt> work in progress, Feb. 1999 or its tecture-03.txt> work in progress, Feb. 1999 or its
successor. successor.
Author's Address Author's Address
Vipul Gupta Vipul Gupta
Sun Microsystems, Inc. Sun Microsystems, Inc.
901 San Antonio Rd. 901 San Antonio Rd.
Palo Alto, CA 94303 Palo Alto, CA 94303
Tel: (650) 786 3614 Tel: +1 650 786 3614
Fax: (650) 786 6445 Fax: +1 650 786 6445
EMail: vipul.gupta@eng.sun.com EMail: vipul.gupta@sun.com
APPENDIX A: NAPT hides the remote host's external address APPENDIX A: NAPT hides the remote host's external address
========================================================= =========================================================
This appendix presents the packet formats for traffic labeled This appendix presents the packet formats for traffic labeled
(a) through (d) (Figure 1) when a NAPT-based approach is used. (a) through (d) (Figure 1) when a NAPT-based approach is used.
The diagrams assume that a single address G_i (rather than The diagrams assume that a single address G_i (rather than
an address range) is used to hide external addresses. ESP with an address range) is used to hide external addresses. ESP with
authentication is used to secure traffic across the Internet. authentication is used to secure traffic across the Internet.
For (a) and (b), the packet head is shown to the right. For (c) For (a) and (b), the packet head is shown to the right. For (c)
and (d), the packet head is shown to the left to match the flow and (d), the packet head is shown to the left to match the flow
 End of changes. 29 change blocks. 
81 lines changed or deleted 107 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/