Implementation and Veriﬁcation of the Diameter NASREQ ...from RADIUS to Diameter is critical, because it will not be simple to replace the large RADIUS deployment base, since Diameter

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.


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.


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


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.


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.


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


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.


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


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


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


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.


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


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.


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.


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

http://www.omnetpp.org/

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.

http://www.omnest.com/comparison.php


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.


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


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.


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-


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]


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.

http://omnetpp.org/doc/omnetpp40/Migration.pdf

http://www.omnetpp.org/doc/omnetpp40/Manual.pdf

http://www.omnetpp.org/doc/omnetpp40/UserGuide.pdf

http://www.omnetpp.org/doc/omnetpp40/UserGuide.pdf

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

Documents

Implementation and Veriﬁcation of the Diameter NASREQ ...from RADIUS to Diameter is critical, because it will not be simple to replace the large RADIUS deployment base, since Diameter