Aaa

Technical White Paper for MSCG Authentication, Authorization and Accounting

Huawei Technologies Co., Ltd.


Huawei Technologies Co., Ltd. All Rights Reserved ihttp://datacomm.huawei.com

Table of Contents

1 Overview.......................................................................................................................... 1

1.1 Background............................................................................................................. 1

1.2 Objectives................................................................................................................ 2

2 Authentication Technology and Realization ............................................................... 2

2.1 PPP Authentication ................................................................................................ 5

2.1.1 Basic Principles................................................................................................. 5

2.1.2 Details of Realization ........................................................................................ 6

2.2 WEB Authentication ............................................................................................... 8

2.2.1 Basic Principles................................................................................................. 8

2.2.2 Details of Realization ........................................................................................ 9

2.3 Binding Authentication ........................................................................................ 10

2.3.1 Basic Principles............................................................................................... 10

2.3.2 Details of Realization ...................................................................................... 11

2.4 802.1X authentication ........................................................................................... 11



2.5 A Comparison of Authentication Methods......................................................... 14

3 Authorization Technology and Realization ............................................................... 16

3.1 User Static Authorization..................................................................................... 16



3.2 User Dynamic Authorization................................................................................ 17



4 Accounting Technology and Realization................................................................... 18


Huawei Technologies Co., Ltd. All Rights Reserved iihttp://datacomm.huawei.com

4.1 Remote Accounting .............................................................................................. 18



4.2 Real-time Accounting........................................................................................... 19



4.3 Local Accounting Protection............................................................................... 20



4.4 Accounting Copy .................................................................................................. 21



5 Typical Application Cases........................................................................................... 22

5.1 Typical PPPoE User Networking Applications .................................................. 22

5.2 Typical IPoE User Networking Application ........................................................ 23

5.3 Multi-Play Service Typical Networking Applications ........................................ 24

Appendix Abbreviation ..................................................................................................... 25


Huawei Technologies Co., Ltd. All Rights Reserved 1http://datacomm.huawei.com

Technical White Paper for MSCG

Authentication, Authorization and Accounting

Abstract: This paper presents a detailed description of MSCG authentication, authorization

and accounting technologies and their typical application instances and

configurations.

Key Words: Authentication, Authorization, Accounting

1 Overview

1.1 Background

The traditional IP network pertains to common communications resources that deliver the

best-effort services, pursue a simple and open architecture, and offer users an open

communications platform instead of conducting user-based operation and management.

In the telecom IP bearer network, however, delivering operable and manageable network

services holds key to networking, and as a result the telecom IP bearer network needs to

provide AAA capabilities, including:

Authentication: validating the identity of users when they log on to network;

Authorization: granting users access to network resources in network applications;

Accounting: recording and providing accurate bill data on users network access or usage.

To ensure network access for authorized users, identifying their identity is required.

Authentication is a process of identifying user identity; authorization is a process of

accessing the preconfigured user profile after identifying user identity through

authentication, granting users the corresponding power of access to network based on

their user profile, including bandwidth limitation, access list, and service strategy, and

thus delivering committed network services to users; accounting is a process of billing

users based on their network access lists and data, and collecting fees by strength of

supporting bills. A statistical record of accounting information can be made per user

accessed services, duration, and traffic.



The authentication, authorization and accounting (AAA) technologies are both mutually

independent and closely related. Authentication is the identification of a user as a

genuine one and a precondition for granting user access. Authorization is an important

means of rigorous user service management and control. Accounting offers technical

assurance for service providers to garner profitability.

1.2 Objectives

In network operation, AAA technologies abound in variety, and carriers also pose stark

discrepant AAA requirements for different users and services.

Based on the large volume of services furnished over years for globally operating

networks, Huawei Corporation makes an analysis and summary of the following mature

and sophisticated AAA solutions, which have been implemented to effectively enhance

broadband network operation and evolution.

At the core of AAA solution is a multi-service control gateway (MSCG) located at the

edge of IP/MPLS multi-service bearer network convergence. MSCG has satisfied the

diverse needs of different levels of customers by seamlessly integrating the various

features of user/terminal management, service control, and security control.

This paper introduces Huawei MSCG AAA technologies and solutions available for

application in broadband operating networks. Huaweis representative AAA products are

MA5200G and ME60 Series.

2 Authentication Technology and Realization

The leading authentication methods used today include PPP authentication, WEB

authentication, bundle authentication and 802.1X authentication. The four authentication

methods can be used together with user access methods to carry out user access

authentication management.

Each authentication method supports one or more authentication technologies. The

relationship between authentication method and authentication technology is shown in

the table below:

Table 1 The Relationship between Authentication Technology and Authentication Method

Authentication Method Authentication Technology

PPP authentication PAP, CHAP/MSCHAP, EAP



Authentication Method Authentication Technology

WEB authentication PAP, CHAP

Binding authentication Authentication based on users location information

802.1X authentication EAP

The technical specifications for authentication are listed in the table below:

Table 2 A Summary of Authentication Technologies

Authentication Technology Description

PAP (Password Authentication Protocol) PAP authentication is a two-way handshake authentication method using transparent

password. The authenticated user sends

username and password to authenticator who

views the user profile to see whether the user

exists and whether the password is correct before

returning a response (Acknowledge or Not

Acknowledge). PAP transparently interacts or

forwards authentication password, resulting in a

compromise of security to some extent.

CHAP

(Challenge Handshake Authentication

Protocol)

CHAP authentication is a three-way handshake

authentication method under which password is

encrypted text (key). The authenticator sends

some randomly generated challenge to the

authenticated user; the authenticated user uses

his/her password and MD5 algorithm to encrypt

the message, and sends the encrypted text back to

the authenticator (Response); the authenticator

uses the authenticated users password and MD5

algorithm stored to encrypt the original random

message, compares their encrypted texts, and

then responds with Acknowledge or Not

Acknowledge based on the results of comparison.

Using encrypted text to interact password delivers

a higher level of security than PAP.

MSCHAP (Microsoft CHAP) MSCHAP is an authentication protocol of Microsoft derived after extending CHAP. MSCHAP

integrates cryptographic algorithm and hash

algorithm and is suitable for LAN users. MSCHAP



Authentication Technology Description

includes V1 and V2 versions.

EAP

(Extensible Authentication Protocol)

A general protocol supporting multiple

authentication mechanisms. Unlike the PPP

authentication process, EAP does not negotiate a

specific authentication method such as PAP or

CHAP at the stage of LCP, but wait until the

authentication stage to make a choice based on

specific situations. This method allows the

authenticator to first send more requests to the

requesting terminal and determine which

mechanism to use after receiving a response.

Under the EAP method, the authenticator (for

example, MSCG) does not have to pay attention to

the authentication process, but instead directly

send EAP authentication request and response

transparently to the authentication server (for

example, AAA Server). The authenticator can

decide whether to allow user access only by

judging over the authentication result

(success/failure) returned by the authentication

server.

The user authorization methods used today usually include static user authorization and

dynamic user authorization. Static authorization is to pre-configure access limitation on

the AAA server under which the system issues network access authorization for users

when they become online and thus carries out strategic control over their access to

network; dynamic authorization is a process in which the AAA server dynamically

modifies the network access authorization for users when they become online and use

network services.

The charging modes used in real-world network operation mainly include: monthly fee

charging, duration based charging, traffic based charging and destination based charging.

Based on the methods of payment, the charging modes can be further divided into

prepaid charging and postpaid charging. The two accounting methods used to implement

such charging modes are: remote accounting and local accounting. Remote accounting

is to send the original accounting information from MSCG through RADIUS to AAA

server, which is then connected with the billing system to issue CDRs or bills; local



accounting is to store the original information at an accounting point through the local

protocol such as an internal interface and subsequently import such information through

file transfer into the accounting system. Local accounting is not a standalone accounting

method, and it is simply used for protection purposes in the event of remote accounting

failure.

To enhance accounting accuracy, MSCG supports real-time accounting capability, which

trigger periodically to send CDR data through RADIUS to AAA server on a real-time

basis.

To ensure accounting reliability and facilitate accounting settlement between networks,

MSCG supports accounting CDR copying functionality by which accounting CDRs are

simultaneously sent to two AAA servers.

2.1 PPP Authentication

2.1.1 Basic Principles

PPP is a point-to-point link layer protocol, which provides point-to-point encapsulation

and data transfer methods; If applied over Ethernet, PPP needs to use PPPoE to remake

one-time encapsulation, and negotiate point-to-point communication on the broadcast

link layer, including server discovery and Session ID confirmation; PPPoEoA is an

encapsulation made by PPPoE after bridging over ATM through RFC1483/2684; PPPoA

is PPP over ATM. PPP generally includes three negotiation phase: Link Control

Protocol (LCP) negotiation phase, authentication phase (for example, CHAP/PAP), and

NCP (for example, IPCP) negotiation phase.

When a user makes dialup connection, the user terminal and ISP provided MSCG (or

access server) negotiates link layer parameters at the LC stage, and then sends the

username and password to MSCG for CHAP/PAP authentication. MSCG can either

conduct local authentication or sends through RADIUS the username and password to

the remote AAA server for authentication. At the NCP (IPCP) negotiation phase after

authentication, MSCG allocates network layer parameters such as IP address to user

computers.

Subsequent to the three PPP negotiation phases, the user can send and receive

datagrams and use the network.

The access authentication process of PPPoE encompasses the PPP authentication

technology and enhances the negotiation over point-to-point communications on



broadcast links. The ensuing description is made based on the PPPoE protocol.

2.1.2 Details of Realization

Authentication System Architecture

In a PPPoE based authentication system, the network between PPPoE client and PPPoE

server is a layer 2 network over which the PPPoE server is responsible for terminating

the PPPoE client originated PPPoE message and using PPP to authenticate clients

request for PPP connection.

The PPPoE based authentication system architecture is shown in the Figure below:

Figure 2 PPPoE Based Authentication System Architecture

The PPPoE use access process using CHAP as an example is follows:



Figure 3 PPPoE Authentication Process

1) A PPPoE client sends a PADI message to the PPPoE server and starts PPPoE

access;

2) The PPPoE server sends a PADO message to the client;

3) In response, the client initiates a PADR request to the PPPoE server;

4) The PPPoE server generates a session ID and sends through PADS to the client;

5) PPP LCP negotiation is made between the client and PPPoE server to establish

link layer communications;

6) The PPPoE server sends a 128bit Challenge to the authentication client;

7) After receiving the challenge, the client first performs MD5 algorithm on password

and Challenge, and then send in the response to the PPPoE server;

8) The PPPoE server sends challenge, challenge-password and username through

RADIUS to the AAA server for authentication;

9) The AAA server determines whether the user is an authorized user based on user

information and then responds with authentication success/failure to the PPPoE

server. In the event of authentication success, the response carries the negotiation



parameters and user specific service properties as necessary to grant user

authorization. In the case of authentication failure, the process comes to an end.

10) The PPPoE server returns the authentication result to the client.

11) When making NCP (for example, IPCP) negotiation, the user obtains such

parameters as the planned IP address through the PPPoE server.

12) In the case of authentication success, the PPPoE server initiates an accounting start request to the RADIUS user authentication server.

13) The RADIUS user authentication server responds to the accounting start request.

By then, the user has passed authentication and received valid authorization, and as a

result, can conduct network services as usual.

2.2 WEB Authentication

Web authentication is an authenticator method under which an IPoE user (including

static user) accesses the web servers authentication page, and interactively enters

username and password to conduct identity authentication.


IPoE users can allocate IP address dynamically through DHCP or statically without using

DHCP. To facilitate unified user IP address planning and maintenance, IPoE users

mostly allocates IP addresses using DHCP. Unlike PPPoE users, the IPoE user access

network cannot dial up and enter username and password to MSCG for authentication

and authorization. Instead, the network can only apply for IP addresses in advance, but

in the case of users failing to obtain the authorization to access network and use services,

they shall submit to MSCG the username and password for authentication, and they are

allowed to use network services only after receiving IPoE user authentication and

authorization from MSCG. Based on the IPoE username and password generation

method, MSCG provides the following two authentication approaches:

1) Default username fast authentication: A user accesses the WEB page without

entering username and password, and directly submits for authentication; based on

user access physical location information (slot, port, VLAN/PVC and Option82),

MSCG generates username and password, and either sends them to the AAA

server for authentication or conducts local authentication by itself;

2) WEB authentication: A client uses the standard WEB browser (for example, IE); the

user enters and submits username and password on WEB page; then the WEB



server and device work together to carry out user authentication.

The default username authentication process is included in the WEB authentication

process. This paper focuses on the WEB authentication process.

Additionally, MSCG supports configuring the corresponding WEB server IP address

under the user authentication domain and enabling users in different authentication

domains to push the personalized mandatory WEB authentication page.


Authentication System Architecture

MSCG redirects customers HTTP request to the WEB server, and allows the customer

to enter username and password on PORTAL page to conduct authentication:

Figure 4 WEB Based Authentication System Architecture

WEB Access Authentication Process

Prior to WEB authentication, a user must obtain an IP address through DHCP and static

configuration. If configured as mandatory WEB authentication, the user only needs to

open the browser and access any web page; MSCG will automatically redirect the user to

PORTAL authentication page.

After the user submits username and password, MSCG collaborates with the WEB

server to conduct user authentication. The specific procedures taking DHCP user as an

example are as follows:



Figure 5 VLAN User Access Process (WEB Authentication)

(1)~(4) refers to the process in which a dynamic user obtains an IP address through

DHCP (an static user can manually configure IP address);

(5) The user accesses WEB servers authentication page, enters username and

password on the page, then clicks login button (in the case of MSCG generating

username in default, MSCG generates username and password in a specific format

based on user access physical location information such as slot, port, VLAN/PVC and

Option82) ;

(6) The WEB server notifies MSCG of user information through PORTAL Protocol;

(7) MSCG goes to the corresponding AAA server to authenticate the user;

(8) The AAA server returns authentication results to MSCG;

(9) MSCG notifies WEB server of authentication results;

(10) The WEB server notifies the user of authentication results through HTTP page;

(11) In the cases of authentication success, the user can access network resources as

usual.

2.3 Binding Authentication


Binding authentication is an authentication method under which MSCG automatically

generates username and password as per user access location information (slot number,



card number, port number, VLAN/PVC and DHCP Option82 information), and conducts

user authentication accordingly.

The binding authentication process further guarantees user service security since users

are unaware of the authentication process.


In binding authentication, the user computer sends an IP message to trigger off the

authentication process on MSCG (or MSCG triggers off the authentication process after

detecting through ARP that the user is online); MSCG generates username and

password as per user location information (slot number, card number, port number,

VLAN number, and DHCP Option82), and either sends such information through Radius

to the AAA server for authentication or directly conducts local authentication by itself.

2.4 802.1X authentication


802.1X Protocol was originated in the development and application of WLAN boasting

mobility and openness features. Therefore, it is necessary to exercise authentication

control over users port access in order to protect wireless spectrum resource utilization

and network security. The 802.1X is also applied in wired LANs to conduct user

management by way of user access port authentication control.

When a user goes online, the users access port is in Locked state; the user initiates a

request for authentication and gains access (usage rights) to the layer 2 networks after

passing authentication.


Authentication system architecture

The 802.1X based authentication system architecture is shown in the figure below:



Figure 6 802.1X Based Authentication System Architecture

In this architecture, the system consists of an authentication requestor, an authentication

and an authentication server in the tripartite structure. Authentication requestor

corresponds to client; authentication point corresponds to MSCG; authentication server

corresponds to AAA server.

The 802.1X Access Authentication Process

The 802.1X based authentication system can select different authentication algorithms

by leveraging EAP extension capability. Take EAP-MD5 as an example:

Figure 7 EAP-MD5 Authentication Method Interaction Diagram

The process is described as follows:

1) After the user and MSCG are physically connected, the user client sends to MSCG



an EAPoL-Start message (or likely a DHCP request message if the user is

dynamically allocated an IP address; or likely an ARP request message if the user is

manually allocated an IP address), and starts 802.1X access;

2) MSCG sends to client an EAP-Request/Identity message requesting the client to

send username;

3) The client responds to MSCGs request with an EAP-Response/Identity, including

username;

4) MSCG sends an Access-Request in the EAP Over RADIUS format which contains

the EAP-Response/Identity sent by client to MSCG, and submits username to the

RADIUS authentication server;

5) AAA server generates a 128 bit Challenge;

6) The AAA server responds to MSCG with an Access-Challenge which contains the

EAP-Request/MD5-Challenge, and sends to MSCG user the corresponding

Challenge;

7) MSCG sends to the authentication client through EAP-Request/MD5-Challenge, and

sends Challenge to the user;

8) After receiving the EAP-Request/MD5-Challenge, the client performs MD5 algorithm

on password and Challenge, and sends to MSCG the resulting Challenge-Password

in EAP-Response/MD5-Challenge;

9) MSCG sends Challenge-Password through Access-Request to the AAA server

which then conducts authentication;

10) The AAA server determines whether the user is an authorized user based on user

information and then responds with authentication success/failure to the MSCG. In

the event of authentication success, the response carries the negotiation parameters

and user specific service properties as necessary to grant user authorization.

11) MSCG responds to user within EAP-Success/EAP-Failure based on the

authentication result, and notifies the user of authentication result. In the event of

authentication failure, the process then comes to an end. In the case of success, go

ahead with subsequent authorization and accounting processes.



2.5 A Comparison of Authentication Methods

Table 3 An Comparison of Authentication Methods

Authentication Method

PPPoE Authentication

WEB Authentication

Binding Authentication

802.1X Authentication

Access control granularity

PPP connection VLAN user, physical port

VLAN user, physical port

Logical port

IP address allocation method

IPCP DHCP static DHCP static DHCP static (extension)

IP address allocation process

Authentication before allocation IP addresses

Allocating IP addresses before authentication

Allocating IP addresses before authentication

EAP authentication before DHCP address allocation; or DHCP address allocation before EAP authentication

Client support Business client (WinXP integration)

Standard browser

No special client needed

Vendors proprietary client (WinXP limited support)

Multicast support

Multicast message/packet may not be encapsulated through PPPoE

Support Support Support

Encapsulation overhead

PPP Encapsulation mega-packet fragmentation

Ethernet Encapsulation



Additional WLAN support

No No No Re-authentication mechanism

Key transfer

EAP



Authentication Method

PPPoE Authentication

WEB Authentication

Binding Authentication

802.1X Authentication

authentication

Protocol standard

Standard protocol

Proprietary protocol

Standard protocol

Standard authentication protocol

Working with RADIUS Server

Standard protocol

Standard protocol

Standard protocol

Standard protocol

Additional devices

RADIUS Server Web Server

RADIUS Server

RADIUS Server RADIUS Server

AS (EAP-SIM authentication)

User offline exception detection

LCP ECHO packet

WEB keep-alive detection

ARP detection

ARP detection Keep-alive mechanism

Re- authentication mechanism

Technical application status

Mature Mature Mature New technology

Additional service features

VPDN Support Free resources access in the past

Authentication interface advertisement service

Service selection Service customization

Free resources access in the past

Authentication interface advertisement service

No

Binding authentication can be conducted after the aforesaid authentication methods are

passed.



3 Authorization Technology and Realization

3.1 User Static Authorization


User static authorization refers to the action of granting authorization in the process of

user going online, and controlling the users access by way of service strategy. The

service strategy includes bandwidth, access authority, idle disconnection, user priority,

traffic regulation and QoS. The service strategy can be preconfigured under the users

domain, and when the user goes online, MSCG authorizes to the user the service

strategy under the domain; the service strategy can also be configured on the AAA

server, and when the user goes online, the AAA server sends the service strategy to the

user. In the event of any overlapping conflict between the service strategy under the

users domain and the service strategy configured on the AAA server, first select the

service strategy issued by the AAA server.

Accounting information can be acquired per user accessed service, duration and traffic.


The user static authorization process is shown in the figure below:

Figure 8 User Static Authorization Process



1) A user initiates to MSCG an online request;

2) MSCG conducts local authorization or initiates through RADIUS an authorization

request to the AAA server (the user authorization process and authentication

process bundled);

3) The AAA server returns user authorization results to MSCG;

4) MSCG responds to user online response results by allowing the user to go online

and authorizing the user to user network services.

3.2 User Dynamic Authorization


Dynamic authorization is an authorization method under which such property values as

User-Group, CAR and Policy-Name are rest on the AAA server when a user goes online,

and the AAA server sends them through CoA (Change of Authorization) to MSCG to

dynamically update users authorization information.


The user dynamic authorization process is shown in the figure below:

Figure 9 User Dynamic Authorization Process



1) When a user goes online, the AAA Server sends through CoA (Change of

Authorization) a user authorization information request to MSCG;

2) MSCG dynamically modifies the online users authorization information ;

3) MSCG returns COA results to the AAA Server;

4) The user uses network services as per the modified authorization phase; the user

will not go offline or get aware of any COA throughout the dynamic COA process.

4 Accounting Technology and Realization

4.1 Remote Accounting


MSCG supports remote accounting through the AAA server. After MSCG gets aware of a

user going offline, MSCG will automatically exchange accounting information with the

AAA server. All accounting information is kept in the AAA server from which the

accounting system directly extracts the original accounting information.

MSCG realizes RADIUS in strict compliance with the definitions of RFC2865, RFC2866

and RFC2869, and provides standard RADIUS accounting property and extension.

MSCG also supports interoperation with the industrys leading vendors such as Huawei

iTellin, Huawei CAMS, Asiainfo, Lianchuang, Tianfu Online, Zoom Networks, and

Shenzhen Galaxy to provide monthly subscription, duration, traffic, and service based

accounting.

When working together with the AAA server to conduct remote accounting, MSCG

supports duration and traffic based comprehensive prepaid services, and supports tariff

switchover and discount features of charging different tariffs for different types of access.




Figure 10 Remote Accounting Process

1) After a user passes authentication and authorization when going online, MSCG

sends through Radius an accounting start request to the AAA server;

2) The AAA server responds to MSCGs accounting request, indicating it is okay to

take user accounting action;

3) When the user goes offline, MSCG notifies the AAA server to stop accounting;

4) The AAA server stops user accounting action, and responds to MSCG with an

accounting stop response.

If MSCG fails to receive a response after sending an accounting message to the remote

AAA server, MSCG can keep the user online or take the user offline through

configuration; in default, MSCG takes the user offline after failing to start accounting.

4.2 Real-time Accounting


MSCG supports real-time accounting capability. Under real-time accounting, when a user

goes online, MSCG generates an accounting message to the server at a fixed time. By

virtue of real-time accounting, MSCG can minimize accounting irregularity time in the



event of losing communications with the server.


Figure 11 Real-Time Accounting Process

When a user goes online to use network services, MSCG sends accounting messages to

the AAA server on a real-time basis to enhance accounting accuracy. The time interval of

real-time accounting CDR transmission can be configure on MSCG. After receiving from

MSCG real-time accounting messages, the AAA server returns responses accordingly.

If MSCG fails to receive any response after sending a real-time accounting message to

the remote AAA server, MSCG can configure the times of resending a failed real-time

accounting message; in the case of resending failure, MSCG can keep the user online or

takes the user offline through configuration; in default, resend an real-time accounting

message three times, and keep the user online after real-time accounting failure.

4.3 Local Accounting Protection


The primary purpose of MSCG local accounting protection is to ensure neither losing

CDRs nor generating erroneous CDRs in the event of link failure (for example, AAA

server link breakdown). In the event of the AAA server becoming incapable of accounting,

storing CDRs locally is advisable; after the AAA server resumes to the normal state, the

accounting system can upload through TFTP the original CDR information to the



accounting server. At present, the local accounting information can meet duration and

traffic accounting requirements, but does not support prepaid services.


In the process of a user going online, accounting irregularity will arise if the AAA server

fails to receive accounting messages when the user is offline because MSCG and AAA

servers communications links break down. In such a circumstance, it is advisable for

MSCG to store CDRs locally and thus avoid such accounting irregularity. In practice, first

store the generated local CDRs in a local CDR cache; MSCGs local CDR cache can be

created or deleted by way of command. In the absence of local CDR cache, no local

CDR will be generated.

MSCG supports backing up the cached CDRs under the following three backup modes:

backup to CF cards, backup through TFTP to the CDR server or no backup. Backup can

be made at a fixed time or through manual operation. Cached CDRs can be backed up to

CF card or CDR server; CDRs in CF card can also be backed up to CDR server. MSCG

supports sending an alarm to the network administration server when the utilization rate

of CDRs in cache or CF card exceeds the preset alarm threshold value.

4.4 Accounting Copy


Accounting message copy refers to the capability of synchronously sending the

accounting information to two AAA servers in the accounting process, and keeping both

servers waiting for response. The accounting message copy functionality is mainly used

where the original accounting information needs to be store in multiple locations (for

example, in the case of multiple carriers or operators networking together). In such a

case, an accounting message needs to be synchronously sent to two AAA servers, and

will be used as the original accounting information in subsequent settlement.


The accounting message copying features supported by MSCG include physical

accounting and two-level accounting.

1) Physical Accounting



Physical accounting is to install and configure an accounting copy server on the user

accessed MSCG port, and find out the accounting copy server on the corresponding port

after a user goes online to copy the accounting messages to the accounting server.

2) Two-Level Accounting

Two-level accounting is to install and configure a primary accounting server and an

accounting copy server which will copy the accounting messages to the accounting copy

server in the accounting process.

5 Typical Application Cases

5.1 Typical PPPoE User Networking Applications

Figure 12 Typical PPPoE User Networking Diagram

After MSCG receives users request for online connection when the user goes online

through PPPoE dialup, MSCG will forward such request to the AAA server for

authentication and authorization. In the absence of any AAA server in a small network,

MSCG can directly conduct local authentication and authorization. After passing

authentication and authorization, the user can access the external network, and user

authorized network services. User accounting messages can be send through RADIUS

to the AAA server on a real-time basis, and the AAA server and carriers accounting

system will carry out original CDR interaction. In the case of any irregularity in links with



the AAA server, MSCG enables the local accounting protection feature, and temporarily

save the generated CDRs in local storage. The accounting system can upload through

TFTP the accounting original CDR information stored locally by MSCG to the accounting

server.

5.2 Typical IPoE User Networking Application

Figure 13 Typical DHCP User Networking Diagram

An IPoE user usually gets an IP address through DHCP; when opening the IE browser,

the user will be redirected by MSCG to the WEB server; the user then enters username

and password on Portal page; the WEB server sends through Portal Protocol the

username and password to MSCG for authentication; MSCG sends username and

password through RADIUS to the AAA server for authenticating and authorizing (in a

small network, MSCG can also directly conduct local authentication and authorization);

after passing authentication and authorization, the user can use network services; any

accounting message will be send through RADIUS to the AAA server on a real-time basis;

in the case of remote AAA link failure, enable MSCG local accounting protection feature

to ensure no losses of CDR.

In multi-play applications, IPTV STB (Set-Top-Box) cannot open the IR browser through

manual interaction after getting an IP address through DHCP; on WEB Portal page,

users enter username and password information; MSCG then performs binding



authentication for such IPoE users, and automatically generates username and

password as per user access location information (slot number, card number, port

number, VLAN/PVC, and DHCP Option82) for remote AAA authentication (or local

authentication).

5.3 Multi-Play Service Typical Networking Applications

Figure 14 Typical Multi-Play Service Networking Diagram

In typical multi-play service applications, the home gateway integrated access device

(IAD) is connected underneath to IPTV STB, VoIP terminals and HIS Service PC

terminals to expand IPTV, VoIP and HIS services respectively. STB and VoIP terminals

get their IP addresses through DHCP; MSCG generally adopts bundle authentication; PC

terminals use PPP dialup connection and PPP authentication; PC terminals can also

allocates IP addresses using DHCP and adopt WEB authentication. After passing

authentication, the user terminals get their corresponding service entitlement; in typical

multi-play applications, the accounting method is monthly fee per home or IAD.



Appendix Abbreviation

Abbreviations Full spelling MSCG Multi-Service Control Gateway RADIUS Remote Authentication Dial-In User Service PAP Password Authentication Protocol CHAP Password Changing Protocol EAP Extensible Authentication Protocol CAMS Comprehensive Access Management Server CoA Change of Authorization STB Set-Top-Box HIS High Speed Internet service IAD Integrated Access Device

Aaa

Documents

Transcript of Aaa