Virtual private data network session count limitation

Details Virtual private data network session count limitation Virtual private data network session count limitation

1999-05-06

2002-08-06

Etienne, Ario (Department: 2153)

Electrical computers and digital processing systems: multicomput

Computer network managing

Computer network access regulating

C709S229000, C709S226000, C709S217000

Reexamination Certificate

active

06430619

ABSTRACT:

BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to the field of data communications networks. More particularly, this invention relates to a method and apparatus for limiting the number of virtual private data network (VPN or VPDN) sessions provided to a group of users locally and network-wide in a data communications network.
2. The Background
ISPs (Internet Service Providers) and Telcos (telephone companies) (collectively referred to as “Wholesale Providers” or “Wholesalers”) typically offer various forms of retail Internet access to their subscribers. In a typical retail model as shown in
FIG. 1
, a user will contact a network access server (NAS) either using dial-up telephone lines, digital subscriber lines, ISDN (integrated services digital network) lines, or the like. The NAS interfaces the user with the data communications network. The way this works is that a user, for example, Joe@corpa.com, dials in to a NAS at ISP's Point of Presence (PoP
1
) on the Internet. A PPP (point to point protocol) session
12
is raised between NAS
1
14
, and Joe's terminal
16
. An LCP (Link Control Protocol) session is raised between NAS
1
and Joe's terminal. At this time the NAS
1
generates an AAA authentication request using a protocol such as RADIUS (Remote Authentication Dial-In User Service) to the ISPs AAA (authentication, authorization and accounting) service
20
. The AAA service
20
handle Joe's authentication (receipt and verification of password and user name), provisions him with appropriate authorizations, and handles accounting for the time and services used by Joe on the data communications network. The AAA service uses a local database
22
to store and retrieve AAA information. To complete Joe's log-in, an access-accept packet is sent to NAS
1
from AAA service
20
. Then an IPCP (Internet Protocol Control Protocol) session is raised between NAS
1
and Joe's terminal during which an IP address is returned to configure Joe's terminal's PPP stack. This completes the log-in of Joe.
Wholesale Providers also offer wholesale internet access to subsidiary and specialized service providers, CLECs (Competitive Local Exchange Carriers), corporations, and Community of Interest (COI) providers. Naturally, the processing afforded customers of the wholesale variety differs from the processing afforded customers of the retail variety. Subscriber information for individual wholesale users is usually stored by those who lease data communications network access from the ISP or Telco. Hence, corporations, CLECs and COI providers do not normally share their user information with the wholesale providers. The Wholesaler, however, typically also has its own retail subscribers whose user information is stored in its databases. In some cases, a particular user might have accounts with both a retail and a wholesale provider. Hence, the Wholesaler must distinguish between the user's wholesale and retail accounts and initiate different actions based upon their status or Service Level Agreements (SLAs).
Traditional wholesale ISPs and Roaming Service Providers offer network access through a technique called “authentication proxying.” Proxying involves the transfer of the authentication responsibility to the “owner” of the subscriber. Thus, if a corporation was to outsource its corporate intranet to a Wholesaler, it would give up the maintenance of its dial-up servers (i.e., the NASes). It would not, however, normally want to give up the control of or information regarding its employees. Hence, when a corporate user connects to such a Wholesaler's network access servers, the user essentially perceives that the user is dialing into a corporate facility when the user is actually dialing into the Wholesaler's domain and then somehow gaining admittance to the corporation's intranet.
What really happens in that scenario is that the Wholesaler determines that the user belongs to Corporation A (Corp
A
) by parsing either the fully qualified domain name (“FQDN”) (e.g., Joe@corpa.com) supplied by the user, reading the DNIS ID associated with the call, reading the CLID associated with the call, or by using some other known mechanism. Using a DNIS ID, the Wholesaler looks at the telephone number (or a specific NAS in access networks other than dial-up) through which the user is connecting to the network. So if a user calls in to 123-456-7890 from his number of 123-444-5555, then the Wholesaler can know which number was called, i.e., the completing station. Having determined that the user trying to gain access belongs to Corp
A
, the Wholesaler cannot authenticate the user by itself. As noted earlier, the user's record is still located on Corp
A
's equipment. Hence, the Wholesaler will “proxy” out the authentication transaction from its AAA proxy service to Corp
A
. An AAA service within the corporation domain then identifies the user, verifies the password, and provisions the user with appropriate authorizations. It may also receive accounting information, if desired. Then the AAA service at Corp
A
notifies the Wholesaler's proxy service that the user is acceptable and passes along provisioning details associated with the user (such as an IP (Internet protocol) address to use or a pool identification of an IP address pool from which an IP address needs to be allocated and any other information that may be needed). The Wholesaler then grants the user access to the network based upon the reply it gets back from Corp
A
. This technique is called “proxying.” This is shown diagrammatically in FIG.
2
.
To be able to perform basic proxying, the Wholesaler maintains minimal information on its proxy service
24
at its PoP. Information such as supported domain names, the IP address to which the transaction is to be sent, the port number (typically an OSI Layer
4
port number) to which the transaction is to be addressed, a shared secret between the proxy service and the remote AAA service, etc., are typically stored on proxy service
24
's local configuration database
30
.
For example, user Joe@corpa.com dials in to NAS
1
. A PPP (point to point protocol) session
26
is typically raised between Joe's terminal and NAS
1
as is a LCP (Link Control Protocol) session. At this time the NAS
1
generates an authentication request using a protocol such as RADIUS (Remote Authentication Dial-In User Service) to proxy service
24
. Proxy service
24
then consults its local configuration database
30
. Proxy service
24
then makes a determination about where to send the access-request packet. Here it decides to send it to the AAA service
32
maintained in the Corp
A
domain
34
. The Corp
A
AAA
32
then consults its local database
36
and authenticates Joe@corpa.com. Corp
A
AAA
32
then returns an access-accept packet to proxy service
24
which, in turn, sends an access-accept packet to NAS
1
. Then an IPCP (Internet Protocol Control Protocol) session is raised between NAS
1
and Joe's terminal during which an IP address is returned to configure Joe's terminal's PPP stack thus completing the log-in of Joe@Corpa.com.
Frequently a large corporation or similar entity will have a need to provide PoPs at a number of locations to service its clients, customers and/or employees in a number of different cities. For example, a corporation “Corp
A
” located in Los Angeles, Calif. might have some employees using dial-up lines from San Francisco, Calif. and New York City, N.Y. Particularly in this situation, and in other situations, it is frequently desirable to establish a secure virtual private network (VPN) session which uses a tunneling protocol such as L2TP (layer two tunneling protocol) to effectively direct the communications from one node on the Internet to another node on the Internet. Communications using these techniques are particularly secure because the entire packet is encapsulated by the protocol and within the encapsulation the data is encr

Affiliated with

Also associated with

Rating

Virtual private data network session count limitation does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Virtual private data network session count limitation, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Virtual private data network session count limitation will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-2947599