|
|
CiscoSecure Global Roaming Server (GRS) supports proxy and translation of Virtual Private Dial-Up Network (VPDN) requests. There are two basic types of "roaming" users: Internet and intranet; VPDN addresses the requirements of roaming intranet users. If the access control servers (ACSes) involved use different authentication, authorization, and accounting (AAA) protocols, both proxy and translation are required. This chapter provides information about the VPDN process and how it affects the operation of CiscoSecure GRS.
This section describes the steps for processing VPDN requests in a standard environment.
1. A VPDN user dials in to the network access server (NAS). The standard call/Point-to-Point Protocol (PPP) setup is done. A username and password are sent to the NAS in the format username@domain (for example, mary@corporation.us). (See Figure 5-1).
2. If VPDN is enabled, the NAS will assume that the user is a VPDN user. The NAS strips off the "username@" (mary@) portion of the username and authorizes (not authenticates) the domain portion (corporation.us) with the ACS. (See Figure 5-2.)
3. If the domain authorization fails, the NAS assumes the user is not a VPDN user. The NAS then authenticates (not authorizes) the user as if the user is a standard non-VPDN dial user. (See Figure 5-3.)
If the ACS authorizes the domain, it returns the tunnel ID and the IP address of the home gateway (HG); these are used to create the tunnel. (See Figure 5-4.)
4. The HG uses its ACS to authenticate the tunnel, where the username is the name of the tunnel (nas_tun). (See Figure 5-5.)
5. The HG now authenticates the tunnel with the NAS, where the username is the name of the HG. This name is chosen based on the name of the tunnel, so the HG might have different names depending on the tunnel being set up. (See Figure 5-6.)
6. The NAS now uses its ACS to authenticate the tunnel from the HG. (See Figure 5-7.)
7. After authenticating, the tunnel is established. Now the actual user (mary@corporation.us) must be authenticated. (See Figure 5-8.)
8. The HG now authenticates the user as if the user dialed directly in to the HG. The HG might now challenge the user for a password. The NAS does not strip off the @ and domain before it passes the authentication to the HG. (The user is passed as mary@corporation.us.) The HG uses its ACS to authenticate the user. (See Figure 5-9.)
9. If another user (sue@corporation.us) dials in to the NAS while the tunnel is up, the NAS does not repeat the entire authorization/authentication process. Instead, it passes the user through the existing tunnel to the HG. (See Figure 5-10.)
In some VPDN cases, both proxy and translation are required in VPDN environments. This section describes these cases and identifies the features of CiscoSecure GRS that support these solutions.
To explain how VPDN and proxy are used together, this section shows how the regional service provider (RSP) and the Internet service provider (ISP) can use CiscoSecure GRS to provide roaming for the corporation's users. In the following example, Corporation requires roaming users to have their usernames in the format username=name@domain (for example, mary@corporation) or username=name@domain.home_country (for example, mary@corporation.us). The RSP's CiscoSecure GRS proxies all requests ending in .us to the ISP's ACS; matching information is stripped.
Step 1 The user (mary@corporation.us) dials in to the NAS. (See Figure 5-11.)
Step 2 The NAS tries to authorize the domain with CiscoSecure GRS. The RSP's NASes have been configured to send all AAA requests to their CiscoSecure GRS. When one of the RSP's NASes receives the call, it recognizes the user as a VPDN user and sends an authorization request to the RSP's CiscoSecure GRS (username=corporation.us). (See Figure 5-12.)
Step 3 CiscoSecure GRS parses the username and matches the .us. The RSP's CiscoSecure GRS proxies the authorization request to the ISP's ACS, stripping off the .us. The authorization request is in the form username=corporation. (See Figure 5-13.)
Step 4 The ISP's ACS authorizes the domain as if it is a local tunnel. The ACS responds with the tunnel ID and IP address of the HG. CiscoSecure GRS forwards the authorization reply to the NAS. (See Figure 5-14.)
Step 5 Using the information provided by CiscoSecure GRS, the RSP's NAS now creates the tunnel and authenticates it with the RSP's HG. (See Figure 5-15.)
Step 6 The RSP's HG authenticates the tunnel using its local ACS and sends back a Challenge Handshake Authentication Protocol (CHAP) response. (See Figure 5-16.)
Step 7 The RSP's NAS now sends the CHAP response to CiscoSecure GRS. CiscoSecure GRS receives the authentication request as username=nas@corporation.us. CiscoSecure GRS matches the .us, strips it off, and proxies the request to the ISP's ACS. (See Figure 5-17.)
Step 8 The HG now uses a CHAP challenge to authenticate the tunnel. (See Figure 5-18.)
Step 9 The RSP's CiscoSecure GRS receives the authentication request username=HG@corporation.us. The RSP's CiscoSecure GRS matches the .us, strips it, and proxies the request. (See Figure 5-19.)
Step 10 The RSP's CiscoSecure GRS responds to the NAS, which sends the CHAP response to the HG. When the HG authenticates the CHAP response, the tunnel is built. (See Figure 5-20.)
Step 11 The HG now uses its ACS to authenticate the user as if the user dialed in locally. (See Figure 5-21.)
Posted: Wed Feb 24 12:12:57 PST 1999
Copyright 1989-1999©Cisco Systems Inc.