Electrical computers and digital processing systems: multicomput – Computer network managing – Computer network access regulating
Reexamination Certificate
1999-05-06
2002-10-15
Burgess, Glenton B. (Department: 2153)
Electrical computers and digital processing systems: multicomput
Computer network managing
Computer network access regulating
C709S223000, C709S224000, C709S229000, C709S239000, C713S152000
Reexamination Certificate
active
06466977
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 providing proxied authentication, authorization and accounting on demand 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 wholesale Internet access and retail Internet access to their subscribers. Wholesale access is typically offered 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 Wholesaler. 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 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).
See, for example,
FIG. 1
where a pure retail environment has a number of network access servers (NAS
1
, NAS
2
and NAS
3
) which provide data communications portals to the Wholesaler's point of presence (PoP) on the data communications network. Each NAS is in communication with a conventional AAA (authentication, authorization and accounting) service maintained by the Wholesaler. Incoming users connect to the NASes by dialing in over the telephone network or in another conventional manner such as via DSL (digital subscriber line) access, cable, ISDN (integrated services digital network, etc.).
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 digital number identification service identification (“DNIS ID”) associated with the call, reading the calling line identification (“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. The DNIS ID is the telephone number of the completing station. 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 tying 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
14
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 stored as illustrated in FIG.
3
.
For example, turning now to
FIG. 2
, user Joe@corpa.com dials in to NAS
1
. A PPP (point to point protocol) session
10
is typically raised between Joe's terminal and NAS
1
. An LCP (Link Control Protocol) session
12
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 Wholesaler's proxy service
14
. Proxy service
14
then consults its local configuration database
16
which contains information like that outlined in FIG.
3
. Proxy service
14
then makes a determination about where to send the authentication request (Access-Request in RADIUS) packet. At this time, the proxy service decides to forward the authentication request to the AAA service
18
maintained in the Corp
A
domain
20
. The Corp
A
AAA
18
then consults its local database
22
and authenticates Joe@corpa.com. Corp
A
AAA
18
then returns an access-accept packet to proxy service
14
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 completing the log-in of Joe@corpa.com.
Turning now in more detail to
FIG. 3
the proxy service's database includes a table containing for each entry a domain to be proxied to, i.e., the domain of Corp
A
, Corp
B
, etc. Associated with each domain entry is a single AAA IP address that identifies the IP address of the AAA service to use at the specified domain. Associated with each AAA IP address is an IP Layer 4 port number (or some other indicator) identifying the port number on which the domain's AAA service is listening to authentication (such as the RADIUS protocol) requests. Finally, for each entry a shared secret is stored which is used to hash (encode and decode) the packets being sent to the domain's AAA service.
This approach has a number of drawbacks. First, the Wholesaler is unable to load balance among a number of instances of an AAA service at the domain. This is in part because it only knows of one AAA at the domain. Second, the Wholesaler is unable to detect or respond to problems at the domain's AAA service. Third, if the domain's AAA service becomes unavailable, no one entering the Wholesaler and requiring the use of that domain can log-in because of the authentication and authorization service outage. Fourth, if the domain's AAA service becomes over-used and too busy, users cannot log-in with the Wholesaler or may experience delays. Furthermore, this approach offers no practical mechanism whereby a Wholesaler can switch service component
Alesso Craig Michael
Sitaraman Aravind
Yager Charles Troper
Burgess Glenton B.
Ritchie David B.
Salad Abdullahi E.
Thelen Reid & Priest LLP
LandOfFree
Proxy on demand does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Proxy on demand, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Proxy on demand will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2946184