Implementation and Verification of the Diameter NASREQ ...from RADIUS to Diameter is critical,...
Transcript of Implementation and Verification of the Diameter NASREQ ...from RADIUS to Diameter is critical,...
Master ThesisFachhochschul-Studiengang
Master Informatik
Implementation and Verification of theDiameter NASREQ Application usingthe OMNeT++ Network Simulation
Environment
implemented by
Bojan Zarkovic0810249012
submitted in partial fulfillment of the requirementsfor the degree of Master of Science in Engineering, MSc
Dornbirn, July 2010
Supervisor: Dipl. -Ing. Armin Simma
Contents
1 Introduction 4
1.1 Background and Motivation . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Structure of the Work . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 AAA - Authentication, Authorization, Accounting 7
2.1 General AAA Architecture . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Requirements for Protocols . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 Common AAA Protocols . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.1 TACACS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.2 RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.3 Diameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3 Diameter Base Specification 15
3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2 Connection vs. Session . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3 Diameter Node Types . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3.1 Relay Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3.2 Proxy Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3.3 Redirect Agent . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3.4 Translation Agent . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.4 Diameter Message Format . . . . . . . . . . . . . . . . . . . . . . . . 19
3.4.1 Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.4.2 Payload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.5 Capability Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.6 The Diameter NASREQ Application . . . . . . . . . . . . . . . . . . 24
3.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4 Network Simulation 25
4.1 Continuous Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2 Discrete Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3 Simulators for Computer Networks . . . . . . . . . . . . . . . . . . . 26
4.4 Rationale for the OMNeT++ Simulator . . . . . . . . . . . . . . . . 26
5 A Discrete Event Simulation Environment – OMNeT++ 27
5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2 Build Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.3 Modules – The Basic Building Blocks . . . . . . . . . . . . . . . . . . 29
5.4 The Message File Editor . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.5 The NED Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.6 The INI File Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.7 Tkenv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.8 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6 Simulation Model Design 35
6.1 Network Description – NED Files . . . . . . . . . . . . . . . . . . . . 35
6.2 Structure of a Diameter Message . . . . . . . . . . . . . . . . . . . . 35
6.3 Core Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.4 Module Interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
7 Implementation of the core modules 36
7.1 Prerequisite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
7.2 Message Definition File - DiameterMessage.msg . . . . . . . . . . . . 36
8 Diameter simulation 37
8.1 Testbed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
8.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
A Appendix 38
A.1 Command Codes in Diameter Messages . . . . . . . . . . . . . . . . . 38
A.2 Diameter Application Identifiers . . . . . . . . . . . . . . . . . . . . . 39
A.3 Basic and derived AVP Data Formats . . . . . . . . . . . . . . . . . . 40
A.4 Diameter Base Protocol AVPs . . . . . . . . . . . . . . . . . . . . . . 40
1Introduction
1.1 Background and Motivation
Due to the rise of e-commerce and the continuous growth of networked (mobile)
systems, the need for confidential communication has been increased considerably.
Thus, a plenty of security concepts and mechanisms have been developed and de-
ployed. Most of them rely on AAA architectures, which provide coherent authenti-
cation, authorization and accounting functionality. This enables an ISP to identify
and authorize its customer as well as to conduct the billing for the consumed re-
sources by the customer.
One of the most widespread protocols among AAA protocols is the Remote Dial-
In User Service (RADIUS), which does not fulfil all requirements for a real AAA
protocol defined by the AAA working group. Originally it was designed to perform
user authentication and authorization by a network access server (NAS) in conjunc-
tion with an AAA server, which executes the RADIUS protocol. Due to the lack of
accounting in the RADIUS specification and other shortcomings, the IETF decided
to specify a successor, which fulfils most of the earlier defined AAA requirements.
Indeed, Diameter was chosen out of four suggestions as the RADIUS successor.
Diameter is a more sophisticated protocol that does not only fix some of the RA-
DIUS shortcomings, but also enables new applications to be used with the Diameter
base protocol such as mobile IP or the SIP application. However, RADIUS still has
a large deployment base, whereas Diameter is not used extensively yet. The reason
is probably the lack of stable implementations of the Diameter protocol as well as
Chapter 1. Introduction 5
the issues which emerge with the migration from RADIUS to Diameter. Migration
from RADIUS to Diameter is critical, because it will not be simple to replace the
large RADIUS deployment base, since Diameter introduces more sophisticated con-
cepts like agents.
The complexity and the lack of Diameter implementations make it di�cult to eval-
uate the viability of the Diameter protocol with a specific application. A common
approach to verify the viability of a network protocol is to simulate the behaviour in
a network simulation environment. Simulations are not only used to verify a given
functionality, but also to find and fix vulnerabilities.
1.2 Objectives
The main objective of this thesis is the verification of the Diameter protocol based
on the NASREQ application. The NASREQ application contains the authentication
and authorization of a single user by a network access server (NAS) in conjunction
with a Diameter server. Because there is no existing Diameter simulation model for
the OMNeT++ simulation environment, it is necessary to design and implement
modules with Diameter functionality.
Due to the complexity of the protocol the modules are not required to be fully
Diameter compliant. Advanced features such as Diameter agents, accounting or
peer discovery are left to be implemented in future work. In fact, the objective is to
create a base AAA simulation framework, which can be extended with additional
AAA functionality and components in future work.
1.3 Related Work
At the time of writing there are only a few Diameter implementations available.
The reason is probably the complexity of the protocol and its innovation. Indeed,
Diameter is a peer-to-peer protocol with advanced concepts and technologies. A
collection of Diameter libraries is provided by the Open Diameter project. The li-
braries are written in C++ and under the GNU GPL available.
Chapter 1. Introduction 6
Since there are almost no implementations available, the Diameter protocol could
only be tested by simulation. In this work the OMNeT++ simulation framework
will be used for simulating the Diameter NASREQ application. The implemen-
tation in this work relies heavily on existing components of the INET framework.
There are several other frameworks available for simulations with OMNeT++ pro-
viding protocols, nodes and other simulation elements. For instance, the INET-
MANET framework provides additional protocols and nodes for mobile ad-hoc net-
works (MANETs).
1.4 Structure of the Work
2AAA - Authentication,
Authorization, Accounting
2.1 General AAA Architecture
Due to the increasing demand on AAA services the AAA Working Group decided
to charter members of its subgroup concerned with AAA authorization to found the
AAAarch Research Group. Its prime objective was to work out a general and flexible
architecture on which di↵erent applications could be run. The group was focused on
supporting NAS- and MobileIP applications. It is to be noted that the architecture
described in [de 00] is a proposal on how AAA protocols could be designed rather
than a specification.
The architecture is considered to be composed of a client and a generic AAA server
that handles user authentications, authorization requests and collects data for ac-
counting purposes. A Rule Based Engine and a Policy Repository are considered to
be part of the generic AAA server. The Rule Based Engine contains logic and/or
algebraic formulas to decide whether an authorization request is granted or denied.
In fact, the Policy Repository holds the available services and resources as well
as the policy rules. Since the generic AAA server has no application specific knowl-
edge, it is interfaced with an Application Specific Module (ASM). Thus, when an
authorization request is submitted to an AAA server it passes the application specific
information to the ASM. In fact, the ASM evaluates the information and returns
a boolean or numeric value to the AAA server. The returned value and the policy
Chapter 2. AAA - Authentication, Authorization, Accounting 8
rules from the Policy Repository are used by the Rule Based Engine to make the
authorization decision. Figure 2.1 illustrates a scenario where a client submits an
authorization request to a generic AAA server. The AAA server cannot handle the
request, thus it forwards the request to another AAA server which resides in a dif-
ferent administrative domain. In that case the first AAA server acts as a client to
the other AAA server. The communication between client and server takes place
via an AAA protocol.
Figure 2.1: AAA Architecture in a Multi Domain Environment
The second server extracts the application specific information for evaluation to an
ASM. In contrast to the client-to-server communication, the information exchange
with the ASM takes place via an application specific protocol. The generic AAA
server makes its decision by using its Rule Based Engine and the information from
the Policy Repository.
It is to be noted that for request forwarding a peer-to-peer protocol is proposed.
Furthermore, the AAA server has a database with timestamped events occurred in
the server. This database is used as an Authorization Event Log. Authorization
decisions could be coupled with previous events. By using certificates the database
could support non-repudiation.
Chapter 2. AAA - Authentication, Authorization, Accounting 9
2.2 Requirements for Protocols
A network protocol has to meet a plenty of requirements to be considered an AAA
protocol. The AAA Working Group has proposed as well as defined AAA require-
ments, which are distributed across several informational RFCs. Requirements for
AAA protocols with respect to the NAS application are defined by Beadles and
Mitton in [Bea01]. These include (among other aspects) bi-directional, multi-phase
and periodic re-authentication concerns as well as accounting and auditing issues.
Authorization requirements are defined separately by Farrell et al. in [Far00]. For
instance, the authorization information contains information about the requester,
the requested service and the operation environment. This information must be
represented by attributes. Moreover, it must be possible that attributes encapsulate
authorization information from non AAA protocols. An AAA protocol must provide
security mechanisms for the information communication. Furthermore, authoriza-
tion information must be timed, that is, it must expire. However, there must be a
mechanism for revoking authorization information before their expiration.
In [Abo00] Aboba et al. provide a more complete and general evaluation of require-
ments for AAA protocols. Table 2.1 lists a couple of these general requirements,
intended to give a brief overview.
Table 2.1: List of AAA Requirements
It is to be noted, that AAA requirements dispersed among various RFCs are defined
multiple and/or overlap each other. This is due to the inquiry of application specific
AAA requirements like in [Gla00] for MobileIP.
Chapter 2. AAA - Authentication, Authorization, Accounting 10
2.3 Common AAA Protocols
This section aims to provide a brief description of today’s available (and deployed)
AAA protocols. It starts with an introduction to the Terminal Access Controller
Access Control System (TACACS) and its adapted variants. Furthermore, the Re-
mote Dial-In User Service (RADIUS) will be covered in more detail. Diameter will
be covered in a separated chapter, since it is a main part of this work.
It is to be noted, that discussions concerning AAA protocols often associate Ker-
beros [Neu05] with AAA protocols. In fact, Kerberos does not provide any autho-
rization or accounting functionality, since it was designed for the purpose of network
authentication.
2.3.1 TACACS
One of the first deployed AAA protocols was TACACS. It was developed in the
eighties by the Department of Defence to be used in MILNET. As its name implies,
it was designed to be used for terminal authentication purposes. However, during
the years TACACS became obsolete and Cisco Inc. developed adopted variants of
TACACS. First Cisco Inc. developed an extended version (XTACACS) which en-
hanced the historic protocol with accounting functionality. Neither TACACS nor
XTACACS were o�cially specified. Nevertheless, there exists an informational de-
scription of the historic TACACS protocol in [Fin93].
Moreover, Cisco Inc. designed and developed from ground up a new protocol called
TACACS+, which is not compatible to the former variants. In contrast to other
AAA protocols, TACACS+ is a proprietary standard. The protocol allows a separa-
tion of authentication, authorization and accounting functionality. Furthermore, it
enables a per-user as well as a per-group authentication. TACACS+ is designed as
a client/server protocol which runs over TCP as transport layer protocol. Message
encryption is also supported. On the other hand, it neither supports proxies nor
other types of agents. A general description of TACACS+ is provided in [Car97].
Chapter 2. AAA - Authentication, Authorization, Accounting 11
2.3.2 RADIUS
The widely deployed Remote Dial-In User Service (RADIUS) was originally devel-
oped by Livingston Enterprises. It was standardized some years later by Rigney et
al. in [Rig00c] with the intention to define an open protocol for AAA applications.
As its name implies, it was originally designed to support remote dial-in services with
a NAS. Hence, accounting functionality was defined separately in [Rig00a] later on.
In contrast to TACACS and its variants, RADIUS runs over UDP instead of TCP.
Thus, reliability is accomplished by the specific RADIUS implementation on the
application layer. Since it relies on the client/server paradigm, there are no special
agents defined. Though, a RADIUS server can act as a proxy on the user’s behalf
when forwarding a request to another RADIUS server.
Originally, the Password Authentication Protocol (PAP) and the Challenge Hand-
shake Authentication Protocol (CHAP) were designated for RADIUS authentica-
tion. Though, other authentication protocols like the Extensible Authentication
Protocol (EAP) can be used as well. Hence, additional attributes were defined
in [Rig00b]. The next section covers some of the RADIUS shortcomings and Diam-
eter improvements. Diameter is covered in more detail in a separated chapter, since
it is a main part of the thesis.
2.3.3 Diameter
Though RADIUS has a large deployment base, it was not considered acceptable as
an AAA protocol, since it does not fulfill a fair amount of the requirements discussed
in section 2.2. Hence, the AAA Working Group (WG) started the process of finding
a successor for RADIUS.
Several supporters of candidate protocols have been asked to submit their proposals
to be evaluated against the AAA requirements discussed in section 2.2. The evalu-
ation team was composed of several WGs with members from well known telecom-
munications companies like Nokia or Nortel Networks.
Chapter 2. AAA - Authentication, Authorization, Accounting 12
In the end, the evaluation team received four candidate protocols to be verified
against the AAA requirements:
. SNMP (enhanced with AAA functionality)
. Radius++ (based on RADIUS)
. COPS (used also for QoS purposes)
. Diameter
In the end, Diameter was slightly preferred opposed to COPS, whereas the other two
protocols were not considered as real AAA protocols. Hence, the AAA WG decided
to focus its e↵orts on enhancements and improvements of the Diameter protocol as
the successor of RADIUS. The results of the evaluation was published in [Mit01] as
an informational RFC. Diameter will be covered in detail in chapter 3.
The RADIUS specification has some serious drawbacks, for instance, it does not
support server-initiated messages. In contrast, Diameter enables a server instance
to initiate certain actions (e.g. re-authentication, session termination etc.) and
hence send messages to its client. The following list itemizes some further improve-
ments and enhancements referring to [MN05]:
. Fail-Over: Fail-over means the forwarding of a pending request with an agent
to another agent if an error is detected on the transport layer. Every Diameter
node maintains a pending message queue for every peer. RADIUS does not
define any fail-over mechanisms at all. Hence, the fail-over behaviour is left to
be defined by RADIUS implementations.
. Reliable Transport: RADIUS defines no reliable transport mechanisms,
since it relies on UDP as transport protocol. This can cause a serious issue
when using RADIUS for accounting, where a packet loss translates directly
into revenue loss. Diameter runs over TCP and SCTP, respectively.
. Capability Negotiation: There is no way for a RADIUS client to determine
which attributes are supported by the server and vice versa.
Chapter 2. AAA - Authentication, Authorization, Accounting 13
. Security and Audibility: The RADIUS specification lacks comprehensive
security mechanisms. RADIUS defines only hop-by-hop security, which en-
sures trust between neighbour servers only. In case of proxy chaining man-in-
the-middle attacks are possible, since there are no end-to-end security mech-
anisms. The consequence is that it is possible for malicious proxies to modify
messages, that is, attributes as well as header fields.
RADIUS does not support per-packet confidentiality, but attribute hiding only.
It is to be noted that RADIUS accounting is vulnerable for replay attacks. The
usage of RADIUS in inter-domain roaming applications is di�cult due to the
lack of a possibility to establish certificate hierarchies. Diameter stipulates
end-to-end security by specifying IPSec [Ken05] as mandatory for both clients
and servers. Moreover, TLS [Die08] is optional for clients, but mandatory for
servers.
. Peer Discovery and Configuration: RADIUS administrators need to con-
figure addresses and shared secrets manually. This is a major security flaw,
since administrators tend to reuse names, addresses and shared secrets. More-
over, in large networks this approach causes a heavy administrative burden.
Diameter enables dynamic peer discovery as well as derivation of dynamic
session keys.
. Support for various Agents: Diameter defines explicitly agents for secure
inter-domain roaming (see section 3.3), whereas RADIUS does only define
proxy-chaining.
Both RADIUS and Diameter instances may coexist in the same network environ-
ment, though the format of the messages is di↵erent. However, an important design
goal of Diameter was the backward compatibility with RADIUS. In fact, the Diam-
eter specification preservers the Attribute-Value-Pair (AVP) code space below 255
for RADIUS Attributes. Moreover, the Diameter Base Protocol defines a translation
agent (see section 3.3.4) for conversion of RADIUS Attributes to Diameter AVPs
and vice versa. It is to be noted, that not every attribute can be translated into an
appropriate AVP.
Chapter 2. AAA - Authentication, Authorization, Accounting 14
Indeed, Diameter supports error-handling on transport level as well as on application
level, by using TCP/SCTP and error message AVPs, respectively. The specification
requires a peer to issue an answer message after receiving a request message. The
answer message contains a result code to indicate success or failure.
Moreover, Diameter enhances the support for several other applications including
SIP and mobile IP application. In contrast, its predecessor RADIUS supports only
the NAS application.
2.4 Summary
In August 2000 the AAAarch Research Group proposed a generic AAA architecture
for future AAA protocols. It describes a client/server architecture with coherent
components like the Policy Repository and the Rule Based Engine. Indeed, for the
client-to-server communication a peer-to-peer protocol is proposed.
There are a plenty of requirements defined across multiple documents that a pro-
tocol must fulfill, in order to be considered a AAA protocol. Scalability, Failover
and Transmission Layer Security are some examples among others for AAA require-
ments. Widely deployed protocols are TACACS+ and RADIUS. The former is a
proprietary protocol developed by Cisco, wheras the latter one is an open standard
specified by the IETF.
Since RADIUS was designed for user authentication via a NAS in the mid-nineties,
it has some serious shortcomings. Hence, the AAA Working Group decided to spec-
ify a successor protocol, which overcomes the RADIUS shortcomings. This protocol
is called Diameter to emphasize the improvements and enhancements. A compre-
hensive analysis and comparison of common AAA protocols is provided in [Ven02].
3Diameter Base Specification
3.1 Overview
As was mentioned in the previous chapter, Diameter is considered as the successor of
the aged RADIUS protocol. It was designed as a peer-to-peer protocol for the com-
munication with Internet Service Provider (ISP) with respect to user authentication,
authorization and accounting.
Figure 3.1: Relationship of Diameter Specifications
However, it was designated for multiple other Diameter applications. Its modular
architecture design is depicted in figure 3.1. Calhoun et al. defined in September
2003 the core protocol features (e.g. capability exchange, agents, error-handling
etc.) in [Cal03], the Diameter Base Protocol. Diameter applications extend the
Base Protocol with additional AVPs to carry application specific data, but may also
introduce new functionality as well as new concepts. Unlike RADIUS, the Diameter
Base Protocol includes accounting functionality.
Chapter 3. Diameter Base Specification 16
At the time of writing the following applications are specified: Mobile IPv4 [Cal05a],
Diameter SIP application [Gar06], Diameter EAP application [Ero05], Diameter
Credit Control application [Hak05] and the NASREQ application [Cal05b].
3.2 Connection vs. Session
Diameter is a connection-oriented protocol, which provides reliable transport mech-
anisms. Hence, the base specification mandates any Diameter client to use either
TCP or SCTP (Stream Control Transmission Protocol) as transport layer protocol,
whereas any server must support both transport protocols. In contrast to TCP, a
Diameter peer using SCTP is capable of additional features like multi-streaming1
and multi-homing2. Furthermore, SCTP is resistant against security threats like
SYN flooding or Denial of Service (DoS) attacks. A brief introduction into SCTP
and a good overview of its features is provided in [Ong02]. However, a comprehen-
sive and detailed description is provided by the protocol specification in [Ste07].
Any two Diameter peers do have to set-up a physical connection using TCP or
SCTP before any communication can happen. The application data is exchanged
after the client and server have established a session. Since the session is established
on the application layer in the TCP/IP reference model, it can span over multiple
nodes. Figure 3.2 illustrates the communication between client and server.
Figure 3.2: Connection vs. Session
Connections are always hop-by-hop, whereas sessions represent a logical end-to-end
channel. Both connections and session can be encrypted to secure communication.
1 Partition of data into multiple streams.2 A host can be assigned several IP addresses.
Chapter 3. Diameter Base Specification 17
3.3 Diameter Node Types
The Diameter standard defines in addition to ordinary client and server nodes, four
types of agents. Agents can be used for value-added processing of requests and
responses. Moreover, they can be used in complex networks to sort and forward
requests to the right target as well as for load balancing.
It is required for Diameter agents to maintain the transaction state, which im-
plies the hop-by-hop identifier in a Diameter message header. This is used for fail
over purposes. Hence, each agent must save the hop-by-hop identifier of a receiving
request and replace it with a locally unique identifier. The same field is replaced
with the stored identifier when the corresponding answer arrives to the agent. The
following subsections will briefly introduce each of the defined agents.
3.3.1 Relay Agent
The Relay Agent accepts AAA requests and routes them further to the next Diam-
eter node by consulting the Realm Routing Table, a list of supported realms and
known peer nodes. Furthermore, it modifies Diameter messages by inserting and re-
moving routing information only. The other fields of the message are left untouched.
Primarily, a Relay Agent is used to aggregate requests from several NASes, which
reduces the configuration load of the back end server.
Figure 3.3: Relaying of Diameter Messages
The NAS in figure 3.3 issues an authentication/authorization request for an user in
the example.com domain. Afterwards it performs a Diameter route lookup in its
Realm Routing Table by using example.com as the key to be looked for. It further
submits the request to the Relay Agent (DRL), which was identified as the next
hop. Receiving the request, the Relay Agent performs a lookup with the same key
Chapter 3. Diameter Base Specification 18
and forwards the request to the Home Diameter Server (HDS). Indeed, the HDS
processes the request and issues an answer message. The answer message is routed
back to the NAS by using the stored transaction state on the DRL.
3.3.2 Proxy Agent
The concept of Proxy Agents (proxies) is similar to Relay Agents excepting that
proxies modify messages to implement policy enforcement. Proxy Agents maintain
the state of their downstream peers (usually NASes) to enforce resource usage as well
as admission control. Since proxies can provide value-add functionality to Diameter
messages, there is no end-to-end security between the NAS and the Diameter server
possible. This would break the authentication due to the message modifications.
Moreover, the maintenance of transaction states is mandatory. However, a proxy
may maintain session states for resource limitation purposes.
3.3.3 Redirect Agent
Another type of agent is called a Redirect Agent, which is used to centralize routing
configuration for a single domain. When it receives a request from a client, it returns
a Redirect Notification. The notification message contains required information,
which allows Diameter nodes to communicate directly.
Figure 3.4: Redirecting Diameter Messages
Chapter 3. Diameter Base Specification 19
Since it is not burdened with relaying messages, it does not modify messages as well
as maintain any transaction state. It is to be noted, that a Redirect Agent never
receives answer messages. Hence, it cannot maintain any session state.
In the scenario in figure 3.4 a NAS submits a request to the Relay Agent, meant
for the HDS. The Relay Agent has no entry for example.com in its Realm Routing
Table, but it has configured a default route. Thus, it contacts the Redirect Agent,
which answers with the requested contact information. Afterwards the Relay Agent
contacts the HDS, which generates an answer message. Finally, the answer message
is routed back to the NAS.
3.3.4 Translation Agent
The fourth agent defined in the Diameter specification is called Translation Agent,
since it translates between two protocols (e.g. from RADIUS or TACACS+ to
Diameter and vice versa). Hence, it is used in scenarios where migration from a
legacy protocol to Diameter is considered.
Figure 3.5: Translation between RADIUS and Diameter Messages
It is to be noted, that Translation Agents must maintain session states as well as
transaction states. Session states must be maintained, because Diameter introduces
the concept of long-lived authorized session. Figure 3.5 shows a self explaining
scenario, where a Translation Agent is used to translate messages between a RADIUS
client and a Diameter server.
3.4 Diameter Message Format
The information exchanged between Diameter nodes is encapsulated in Diameter
messages. Each message has a Header and a payload, which is represented by an
Chapter 3. Diameter Base Specification 20
Attribute-Value-Pair (AVP). The following subsections provide a guidance through
the structure of a Diameter message as well as its content.
3.4.1 Header
The receiving Diameter node uses the header of the message to determine the action
to be taken on a received Diameter message. The fields of the header are apparent
from figure 3.6 as well as their number of octets.
Figure 3.6: Structure of Diameter Messages
Every Diameter message contains a header with the following fields:
. Version: Indicates the Diameter version and set to 1 by default.
. Message Length: Specifies the length of the message including the header.
. Command Flags: The first four bits represent flags associated with a mes-
sage, whereas the last four bits are reserved for future use and are required to
be set to zero. The following bits represent flags:
– R-Bit: If set, the message is a request otherwise an answer.
– P-Bit: If set, the message may be proxied, relayed or redirect by an
Diameter agent. Otherwise it must be processed locally.
Chapter 3. Diameter Base Specification 21
– E-Bit: Indicates a protocol error and must not be set in request messages.
Messages with a set ’E’ bit are referred to as error messages.
– T-Bit: Used to indicate a potentially re-transmitted message. It is set
when resending requests are not acknowledged as an indication of a possi-
ble duplicate message. The flag must not be set in an answer message as
well as in an error message that has been received for the earlier message.
When the message is forwarded by a Diameter agent, the ’T’ flag must
be kept unchanged.
. Command Code: This field identifies the command associated with the
message. The code is used to determine the action to be accomplished for
a particular message. A complete list of all command codes defined in the
Diameter Base Protocol can be found in section A.1 of appendix A.
. Application ID: Indicates the application to which the message is applicable
for. That could be one of the mentioned applications in section 3.1 or even a
vendor specific one. Section A.2 of appendix A contains a list of all standards
track applications.
. Hop-by-Hop Identifier: This field contains a monotonically increased un-
signed 32-bit integer, which is used to uniquely identify a connection. Its start
value is randomly generated. The sender of an answer message must ensure
that the answer message contains the same value that was found in the cor-
responding request message. A message received with an unknown identifier
must be discarded.
. End-to-End Identifier: This field contains an unsigned 32-bit integer for
the purpose of duplicate message detection. The sender of a request message
must set an unique identifier, whereas the originator of an answer message
must ensure that the answer message contains the same value that was found
in the corresponding request message. Diameter agents must not modify the
identifier of a received message. The identifier must remain locally unique for
at least four minutes, even across reboots.
Chapter 3. Diameter Base Specification 22
3.4.2 Payload
The payload of a Diameter message contains several AVPs, at least one. Every AVP
consists of a header and encapsulated information relevant to the used Diameter
application. The general format of an AVP is depicted in figure 3.7.
Figure 3.7: Structure of an AVP
As mentioned above an AVP carries information relevant to a specific application.
Such information could be the username and password in an authentication appli-
cation. However, the header of an AVP contains the following information:
. AVP Code: Identifies the attribute uniquely in conjunction with the Vendor-
ID field. The space of numbers from 1 to 255 without setting the Vendor-ID
field are reserved for RADIUS backward compatibility. The space above 255 is
used for Diameter attributes assigned by IANA. A complete list of all defined
AVPs with their codes is provided in section A.4 in appendix A.
. AVP Flags: Indicate how the attribute should be handled by the receiver.
The first three bits are used, whereas the remaining bits are unused and marked
as reserved. The following bits are defined:
– V-Bit: Known as the Vendor-Specific bit, which indicates if the Vendor-
ID field is present.
– M-Bit: Known as the Mandatory bit, which indicates whether support
of the AVP is required. A Diameter node who receives an either an un-
recognized AVP or its value with the ’M’ bit set must reject the message.
Chapter 3. Diameter Base Specification 23
An exception are relay and redirect agents, who must not reject messages
with unrecognized AVPs. A cleared ’M’ bit denotes an informational
AVP. Such an AVP may be ignored by a receiver node, if itself or its
value is not supported.
– P-Bit: Indicates the need for encryption for end-to-end security.
. AVP Length: Denotes the number of octets the AVP payload contains,
including the header fields. A message with an invalid attribute length should
be rejected.
. Vendor-ID: Denotes in conjunction with the AVP Code a vendor specific
attribute. This field is optional.
The AVP Data field contains either zero or several octets of attribute data. Each
attribute has either a basic or a derived data format. A comprehensive list of valid
data formats is provided in section ?? of appendix A. Moreover, the Diameter base
protocol defines a couple of AVPs, which are listed in section A.1 of appendix A.
3.5 Capability Exchange
In contrast to RADIUS and other AAA protocols, Diameter requires an exchange
of capabilities before an AAA request is issued. This enables Diameter nodes to
discover the identity and capabilities (supported services and security mechanisms)
of their peers. Moreover, the base specification requires the peers to cache the ad-
vertised applications in order to avoid sending unsupported application commands.
The receiving peer of a Capability Exchange Request (CER) closes the transport
connection to its peer in the following situations:
. If it does not support the advertised application from its peer. In that case it
issues a Capability Exchange Answer (CEA) with the result code AVP set to
DIAMETER NO COMMON APPLICATION and sends it back to the peer.
. If it does not support the advertised security mechanism. This causes a CEA
with a result code AVP set to DIAMETER NO COMMON SECURITY to be
issued and sent back to the peer.
Chapter 3. Diameter Base Specification 24
. If it receives a CER from an unknown peer. It is left to the peer, whether
it discards the request or issues a CEA with the result code AVP set to DI-
AMETER UNKNOWN PEER. In both cases the transport connection will be
closed.
Capability exchange messages must not be processed by any of the agents defined
in section 3.3.
[CER/CEA MESSAGE FORMAT?]
3.6 The Diameter NASREQ Application
3.7 Summary
4Network Simulation
4.1 Continuous Simulation
4.2 Discrete Simulation
Figure 4.1: The event loop
Chapter 4. Network Simulation 26
4.3 Simulators for Computer Networks
4.4 Rationale for the OMNeT++ Simulator
Omnet++ is used for the following reasons:
. one of the most widespread network simulators (several projects were devel-
oped INET, MANET, ..., several papers written)
. huge academic community - (support, bug-fixes, mailing list)
. well documented
. powerful tool with many features (reports, charts)
. available in version 4 (approved net simulator)
5A Discrete Event Simulation
Environment – OMNeT++
5.1 Overview
The Objective Modular Network Testbed in C++ (OMNeT++) is according to its
project website ”an extensible, modular, component-based C++ simulation library
and framework” (http://www.omnetpp.org/). That is, it provides not only a sim-
ulation infrastructure, but also supporting tools for the development of simulation
models. In fact, simulation models are typically composed of several building blocks
called modules, which are written in C++. Hence, OMNeT++ provides an eclipse-
based IDE for developing and debugging the modules. Furthermore, OMNeT++
enables a parallel and distribute simulation by configuration.
The development of OMNeT++ started in 1992 as a student project at the university
of Budapest (Hungary) by Andras Varga. During the years many people contributed
to the project with new simulation models. For instance, the TCP model was de-
veloped by several people at the university of Karlsruhe (Germany) in 2000. At the
time of writing the current version is 4.0, which is used for the implementation in
this thesis. In fact, models developed with with previous version need to be rewrit-
ten due to the new features introduced in the 4.0 version. Fortunately, OMNeT++
provides tools and documentation on migration from models of the previous version
to the newer version (see [omna] for explanation).
Chapter 5. A Discrete Event Simulation Environment – OMNeT++ 28
As an open source project OMNeT++ is free only for academic and non-profit
use in general, otherwise a commercial version (OMNEST) needs to be obtained
from Simulcraft Inc. Both versions are available for Windows, Linux, MacOs and
other Unix-like systems. In contrast to OMNeT++, the commercial version pro-
vides some additional features like support for Microsoft Visual C++ among others.
A detailed comparison is provided on the OMNEST website1.
5.2 Build Process
The intention of this section is to briefly explain the building process of a simulation
model. Figure 5.1 illustrates each step until a simulation is running. The involved
components are discussed in the next sections.
Figure 5.1: Build Process in OMNeT++
As mentioned in the previous section, simulation models are composed of modules
written in C++. The modules interact with each other by message-passing. The
1http://www.omnest.com/comparison.php, accessed on 28th of April 2010.
Chapter 5. A Discrete Event Simulation Environment – OMNeT++ 29
message format is described by a message file (.msg) in a C++-like language and
translated into C++ code by a message compiler (see section 5.4. Afterwards all
source files are compiled and linked with the simulation kernel and some user inter-
face libraries. The generated output is an executable simulation program.
However, the simulation need to be configured in order to get useful results. This is
done by creating configuration files, that is, network description files (ned files) and
an initialization file (omnetpp.ini). Simulation parameters are usually placed in the
omnetpp.ini file, but can be placed in optional XML files as well. When running
the simulation program the network description and configuration file(s) are loaded
dynamically. The simulation results are usually placed in separate statistic files to
be inspected later on.
5.3 Modules – The Basic Building Blocks
Simulation models are composed of components called modules. Indeed, OMNeT++
defines simple and compound modules. Simple modules encapsulate the behaviour
of a component, that is, the C++ code. As figure 5.2 illustrates, compound modules
can be thought of a collection of simple modules. The modules labelled M1, M2 and
M3 are simple modules.
Figure 5.2: Compound and Simple Modules
Each module is associated with at least one gate2, connections and optional param-
eters. Messages travel via connections from one gate to another gate. Connections
2 In other simulation environments gates are called ports. This could lead to misunderstandingsand confusion, since there are many other items called ports, for instance, TCP ports. Hence,ports in OMNeT++ are called gates.
Chapter 5. A Discrete Event Simulation Environment – OMNeT++ 30
are represented by channels associated with simulation parameters like data rate or
bit error rate. As figure 5.2 illustrates, simple modules can be connected within a
compound module as well as with modules beyond a compound module. It is to be
noted, that modules (simple and compound) can be nested arbitrarily.
In general a network is designed as a compound module, which contains multi-
ple network devices like router or hosts. Usually each of the network devices itself
are compound modules. Due to the modular architecture of OMNeT++, devices
can be assembled arbitrarily with di↵erent protocol layers.
5.4 The Message File Editor
For communication, modules exchange messages with other modules. In general a
message contains an encapsulated packet, which format is defined by the used net-
work protocol. In OMNeT++ messages are represented by the core class cMessage.
Indeed, packets are represented by the cPacket core class, which itself is subclassed
from the cMessage core class.
Usually a packet carries some header fields as well as payload data. These fields
need to be placed into the appropriate C++ message class. This could be done
either by manually writing the C++ code or left to the Message Compiler [omnb],
which automatically generates the appropriate code. The Message Compiler gener-
ates for each field a private member and corresponding getter and setter methods as
well as reflection code for further inspection in Tkenv. Furthermore, the resulting
class needs to be integrated with the simulation framework. Because this is a te-
dious and error-prone task for a developer, it is more convenient to let the message
compiler generate the appropriate code automatically.
As it is depicted in figure 5.3 the Message Compiler gets a message definition file
as its input and produces the corresponding C++ source and header file. The files
are named with the class name followed by a m postfix. The message definition
file contains a description of the packet format expressed in a C++ like syntax.
The protocol header fields as well as the payload can be assigned any of the scalar
C++ types. Moreover, a message definition file may contain definitions of embedded
Chapter 5. A Discrete Event Simulation Environment – OMNeT++ 31
classes as well as other data structures like structs or enums. However, pointers and
unions are not supported.
Figure 5.3: Message Compiler
A major drawback of code generators is the lost of flexibility in writing customized
code. For instance, it is worthless to edit a pre-defined getter/setter method since
the files are over-written every time the compiler processes the message definition
file. The changes in the getter/setter methods are lost. Fortunately, this could be
avoided by adding the @customized(true); line of code to the message definition.
This causes the Message Compiler to generate a header and source file named with
the class name followed by the Base postfix. Subclassing from this base class enables
the addition of customized code.
5.5 The NED Editor
Every module has in addition to its implementation a corresponding Network De-
scription (NED) file. The NED file contains the description of the gates, parameters
and the connections to other modules. To edit such files an additional tool was added
to the Eclipse-based IDE, simply called the NED Editor. The Editor can be used
either in graphical or textual mode. In Figure 5.4 the editing of a router component
in graphical mode is illustrated. On the left side several modules are placed into a
compound module, which represents the router. The right side shows a palette from
which modules can be added to the model. In general the editor provides function-
ality similar to other graphical editors like resizing of components or zooming.
Chapter 5. A Discrete Event Simulation Environment – OMNeT++ 32
Figure 5.4: NED Editor in Graphical Mode
Every change in graphical mode is visible in textual mode immediately. The textual
mode o↵ers syntax highlighting and code completion. Furthermore, the typed code
is immediately evaluated for displaying errors, if there are any.
5.6 The INI File Editor
The advanced configuration of the simulation model is placed in the initialization
file (ini file), which is a plain text file by default named omnetpp.ini. Such config-
uration files can be edited with every text editor. However, the OMNeT++ IDE
provides an additional INI File Editor aiding the user in configuring the simulation
model either form-based or textual. It provides the same editing features like the
NED Editor, that is, syntax highlighting, code completion and error detection.
The ini file is organized in di↵erent sections, where the general section is the root
of all other sections. It contains at least the name of the network to be simulated
is specified. All sections inherit the parameters from the general section. In the
general section one can further specify the stopping condition for a simulation.
Moreover, several configurations can be stored in a single ini file. This is particu-
Chapter 5. A Discrete Event Simulation Environment – OMNeT++ 33
larly convenient when a model should be examined with di↵erent parameters. Figure
5.5 illustrates the INI File Editor in form-based mode.
Figure 5.5: Configuration Form in INI Editor
The form-based mode shows all supported configuration options as well as all avail-
able parameters, which can be set in from ned files too. As figure 5.5 shows there
are sections for the configuration of random number generators, output files or even
parallel simulation parameters.
5.7 Tkenv
5.8 Summary
OMNeT++ provides an extended IDE with new editors, views and additional func-
tionality based on the Eclipse platform. see user guide [omnc]
Chapter 5. A Discrete Event Simulation Environment – OMNeT++ 34
Figure 5.6: Tkenv
6Simulation Model Design
6.1 Network Description – NED Files
6.2 Structure of a Diameter Message
Figure 6.1: Diameter Message Design
6.3 Core Modules
6.4 Module Interactions
7Implementation of the core modules
7.1 Prerequisite
7.2 Message Definition File - DiameterMessage.msg
8Diameter simulation
8.1 Testbed
8.2 Results
AAppendix
A.1 Command Codes in Diameter Messages
Every message has an unique command code to indicate the message is to be pro-
cessed by the receiving node. The codes defined in the Diameter Base Protocol are
listed in table A.1 with their abbreviations.
Table A.1: Diameter Command Codes
The Diameter NASREQ application defines additional command codes. Most of
them are identical with the codes defined in the Base Protocol. Table A.1 lists all
NASREQ command codes.
Figure A.1: NASREQ Command Codes
A.2 Diameter Application Identifiers
The Diameter protocol was designed to support several applications. Each standards
track application is assigned an unique identifier. Table A.2 lists all standardized
applications with the assigned identifiers.
Table A.2: Application IDs for Diameter Applications
The range of 0x00000001 to 0x00↵↵↵ has been assigned to standard application,
whereas the range of 0x01000000 to 0x↵↵↵fe is preserved for private use.
A.3 Basic and derived AVP Data Formats
An Attribute-Value-Pair (AVP) contains the data to be exchanged between peers.
The Diameter Base Protocol defines a couple of basic data types. Table A.3 lists all
basic data types. The derived types are listed in table A.4.
Table A.3: Basic Data Types
Table A.4: Derived Data Types
A.4 Diameter Base Protocol AVPs
The AVPs defined in the Diameter Base Protocol are completely listed in table A.4
with their data types and the assigned codes. Moreover, table A.4 illustrates which
flags must, may or must not be set.
Bibliography
[Abo00] Aboba B., et al. Criteria for Evaluating AAA Protocols for Network Ac-
cess. IETF, RFC2989, November 2000.
[Bea01] Beadles M., Mitton D. Criteria for Evaluating Network Access Server
Protocols. IETF, RFC3169, September 2001.
[Cal03] Calhoun P., Loughney J., Guttman E., Zorn G., Arkko J. Diameter Base
Protocol. IETF, RFC3588, September 2003.
[Cal05a] Calhoun P., Johansson T., Perkins C., Hiller T., McCann P. Diameter
Mobile IPv4 Application. IETF, RFC4004, August 2005.
[Cal05b] Calhoun P., Zorn G., Spence D., Mitton D. Diameter Network Access
Server Application. IETF, RFC4005, August 2005.
[Car97] Carrel D., Grant L. The TACACS+ Protocol. Internet-Draft, January
1997.
[de 00] de Laat C., Gross G., Gommans L., Vollbrecht J., Spence D. Generic AAA
Architecture. IETF, RFC2903, August 2000.
[Die08] Dierks T., Rescorla E. The Transport Layer Security (TLS) Protocol.
Version 1.2. IETF, RFC5246, August 2008.
[Ero05] Eronen P., Hiller T., Zorn G. Diameter Extensible Authentication Protocol
(EAP) Application. IETF, RFC4072, August 2005.
[Far00] Farrell S., Vollbrecht J., Calhoun P., Gommans L., Gross G., de Bruijn B.,
de Laat C., Holdrege M., Spence D. AAA Authorization Requirements.
IETF, RFC2906, August 2000.
[Fin93] Finseth C. An Access Control Protocol, Sometimes Called TACACS.
IETF, RFC1492, July 1993.
42
[Gar06] Garcia-Martin M., Belinchon M., Pallares-Lopez M., Canales-Valenzuela
C., Tammi K. . Diameter Session Initiation Protocol (SIP) Application.
IETF, RFC4740, November 2006.
[Gla00] Glass S., Hiller T., Jacobs S., Perkins C. Mobile IP Authentication, Autho-
rization, and Accounting Requirements. IETF, RFC2977, October 2000.
[Hak05] Hakala H., Mattila L., Koskinen J., Stura M., Loughney J. Diameter
Credit-Control Application. IETF, RFC4006, August 2005.
[Ken05] Kent S., Seo K. Security Architecture for the Internet Protocol. IETF,
RFC2401, December 2005.
[Mit01] Mitton D. St. Johns M., Barkley S., Nelson D., Patil B., Stevens M., Wol↵
B. Authentication, Authorization and Accounting: Protocol Evaluation.
IETF, RFC3127, June 2001.
[MN05] Mahsa Nakhjiri Madjid Nakhjiri. AAA and Network Security for Mobile
Access. Wiley, 1 edition, September 2005.
[Neu05] Neuman C., Yu T., Hartman S., Raeburn K. The Kerberos Network Au-
thentication Service (V5). IETF, RFC4120, July 2005.
[omna] Migrating OMNeT++ Simulations From Version 3.x To 4.0.
. http://omnetpp.org/doc/omnetpp40/Migration.pdf, accessed on
28th April 2010.
[omnb] OMNet++. Descrete Event Simulation System, User Manual, Version
4.0. http://www.omnetpp.org/doc/omnetpp40/Manual.pdf, accessed on
28th April 2010.
[omnc] OMNeT++ User Guide. http://www.omnetpp.org/doc/omnetpp40/
UserGuide.pdf, accessed on 28th April 2010.
[Ong02] Ong L., Yoakum J. An Introduction to the Stream Control Transmission
Protocol (SCTP). IETF, RFC3286, May 2002.
[Rig00a] Rigney C. RADIUS Accounting. IETF, RFC2866, June 2000.
[Rig00b] Rigney C., Willats W., Calhoun P. RADIUS Extensions. IETF, RFC2869,
June 2000.
[Rig00c] Rigney. C, Willens S., Rubens A., Simpson W. Remote Authentication
Dial In User Service (RADIUS). IETF, RFC2865, June 2000.
[Ste07] Stewart R. Stream Control Transmission Protocol. IETF, RFC4960,
September 2007.
[Ven02] Ventura H. Diameter next generation’s AAA protocol. Master’s thesis,
Linkopings Tekniska Hogskola, April 2002.