BRAS and AAA

IntroductionRADIUS(AAA) • Remote Authentication Dial In User Service (RADIUS) is a networking protocol that provides centralized

Authentication, Authorization, and Accounting (AAA) management for computers to connect and use a network service.RADIUS is a client/server protocol that runs in the application layer, using UDP as transport. RADIUS servers use the AAA concept to manage network access in the following two-step process, also known as an "AAA transaction". AAA stands for “authentication, authorization and accounting”.

• Policy/portal server—A policy/portal server is the network element that provides the service control that allows for the management and modification of services in real time.

• Billing server—The billing server maintains user account information, including the amount of credit remaining for prepaid services. When a user initiates services, the ISG contacts the billing server to determine if the user has credit available.

• AAA server—In IP deployments, the network utilizes a single authentication, authorization, and accounting (AAA) server. The AAA server maintains user authentication information and information about services available to users. When the ISG receives a username and password, it forwards them to the AAA server for authentication. When a user activates a service, the ISG contacts the AAA server, which replies to the ISG with information on the service.

• CPE—The customer premises equipment (CPE) router is a small router such as the Cisco 800 series router that is used either as a bridge or to initiate IP connections from the customer PC to the ISG.

• A broadband remote access server (BRAS, B-RAS or BBRAS) routes traffic to and from broadband remote access devices such as digital subscriber line access multiplexers (DSLAM) on an Internet service provider's (ISP) network. BRAS can also be referred to as a Broadband Network Gateway (BNG).The BRAS sits at the core of an ISP's network, and aggregates user sessions from the access network. It is at the BRAS that an ISP can inject policy management and IP Quality of Service (QoS).

Access models• One of the decisions to be made when running Bras is the type of access that is

preferred. There are 2 key options which is PPPoE (PPP over Ethernet) or IPoE.

• PPPoE sessions are triggered by the reception of a PADI and IP sessions are created by using DHCP as a session trigger.

Introduction

IPoE Call Flow

Flow 1 •A DHCP DISCOVERY message is initiated by subscriber. •An intermediate device (DSLAM or switch) populates DHCP Option-82 information to identify the subscriber's

physical location. •The ISG interface is configured to start a new session using DHCP control traffic. •Upon starting, the policy starts default service and authorizes the session based on network identifiers.

Flow 2 •The ISG issues an Accept Request to authorize the session at AAA. The request includes DHCP option 82

information and the client's MAC address as a username.

Flow 3 •Upon successful identity verification, the AAA server responds with an Access Request, which includes the user

profile and services to be activated. If the AAA server sends an Access Reject message, it means that user authorization failed; the L4 Redirect service will be activated and the subscriber will be forced to log into the account.

Flow 4 •Assuming that services to be activated for the session are not already cached on the ISG, the ISG sends an Access

Request to the AAA server to download the service definition.

Flow 5 •TAL is successful, and the DHCP module sends a DHCP OFFER message to the DHCP client.

Flow 6 •Accounting Start Record begins for the parent session and service.

Flow 7 •The ISG assigns an IP address to the client.

Authentication, Authorization and Accounting

• The user or machine sends a request to a Remote Access Server (RAS) to gain access to a particular network resource using access credentials. The credentials are passed to the RAS device via the link-layer protocol - for example, Point-to-Point Protocol (PPP) in the case of many dialup or DSL providers or posted in an HTTPS secure web form.

• In turn, the RAS sends a RADIUS Access Request message to the RADIUS server, requesting authorization to grant access via the RADIUS protocol.

• This request includes access credentials, typically in the form of username and password or security certificate provided by the user. Additionally, the request may contain other information which the RAS knows about the user, such as its network address or phone number, and information regarding the user's physical point of attachment to the RAS.

• The RADIUS server checks that the information is correct using authentication schemes like PAP, CHAP or EAP. The user's proof of identification is verified, along with, optionally, other information related to the request, such as the user's network address or phone number, account status and specific network service access privileges. Historically, RADIUS servers checked the user's information against a locally stored flat file database.

The RADIUS server then returns one of three responses to the RAS : 1) Access Reject, 2) Access Challenge or 3) Access Accept.

• Access Reject - The user is unconditionally denied access to all requested network resources. Reasons may include failure to provide proof of identification or an unknown or inactive user account.

• Access Challenge - Requests additional information from the user such as a secondary password, PIN, token or card. Access Challenge is also used in more complex authentication dialogs where a secure tunnel is established between the user machine and the Radius Server in a way that the access credentials are hidden from the RAS.

• Access Accept - The user is granted access. Once the user is authenticated, the RADIUS server will often check that the user is authorised to use the network service requested.

Authentication, Authorization and Accounting

• When a client is configured to use RADIUS Accounting, at the start of service delivery it will generate an Accounting Start packet

• At the end of service delivery the client will generate an Accounting Stop packet.

• The NAS sends an accounting-request to the forwarding server.

• Finally, when the user's network access is closed, the NAS issues a final Accounting Stop record (a RADIUS Accounting Request packet containing an Acct-Status-Type attribute with the value "stop") to the RADIUS server, providing information on the final usage in terms of time, packets transferred, data transferred, reason for disconnect and other information related to the user's network access.

Authentication, Authorization and Accounting

Packet structure

• RADIUS packet data format.

• The fields are transmitted from left to right, starting with the code, the identifier, the length, the authenticator and the attributes.

• RADIUS Codes (decimal) are assigned as follows:Code Assignment1 Access-Request2 Access-Accept3 Access-Reject4 Accounting-Request5 Accounting-Response11 Access-Challenge12 Status-Server (experimental)13 Status-Client (experimental)255 Reserved

• The Identifier field aids in matching requests and replies.

Authentication, Authorization and Accounting

• RADIUS has been officially assigned UDP ports 1812 for RADIUS Authentication and 1813 for RADIUS Accounting by the Internet Assigned Numbers Authority (IANA). However, prior to IANA allocation of ports 1812 and 1813, ports 1645 and 1646 (authentication and accounting, respectively) were used unofficially and became the default ports assigned by many RADIUS Client/Server implementations of the time.

Authentication, Authorization and Accounting

Attribute value pairs The RADIUS Attribute Value Pairs (AVP) carry data in both the request and the response for the authentication, authorization, and accounting transactions. The length of the radius packet is used to determine the end of the AVPs.

AVP Assignment1 User-Name2 User-Password3 CHAP-Password4 NAS-IP-Address5 NAS-Port6 Service-Type7 Framed-Protocol8 Framed-IP-Address9 Framed-IP-Netmask10 Framed-Routing11 Filter-Id12 Framed-MTU13 Framed-Compression14 Login-IP-Host15 Login-Service

16 Login-TCP-Port17 (unassigned)18 Reply-Message19 Callback-Number20 Callback-Id21 (unassigned)22 Framed-Route23 Framed-IPX-Network24 State25 Class26 Vendor-Specific27 Session-Timeout28 Idle-Timeout29 Termination-Action30 Called-Station-Id31 Calling-Station-Id32 NAS-Identifier33 Proxy-State34 Login-LAT-Service35 Login-LAT-Node36 Login-LAT-Group

37 Framed-AppleTalk-Link38 Framed-AppleTalk-Network39 Framed-AppleTalk-Zone40 Acct-Status-Type41 Acct-Delay-Time42 Acct-Input-Octets43 Acct-Output-Octets44 Acct-Session-Id45 Acct-Authentic46 Acct-Session-Time47 Acct-Input-Packets48 Acct-Output-Packets49 Acct-Terminate-Cause50 Acct-Multi-Session-Id51 Acct-Link-Count52-59 (reserved for accounting)60 CHAP-Challenge61 NAS-Port-Type62 Port-Limit63 Login-LAT-Port

• The following is the "debug aaa authentication" output from the router.

• User Access Verification Username: Jun 3 12:13:01.422 EDT: AAA: parse name=tty72 idb type=-1 tty=-1 Jun 3 12:13:01.422 EDT: AAA: name=tty72 flags=0x11 type=5 shelf=0 slot=0 adapter=0 port=7 2 channel=0 Jun 3 12:13:01.422 EDT: AAA/MEMORY: create_user (0x82A1CA18) user='NULL' ruser='NULL' ds0 =0 port='tty72' rem_addr='10.20.1.1' authen_type=ASCII service=LOGIN priv=15 initial_task_ id='0' Jun 3 12:13:01.422 EDT: AAA/AUTHEN/START (4245677897): port='tty72' list='' action=LOGIN service=LOGIN Jun 3 12:13:01.422 EDT: AAA/AUTHEN/START (4245677897): using "default" list Jun 3 12:13:01.426 EDT: AAA/AUTHEN/START (4245677897): Method=tacacs+ (tacacs+)te Jun 3 12:13:01.426 EDT: TAC+: send AUTHEN/START packet ver=192 id=4245677897 Jun 3 12:13:01.638 EDT: TAC+: ver=192 id=4245677897 received AUTHEN status = GETUSER Jun 3 12:13:01.638 EDT: AAA/AUTHEN (4245677897): status = GETUSERst1 Password: Jun 3 12:13:03.746 EDT: AAA/AUTHEN/CONT (4245677897): continue_login (user='(undef)') Jun 3 12:13:03.746 EDT: AAA/AUTHEN (4245677897): status = GETUSER Jun 3 12:13:03.746 EDT: AAA/AUTHEN (4245677897): Method=tacacs+ (tacacs+) Jun 3 12:13:03.746 EDT: TAC+: send AUTHEN/CONT packet id=4245677897 Jun 3 12:13:03.950 EDT: TAC+: ver=192 id=4245677897 received AUTHEN status = GETPASS Jun 3 12:13:03.950 EDT: AAA/AUTHEN (4245677897): status = GETPASS Jun 3 12:13:06.318 EDT: AAA/AUTHEN/CONT (4245677897): continue_login (user='test1') Jun 3 12:13:06.318 EDT: AAA/AUTHEN (4245677897): status = GETPASS Jun 3 12:13:06.322 EDT: AAA/AUTHEN (4245677897): Method=tacacs+ (tacacs+) Jun 3 12:13:06.322 EDT: TAC+: send AUTHEN/CONT packet id=4245677897 Jun 3 12:13:06.523 EDT: TAC+: ver=192 id=4245677897 received AUTHEN status = PASS Jun 3 12:13:06.523 EDT: AAA/AUTHEN (4245677897): status = PASS

BRAS_KB#sh radius authentication statistics RADIUS Authentication Statistics -------------------------------- Statistic 202.159.219.230 203.94.243.81------------------- --------------- -------------UDP Port 1812 1812 Round Trip Time 3 1 Access Requests 133338335 0 Rollover Requests 0 18549 Retransmissions 221205 2458 Access Accepts 22052926 14673 Access Rejects 111266861 2693 Access Challenges 0 0 Malformed Responses 0 0 Bad Authenticators 0 0 Requests Pending 0 0 Request Timeouts 239760 3639 Unknown Responses 0 0 Packets Dropped 0 0

Statistics baseline set MON FEB 27 2012 12:17:46 IST

BRAS_KB#sh radius acco statistics RADIUS Accounting Statistics ---------------------------- Statistic 202.159.212.59------------------- --------------UDP Port 1646 Round Trip Time 5 Requests 12925957 Start Requests 6459833 Interim Requests 0 Stop Requests 6466124 Reject Requests 0 Rollover Requests 0 Retransmissions 90336 Responses 12918408 Start Responses 6456636 Interim Responses 0 Stop Responses 6461772 Reject Responses 0 Malformed Resp 0 Bad Authenticators 0 Requests Pending 0 Request Timeouts 112828 Unknown Responses 0 Packets Dropped 5735

Statistics baseline set MON FEB 27 2012 12:17:46 IST