No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

Configuration Guide - Security

CloudEngine 8800, 7800, 6800, and 5800 V200R005C10

This document describes the configurations of Security, including ACL, local attack defense, MFF, attack defense, traffic suppression and storm control, ARP security, Port security, DHCP snooping, ND snooping, PPPoE+, IPSG, SAVI, separating the management plane from the service plane, security risks.
Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
RADIUS

RADIUS

Overview of RADIUS

RADIUS uses the client/server model in distributed mode and protects a network from unauthorized access. It is often used in network environments that require high security and control of remote user access. It defines the User Datagram Protocol (UDP)-based RADIUS packet format and message transmission mechanism, and specifies UDP ports 1812 and 1813 as the authentication and accounting ports, respectively.

At first, RADIUS was only an AAA protocol used for only dial-up users. Later on, RADIUS adapted to more diverse user access modes, such as Ethernet. RADIUS provides the access service through authentication and authorization, and records the network resources used by users through accounting.

RADIUS has the following characteristics:

  • Client/Server model

    • RADIUS client: RADIUS clients run on the network access servers (NAS) to transmit user information to the specified RADIUS server and process requests (for example, accept or reject user access) based on the responses from the server. RADIUS clients can be located at any node on a network.

      As the RADIUS client, the device supports:

      • Standard RADIUS protocol and its extensions

      • Huawei-developed private attributes

      • Active detection on the RADIUS server status

      • Retransmission of Accounting Stop packets in the local buffer

      • Automatic switching function of the RADIUS server

    • RADIUS server: RADIUS servers run on central computers and workstations to maintain user authentication and network service access information. The servers receive connection requests from users, authenticate the users, and send responses (indicating that the requests are accepted or rejected) to the clients. RADIUS servers need to maintain three databases, as shown in Figure 1-2.

      Figure 1-2 Databases maintained by the RADIUS servers

    • Users: Stores user information such as user names, passwords, protocols, and IP addresses.
    • Clients: Stores RADIUS client information such as the shared key and IP address of an access device.
    • Dictionary: Stores the attributes in the RADIUS protocol and their value descriptions.
  • Security mechanism

    RADIUS clients and servers exchange authentication messages using shared keys that cannot be transmitted through networks, enhancing information exchange security. In addition, to avoid theft on an insecure network, passwords are encrypted using shared keys before being transmitted.

  • Good scalability

    RADIUS packets consist of the packet header and a certain number of attributes. After new attributes are added to RADIUS packets, its implementation remains unchanged.

RADIUS Packets

RADIUS Packet Format

RADIUS uses UDP packets to transmit information. Figure 1-3 shows the RADIUS packet format.

Figure 1-3 RADIUS packet format

Fields in a RADIUS packet include:
  • Code (1 byte): Describes the RADIUS packet type. The value 1 indicates an Access-Request packet, and the value 2 indicates an Access-Accept packet.
  • Identifier (1 byte): Used to match request packets and reply packets, and to detect the request packets retransmitted within a certain period. After a client sends a request packet, the server sends a reply packet with the same Identifier value as the request packet.
  • Length (2 bytes): Specifies the RADIUS packet length. Bytes exceeding the specified length value are treated as padding and ignored on the receiver. If the length of a received packet is smaller than the Length value, the packet is discarded.
  • Authenticator (16 bytes): Used to verify the reply packets sent by the RADIUS server and encrypt user password.
  • Attribute (variable length): Field of a packet carrying authentication, authorization, and accounting information and providing configuration details of request and reply packets. An Attribute field may contain multiple attributes, each of which consists of the Type, Length, and Value fields.

    • Type (1 byte): Indicates the attribute type. The value range is from 1 to 255.
    • Length: Indicates the length of an attribute (including type, length, and attribute). The length is measured in bytes.
    • Value: Indicates the attribute information. The format and content are dependent on Type and Length. The maximum length is 253 bytes.
RADIUS Packet Type

RADIUS defines 16 types of packets. These packets can be categorized into authentication packets, accounting packets, and authorization packets, which are described in Table 1-1, Table 1-2, and Table 1-3.

Table 1-1 RADIUS authentication packets

Packet Name

Description

Access-Request

This is the first packet transmitted in a RADIUS interaction process. This packet carries user authentication information, such as user name and password. The Access-Request packet is sent from the RADIUS client to the RADIUS server, which then determines whether a user is allowed to access the network according to the user information carried in this packet.

Access-Accept

If all attributes in the Access-Request packet are acceptable, the RADIUS server considers that the user passes the authentication and sends this packet to the client. After receiving this packet, the client grants the network access rights to the user.

Access-Reject

If any attribute in the Access-Request packet is unacceptable, the RADIUS server considers that the user fails the authentication and sends this packet to the client.

Access-Challenge

During an Extensible Authentication Protocol (EAP) authentication, when the RADIUS server receives an Access-Request packet carrying the user name, it generates a random MD5 challenge and sends the MD5 challenge to the client in this packet. After the client encrypts the user password using the MD5 challenge, the client sends the encrypted password in an Access-Request packet to the RADIUS server. The RADIUS server compares the encrypted password received from the client with the locally encrypted password. If they are the same, the server considers the user valid.

Table 1-2 RADIUS accounting packets

Packet Name

Description

Accounting-Request (Start)

If the client uses RADIUS accounting, the client sends this packet to the server before accessing network resources.

Accounting-Response (Start)

After receiving and recording the Accounting-Request (Start) packet, the server returns this packet to the client.

Accounting-Request (Stop)

When a user goes offline voluntarily or is forcibly disconnected, the client sends this packet carrying the network resource usage information (including online duration and number of incoming/outgoing bytes) to the server, requesting the server to stop accounting.

Accounting-Response (Stop)

After receiving an Accounting-Request (Stop) packet, the server sends this packet to the client.

Accounting-Request (Interim-update)

If the accounting server fails to receive the Accounting-Request (Stop) packet, the server cannot stop accounting for the user. To address this problem, configure interim accounting on the client. The client then periodically sends accounting packets to the server. If the server stops receiving these packets, it stops accounting for the user.

Accounting-Response (Interim-update)

After receiving an Accounting-Request (Interim-update) packet, the server returns this packet to the client.

Table 1-3 RADIUS authorization packets

Packet Name

Description

CoA-Request

When the administrator needs to modify the rights of an online user (for example, prohibit the user from accessing a website), the server sends this packet to the client, requesting the client to modify the user rights.

CoA-ACK

If the client successfully modifies the user rights, the client sends this packet to the server.

CoA-NAK

If the client cannot modify the user rights, the client sends this packet to the server.

DM-Request

When the administrator needs to disconnect a user, the server sends this packet to the client, requesting the client to disconnect the user.

DM-ACK

If the client successfully disconnects the user, the client sends this packet to the server.

DM-NAK

If the client cannot disconnect the user, the client sends this packet to the server.

RADIUS Interaction Process

RADIUS Authentication, Authorization, and Accounting

Access devices function as RADIUS clients by collecting user information, including user names and passwords, and sending the information to the RADIUS server. The RADIUS server authenticates users according to the information, after which it performs authorization and accounting for the users. Figure 1-4 shows information exchanged between a user, the RADIUS client, and the RADIUS server.

Figure 1-4 RADIUS authentication, authorization, and accounting process

The following describes the process shown in Figure 1-4:

  1. A user sends a connection request carrying the user name and password to the RADIUS client (access device).
  2. The RADIUS client sends an Access-Request packet containing the user identity information to the RADIUS server according to the user name and password.
  3. The RADIUS server verifies the user identity:

    • If the user identity is valid, the RADIUS server returns an Access-Accept packet to the RADIUS client. The Access-Accept packet contains authorization information.
    • If the user identity is invalid, the RADIUS server returns an Access-Reject packet to the RADIUS client to reject access from the user.
  4. The RADIUS client notifies the user of whether authentication is successful.
  5. The RADIUS client permits or rejects the user according to the authentication result. If the user is permitted, the RADIUS client sends an Accounting-Request (Start) packet to the RADIUS server.
  6. The RADIUS server sends an Accounting-Response (Start) packet to the RADIUS client and starts accounting.
  7. The user starts to access network resources.
  8. (Optional) If interim accounting is enabled, the RADIUS client periodically sends Accounting-Request (Interim-update) packets to the RADIUS server, preventing incorrect accounting result caused by unexpected user disconnection.
  9. (Optional) The RADIUS server returns Accounting-Response (Interim-update) packets and performs interim accounting.
  10. The user sends a logout request.
  11. The RADIUS client sends an Accounting-Request (Stop) packet to the RADIUS server.
  12. The RADIUS server sends an Accounting-Response (Stop) packet to the RADIUS client and stops accounting.
  13. The RADIUS client notifies the user of the processing result, and the user stops accessing network resources.
CoA

Change of Authorization (CoA) allows the administrator to change the right of an authenticated online user through RADIUS. For example, a VLAN ID can be delivered to some access users through CoA packets. In this way, they can belong to the same VLAN no matter which interfaces they connect to. Figure 1-5 shows the CoA interaction process.

Figure 1-5 CoA interaction process

The following describes the process shown in Figure 1-5:

  1. The RADIUS server sends a CoA-Request packet to the RADIUS client according to service information, requesting the client to modify user authorization information. The CoA-Request packet may contain the policy name (configured on the RADIUS client) or ACL rules.
  2. The RADIUS client modifies user authorization information according to the CoA-Request packet without disconnecting the user.
  3. The RADIUS client returns a CoA-ACK or CoA-NAK packet.
    • If the authorization information is modified (for example, the policy name in the CoA packet is the same as that configured on the client), the RADIUS client returns a CoA-ACK packet to the RADIUS server.
    • If the authorization information cannot be modified, the RADIUS client returns a CoA-NAK packet to the RADIUS server.
DM

When a user needs to be disconnected forcibly, the RADIUS server sends a Disconnect Message (DM) to the RADIUS client. Figure 1-6 shows the DM interaction process.

Figure 1-6 DM interaction process

The following describes the process shown in Figure 1-6:

  1. On the RADIUS server, the administrator forcibly disconnects a user. The RADIUS server sends a DM Request packet to the RADIUS client, requesting the client to disconnect the user.
  2. When receiving the DM Request packet, the RADIUS client requests the user to go offline.
  3. The RADIUS client returns a DM ACK or DM NAK packet.

    • If the user successfully goes offline, the RADIUS client returns a DM ACK packet to the RADIUS server.
    • If the user cannot go offline, the RADIUS client returns a DM NAK packet to the RADIUS server.
Translation
Download
Updated: 2019-04-20

Document ID: EDOC1100074765

Views: 23733

Downloads: 93

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next