Adding bandwidth specification to a AAA Sever

Abstract: Authentication, authorization, and accounting (AAA) are key elements in network security. In many networks, clients can use resources only after they have been authenticated by an authentication server and authorized to use these resources. In some cases the server will also maintain accounting records in order for an operator (a provider of resources) to charge the account/subscriber for using the service. There are four main AAA protocols being used today. Of these RADIUS is the mostly widely used. This thesis starts with an introduction to AAA protocols, and then goes in the details of RADIUS. In order to perform a practical evaluation of how the AAA could be improved, FreeRADIUS was selected as the base code for this project; because this implementation is one of the most widely used RADIUS servers. A proposal for how to improve AAA performance is introduced and the implementation steps needed to realize these improvements are shown. Additionally, some experiments have been conducted to show both the correct functioning of the resulting implementation and to examine if there is a performance improvement. Following this some conclusions are drawn based upon a comparison with a traditional AAA server. A key element of the change in AAA which is proposed is the use of a non-binary IEEE 802.1x process. This new non-binary solution introduces a new type of AAA server and requires the re-thinking of a number of traditional AAA design decisions. It is expected that this change will have a significant impact, but will require some time for exposure, implementation by others, and a more extensive evaluation that was possible during the period of this thesis project. One of the most important conclusions drawn during this thesis is the difficulty of making a change in authentication and authorization, because of the large amount of interaction between both the various protocols and the standards which have been developed for these protocols. Thus one of the difficult aspects of the task is how to introduce a change in a protocol while maintaining backward compatibility for others who have not adopted this change -- without requiring the addition of a protocol version field. A second important conclusion is that doing this implementation in three separate parts with different students being responsible for the different parts revealed just how complex the interaction of protocol design decisions are. While a working version of the entire set of changes proved to be impossible, it was observed that the different parts could be decoupled more than initially expected.