Alan DeKok's RADIUS Blog

I came across the following paper recently. Titled in part One Size Fits All?, it shows how text processing benefits enormously from the use of specialized databases. They compare the performance of standard relational databases (RBMS) with the performance of systems designed to solve specific problems. They convincingly demonstrate that specialized systems can easily obtain two orders of magnitute better performance than RDBMS.

The reasons have to do with careful design, and choosing the right tool for the job. RDBMS are designed to do a number of things very well, but they're not spectacular at solving any one problem. If you want to quickly prototype a system, RDBMS are a good choice. But if you want a fast system, it's best to pay close attention to the design of the system.

The same design methods apply in the RADIUS space, too. It's easy to set up a RADIUS server that uses an SQL database to store authorization rules and accounting data. It's much more difficult to build a system that has the same functionality, but scales to 100 times the load of a “simple” design. But as my previous post showed, FreeRADIUS has (of course) no problem being part of such a system.

The testimonials page on the main FreeRADIUS web site contains an example of a carrier-class deployment of the server. Other large deployments of the server exist, of course, but this one was willing to publicise their use of FreeRADIUS.

From what they say, it looks like they have hundreds, if not thousands of devices at the edge. They have many machines at the core, all running FreeRADIUS and MySQL as application servers. They use LVS to do load balancing and failover. In short, they've built a system that handle thousands of sustained reads and writes per second, with near 100% uptime. Any piece can be upgraded while the system is “live”, without affecting uptime or stability.

That's a cool architecture, and from what else they've said, they don't seem to spend much time maintaining it. It Just Works.

While the server is a great product, it fails on a number of accounts. Documentation is a popular choice, but I don't think that's the worst of its problems.

The worst problem is that it works.

Yes, I know a lot of people on the users list will disagree with me, especially the ones who are fighting with the previously mentioned lack of documentation. But given recent statistics, the few people every day who discuss their problems are about 0.1% of the install base. The rest of the users (for the most part) install it without major grinding of teeth, and then proceed to forget about it. They manage their users in an SQL or LDAP database, and don't really change the server configuration. Ever.

They don't change it because it just works. That's what software should do.

This means the project is a commercial failure, because it's difficult to sell costly support, upgrades, or other commercial value-adds when the customer is content with what they have. That's fine, because there are a good number of commercial RADIUS products based on FreeRADIUS. This means that even if you're paying for a RADIUS server, the odds are pretty good that if it's not IAS or ACS, it's a rebranded FreeRADIUS.

That's a successful commercial product.

I'm not done the book yet, so this blog may be a little premature. Still, I've learned a lot from what I've written so far. The main one is that the hardest part of the book is simply finding the time to write it.

The next hardest part is figuring out how to organize it. But I've solved that problem, I think. My solution is to concentrate on writing the contents first, even if that means the drafts look like a random collection of notes. As the notes get fleshed out into paragraphs, sections, and chapters, the organization grows naturally.

As of this writing, I'm up to 60 pages, and I have only about 5 pages that are specific to FreeRADIUS. Just explaining the concepts behind RADIUS, and correcting common misconceptions is taking a fair amount of space. That's good, though. It means that that the rest of the book is built on those foundations, and isn't just a jumble of “how-to's”.

The finished book will have a number of “how-to's”, of course. But without the additional background materials, they help people copy configurations, which is not the same as helping them to solve problems.

When I started FreeRADIUS, there were a few open source RADIUS servers in development. Yet a few years later, almost all of them are not actively developed or maintained. What qualities did FreeRADIUS have that allowed it to succeed and grow, when many open source project stagnate?

I think it's because of the architecture. Not just of the software (though that helps), but of the larger social group surrounding it. The following qualities are vital to getting community involvement in an Open Source project:

1. Modularized code.
   Not only must the code be easy to understand, it must be easy to add new features. The pluggable module interface ensured that it was easy to add new modules. The benefit of the design was shown quickly, when many modules (LDAP, SQL, etc) were added quickly after the project started.
2. Fast acceptance of patches.
   There's nothing worse than submitting a patch for a bug fix or feature enhancement to an open source project, and having it ignored. It's discouraging, and usually means that you'll move your efforts to something that's more productive. In the end, the project loses, because it loses features and bug fixes that everyone needs.
3. Public mailing lists.
   Not only the “users” or “help” list has to be public, the developers list has to be public too. The developers have to be active on both lists, to help users, and to have public discussions about the design and direction of the project. A welcoming attitude to open discussion means that more people contribute, which means that the project gains the benefit of everyones expertise.
4. Public CVS repository and bug site.
   Allowing people to submit bugs and view the source code ensures that they can find out if other people have run into the same issues they see, and what the solutions are. People are more likely to use a piece of software if they see that it is under active development. They can use an unstable version from CVS to get the feature they need, which means thay don't use another piece of software.
5. Fast development.
   An incremental approach to development is better than the “big bang” approach. Don't underestimate the power of a series of small fixes. The small fixes means that the project almost always works, which means people use it and debug it. The small fixes also mean that new features are available quickly, which again means people use those features and debug them.

All of the items discussed above are important, but it's interesting what I left out: documentation. While documentation is useful, it doesn't help most developers, who are the ones driving bug fixes and new features. Documentation is useful to end users, of course, which is why I'm writing the book.

Finally, the items discussed above are all really variants of a common theme: Low barrier to entry. The easier it is to get work done, the more work people get done.

It's not rocket science, but it's amazing how many open source projects fail because the founders run the project with high barriers to entry.

The Enterprise Strategy Group recently came out with a white paper proposing an open supplicant initiative. This initiative would ideally have wide industry support from commercial organizations, and be based on an Open Source supplicant.

I think it's a great idea.

Cisco has their NAC solution, and Microsoft has NAP, both of which rely on endpoint software for network integrity. As single-vendor solutions are always a concern to some people, there is now a standards body called TNC that's doing something similar.

However, the TNC body doesn't currently have an open supplicant that everyone can use. This is where an open supplicant initiative comes in. The supplicant can implement TNC, and whatever else anyone needs, in an open and standards-based approach.

This is not to say anything bad about Cisco or Microsoft. Their solutions are very interesting and useful. But some people prefer a vendor-independent, and standards-based system to a single-vendor solution.

I think it's high time for an Open Source supplicant to have signficant commercial backing. I hope this effort takes off.

Apple has announced that they're including RADIUS in MAC OSX Leopard. The RADIUS server of choice is naturally FreeRADIUS.

I was given a preview of it at the recent Apple WWDC, and though I can't say much, I'm impressed. It's simple, clean, and solves the basic problems needed by many people who are deploying a RADIUS solution.

Not all of the servers configuration was exposed through the GUI, of course. Instead, the common use-cases were covered, while the potential still exists for creating more complex configurations by hand.

I know I'm excited to see the install base of FreeRADIUS double (or more). This means I'll probably have to include a chapter on Leopard in my book, which is a good thing.

I can't tell for sure, but there are a lot of people using FreeRADIUS. The main FreeRADIUS page says it's in the “top 5″ servers, but that's really a guess based on the following information:

RADIUS Server Software

• Cisco ACS
• Funk Steel Belted RADIUS
• Radiator
• FreeRADIUS
• other servers

Maybe the main web page needs updating. I can't think of other RADIUS servers that have as big a market share as the four listed above. And many commercial RADIUS products not listed above use FreeRADIUS as the protocol engine for their product.

In terms of cusomer base, I know of at least 4 deployments with 2 to 8 million users. I know of hundreds of small sites (universities, etc) with tens of thousands of users. Most sites won't let their names be used publicly (for a number of reasons), but if you're planning on deploying FreeRADIUS, you're not alone.

So FreeRADIUS looks to have a significant portion of the RADIUS server market. Without doing more detailed analysis, the best guess is that somewhere between 10% and 50% of RADIUS server installations world-wide are for FreeRADIUS. And with 802.1x deployments becoming ubiquitous, there are likely many, many more people installing FreeRADIUS in home networks with less than 10 users.

That's not bad for a software product with no support staff, no development budget, and no marketing.

5 years ago, I was sure RADIUS was dying. Since then, I've discovered why I was wrong.

Everyone wants RADIUS. You can go to Best Buy, and pick up a Linksys WRT54G for less than $100. You can run OpenWRT on it, which includes packages for FreeRADIUS!

That's cool.

You just can't kill a technology that is ubiquitous, and that everyone wants. Not that I want to do anything to RADIUS… I enjoy working in the space. But there have been many rumors over the past few years about the death of RADIUS.

Don't believe them.

I've taken a quick look at the Wiley RADIUS Book, and I have to say it looks like a significant effort. 300 pages, $120, and the table of contents covers a wide variety of topics.

My only question, though, is how useful it will be for the average administrator. The summary says

This text will provide researchers in academia and industry, network security engineers, managers, developers and planners, as well as graduate students,with an accessible explanation of the standards fundamental to secure mobile access.

I find that summary a little daunting, quite frankly. The first target audience is researchers. And from reading the sample chapter contents, I agree that researchers are a good target for this book. I've been working with RADIUS for a long time, and it took me some effort to understand the text.

Based on a preliminary review, this book appears useful if you're:

• a researcher,
• using mobile IP,
• using IPsec,
• using Diameter.

For the average administrator intent on deploying RADIUS, that book is probably too much. It looks to have some RADIUS content (20 pages or so), some overview of AAA architectures (50 pages or so), but the majority of it is devoted to issues that just don't come up in common RADIUS deployments.

The overlap between that book and Deploying RADIUS: Practices and Principles appears to be pretty minimal. My book will concentrate on practice, and not on research. i.e. Administrators are less concerned with how something works than with how to get a job done.

That's where Deploying RADIUS will shine.