Alan DeKok's RADIUS Blog

RFC 5080 has just been issued. It's been in progress for over three years now, so I'm personally very happy that it is finally done. As a co-author, it's nice to see it published. As someone who has been working with RADIUS for a long time, it's nice to be able to point to a document that clarifies problems or inconsistencies in previous RFC's.

This document describes common issues seen in Remote Authentication Dial In User Service (RADIUS) implementations and suggests some fixes. Where applicable, ambiguities and errors in previous RADIUS specifications are clarified.

Section 2.1.1 (no hyperlink available yet) documents the practice first implemented in FreeRADIUS: simplified handling of EAP sessions in RADIUS servers. To my knowledge, all RADIUS servers today follow the FreeRADIUS method of handling EAP sessions… even large commercial products.

So if a commercial vendor ever puts down FreeRADIUS, you can politely point out that their software is following our lead.

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.

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.

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.

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'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.