Does your ISPs AAA server system stink? If you've already solidified authentication in your AAA server—why not consolidate concurrency control there as well?

by Lisa Phifer Core Competence, Inc. [April 11, 2001]

ISPs have long used AAA servers from Funk, Ascend, Livingston, and others to Authenticate, Authorize, and Account for network access. Most AAA servers use the Remote Authentication Dial-In User Service (RADIUS) protocol to interface with a wide variety of edge devices, including remote access servers (RAS), network access servers (NAS), firewalls, and Virtual Private Network (VPN) gateways.

Whenever a user tries to log on, the edge device consults the AAA server to validate the user's credentials, permit or deny the connection, and supply parameters like an IP address. AAA servers authenticate against a local user database or consult back-end services like Lightweight Directory Access Protocol (LDAP), Terminal Access Controller Access Control System (TACACS+), Windows domain controllers, NetWare NDS, UNIX NIS, and ACE/Servers. When the connection ends, the edge device notifies the AAA server, which logs start and end times for accounting or metered billing purposes.

The problem—double dipping
AAA servers allow ISPs to control and track whose accessing your network, but they typically do not enforce connection limits. All-you-can-eat Internet access for $15 a month may assume a single active connection, but can your ISPs AAA servers prevent these accounts from being shared? Your ISDN Internet access package might include 100 hours each month, but can your ISP disconnect the user when hour 100:01 starts? A small business Internet bundle may support 10 users, but can your ISP enforce this limit using an inexpensive RAS, PAP/CHAP, and a single username/password for the entire company?

Some edge devices can be configured to enforce concurrency limits—for example, a VPN gateway that permits just one remote client per tunnel. Enforcing cumulative connect time thresholds at NAS or RAS is less common—you may deny the next connect attempt, but can you prevent users from simply staying connected, around the clock? Furthermore, consistent enforcement at the edge can be difficult if you've deployed many different kinds of access servers. You've consolidated authentication in your AAA server—why not consolidate concurrency control there as well?

One solution—Funk's concurrency server
This is the problem that Funk Software hopes to solve with their new Concurrency Server. This product can be deployed as an add-on to Funk's popular Steel-Belted Radius/Service Provide Edition (SBR/SPE). It can also be integrated with other-vendor AAA servers adapted to use Funk's published interface.

Funk's Concurrency Server is designed to reduce connection abuse, log the information needed to convert abusers into paying customers, and enable new "group plan" revenue opportunities. It accomplishes this by stepping into the middle of normal AAA server processing. After an AAA server authenticates a user—but before it responds to the edge device—the AAA server forwards the request to the Concurrency Server. The Concurrency Server tracks current connections and uses this information to permit or deny access.

Why not just enforce concurrency on the AAA server? Most AAA servers can enforce connection limits. But, for reliability and scalability reasons, most ISP networks have more than one AAA server. When authentication is being performed simultaneously by several AAA servers, a single point of control is required to manage concurrency across those servers.

Once you've consolidated account information in one database, you don't want to replicate it elsewhere. There is no need to configure the Concurrency Server with account-specific data because it operates on parameters supplied by the AAA server. Funk's SBR/SPE server can set concurrency limits in several ways—by port type (analog = 1, ISDN = 2), individual user, group, or service profile.

ISPs can leverage Funk's Concurrency Server to offer new services with custom thresholds. For example, create a "family plan" profile that allows four concurrent connections. Or create corporate plans that enforce per-company or per-site limits. Information logged by the Concurrency Server can target accounts ripe for upgrade. Residential users may not realize that they're stealing service when double dipping, and may pay incremental fees for this privilege. Corporate accounts can be invoiced by monthly high-water marks—a simpler solution than detailed per-connection billing.

Measuring return on investment
At a starting price of $37,500, Funk's Concurrency Server isn't cheap. The software runs on Solaris 2.6/7/8 or Windows NT4/2000, but requires a hearty engine—Funk recommends a platform with four processors. Connection records can be logged to a file, but anyone relying on this for billing will use an SQL database.

Is this investment really worthwhile? Funk argues that ISPs under-estimate both the extent and cost of concurrency abuse. They say that early adopters are reporting abuse rates that double pre-deployment estimates. Abuse increases operational cost by inflating port, server, and bandwidth utilization. By reporting usage accurately, ISPs can eliminate lost revenue, convert some portion of abuse into new revenue, and boost their business valuation.

Funk published an analysis demonstrating potential incremental profits. For example, consider an ISP with 50,000 users, each paying $20 a month, at an operation cost of $15 a month. If abuse runs at 10 percent, or at $10 a user each month, this ISP is losing at least $50,000 a month. But concurrency control will not eliminate abuse—it will only reduce it. Assuming that 25 percent of abuse is prevented and 10 percent is converted to "group plan" revenue, Funk estimates an increased profit of $20,000 a month. Using the same parameters, an ISP with 500,000 users can boost profit $200,000 a month—and so on.

One expects a vendor-supplied analysis to yield a positive ROI. But Funk's estimates are not outlandish. In fact, they're pretty conservative. In this example, the Concurrency Server pays for itself in two or three months. The smaller the subscriber base, the longer ROI takes. For larger ISPs, these numbers are compelling. To plug in your own numbers, download Funk's spreadsheet and see for yourself.

Go to page 2: One Satisfied Customer >