Side_1_360

shared, are explained above. Co-existenceindi-

cates whether both tree types can exist and

a switchover might be possible for the same

multicast session. Uni-/bi-directionalrefers to

whether a shared tree supports uni- and/or bi-

directional connections. Encapsulationindicates

whether data between the source and the root

node (for shared trees) is encapsulated (i.e. IP-

in-IP). Loop freerefers to whether or not loop

detection is part of the multicast protocol.

6 Authentication, Authorisation,

Accounting and Security

Increasing commercialisation leads to a steadily

growing emphasis on the issues addressed in

this chapter. Authentication, authorisation and

accounting (AAA) are essential functions of net-

work management and when interfacing cus-

tomers and other operators/providers.

As a customer is eventually to pay for a service,

being sure that the service is delivered to the

proper party and charged for correctly is essen-

tial. Besides, having traffic flows from different

parties in the network also requires adequate

security mechanisms.

Authentication is not specifically described in

the following. Authentication is commonly

understood as confirming that the source/entity

is the one it claims to be. This is often imple-

mented by using passwords, certificates and so

forth.

6.1 Authorisation Framework

Authorisation is the function of deciding whether

a particular right can be granted to the presenter

of a particular credential; for instance, if a given

user is allowed to use a certain resource.

The framework identifies the conceptual entities

that may be participants in an authorisation pro-

cedure (see Figure 16):

1. A User who wants to access the service or
   resource;


2. A User Home Organisation (UHO) that has an
   agreement with the user and checks whether

the user is allowed to obtain the requested ser-

vice or resource;

3. A Service Provider’s AAA Server that autho-
   rises a service based on the agreement with
   the UHO without specific knowledge of the
   individual user;


4. A Service Provider’s Service Element that
   provides the service itself.

Several scenarios are possible:

• Single domain case: the UHO and the Service
  Provider are the same entity. An example of
  this is a router controlled by a local bandwidth
  broker acting as the AAA server.


• Roaming: the UHO and the Service Provider
  are different. Their AAA servers have to co-
  operate in order to complete the authorisation
  process. An example of roaming is a Mobile
  IP provider allowing access to a user from
  another domain.


• Distributed Service: to complete a service,
  offerings from several service providers may
  need to be combined. Again, the AAA servers
  of the service providers have to co-operate.

In all scenarios SLAs would exist between the

actors, which have to be taken into account

when making authorisation decisions.

All these entities may interact in many different

ways depending on the type of service and sce-

nario. In some cases the user may send the ser-

vice requests to the AAA server, while in others

the request is sent to the service element (e.g.

dial-in access). Also, it is possible for the user to

get a ticket or certificate from the AAA server to

include it in the request to the service element.

One view of an authorisation is that it is the

result of evaluating policies of each organisation

that has an interest in the authorisation decision.

The authorisation process can be modelled in

terms of the Policy Framework [Jens01a]. AAA

servers may act as Policy Retrieval Points (PRP)

and Policy Decision Points (PDP). Service ele-

ments correspond to Policy Enforcement Points

(PEP). Both entities are also Policy Information

Points (PIP) containing information needed for

policy evaluation, which can be accessed as Pol-

icy Information Base (PIB). The user may also

be a PRP, a PIP and a PDP if policy is used to

request the service. These are described in

[Jens01a].

In many applications, authorisation results in

establishing an ongoing service which is called

a session. Each of the AAA servers involved in

Figure 16 Entities in the
authorisation framework

User

User Home

Organisation

Service Provider

AAA

server

service

element

= agreement