RADIUS Attribute Prohibition, Conversion, and Default Carrying Status

RADIUS is widely applied on networks because it is simple, flexible, and extensible. However, these same characteristics lead vendors to define RADIUS attributes differently and develop proprietary attributes. RADIUS interconnection between different vendor devices often suffers attribute compatibility problems. Huawei NetEngine 8000 Fs solve this problem by supporting flexible configuration, prohibition, and conversion of RADIUS attributes, enhancing attribute compatibility between different vendor devices.

RADIUS server vendors set different limits on the number of RADIUS attributes carried in a packet. For example, the RADIUS servers manufactured by some vendors can process a packet carrying up to 50 RADIUS attributes. The RADIUS servers cannot properly process packets exceeding this number. NetEngine 8000 Fs are configurable to carry or not carry specific RADIUS attributes in packets to be sent to RADIUS servers.

The commands for attribute prohibition, conversion, and carrying are all configured in the RADIUS server group view. The commands for attribute prohibition and conversion take effect on packets in the sending and receiving directions of a RADIUS server group, but the commands controlling the attribute carrying status take effect only on packets in the sending (from BRAS to RADIUS server) direction.

RADIUS Attribute Prohibition

Normally, a RADIUS server interconnects with multiple BRASs, which may be from different vendors. If the BRASs of some vendors require the RADIUS server to deliver an attribute to support a specified feature, whereas the BRASs from other vendors do not support the delivered attribute, parsing the attribute fails. Likewise, when a Huawei BRAS connects to RADIUS servers of other vendors, some RADIUS servers may require that the Huawei BRAS send attributes that may not be processed by other RADIUS servers. If other RADIUS servers receive these attributes, a processing error occurs. NetEngine 8000 Fs provide the following configuration commands in a RADIUS server group, preventing NetEngine 8000 Fs from sending specific attributes or allowing NetEngine 8000 Fs to ignore specific attributes in received packets.

Commands:

radius-attribute disable attr-description { receive | send } *

radius-attribute disable attr-description { access-request | access-accept | account [ start ] } *

radius-attribute disable attr-description { ip forbid-ip | string forbid-string | bin forbid-bin-value | integer integer-value } receive

Parameters:

  • attr-description: name of a prohibited RADIUS attribute
  • forbid-ip: prohibited IP address
  • forbid-string: prohibited character string
  • forbid-bin-value prohibited value (in hexadecimal notation) in the bin format
  • integer-value: prohibited integer

To allow the preceding commands to take effect, the radius-server attribute translate command must be run in the RADIUS server group view.

If the preceding commands are not run, NetEngine 8000 Fs support all the attributes listed in "Attributes Carried in RADIUS Packets" when handling protocol packets. If the preceding commands are run, NetEngine 8000 Fs do not encapsulate the specified attributes when sending packets, and ignore the specified attributes when receiving packets.

RADIUS Attribute Conversion

NAS-Port-Id (87) is used to identify the location of the user. The attribute is defined as a string in RADIUS standards, but the structure of the string is not specified. Therefore, the formats defined for this attribute vary among the RADIUS servers of different carriers. NetEngine 8000 Fs provide a flexible attribute conversion mechanism to meet the requirements of carriers.

NetEngine 8000 Fs support attribute conversion in both sending and receiving directions. In the sending direction, if attribute A is converted to attribute B, an NetEngine 8000 F encapsulates the attribute type of A but attribute content and format of B before sending packets. In the receiving direction, if attribute A is converted to attribute B and received by an NetEngine 8000 F, the NetEngine 8000 F parses it as attribute B. The attribute conversion commands are as follows:

radius-attribute translate src-attr-description dest-attr-description { receive | send } *

radius-attribute translate src-attr-description dest-attr-description { access-request | access-accept | account } *

radius-attribute translate extend src-attr-description dest-attr-description { access-request | access-accept | account } *

radius-attribute translate extend <src-attr-description vendor-specific dest-vendor-id dest-sub-attr-id { access-request | account } *

radius-attribute translate extend vendor-specific src-vendor-id src-sub-attr-id dest-attr-description access-accept

Parameters:

  • src-attr-description: name of an attribute to be converted
  • dest-attr-description: name of an attribute after conversion
  • dest-vendor-id vendor ID attribute number after conversion
  • dest-sub-attr-id: vendor ID sub-attribute number after conversion
  • src-vendor-id: vendor ID attribute number to be converted
  • src-sub-attr-id vendor ID sub-attribute number to be converted

To allow the preceding commands to take effect, the radius-server attribute translate command must be run in the RADIUS server group view.

Attribute Conversion Rules:

  1. Attribute conversion configuration requires the same or compatible data types.

    RADIUS attributes can be integer, string, IP address, or text data type. The string and text types are compatible, and integer and IP address types are compatible. The attributes before and after conversion must belong to the same or a compatible type. For example, User-name (1) can be converted to NAS-Identifier (32) because they are both of the string type, and Server-Type (6) can be converted to Framed-Protocol (7) because they are both of the integer type. User-name (1) cannot be converted Service-Type (6) because they are of different types.

  2. Conversion restrictions with and without the extend keyword:

    If the extend keyword is not carried in a command, the source and destination attributes can be public or vendor-specific private attributes. If the extend keyword is carried in a command, the source and destination attributes can only be vendor-specific private attributes. Under the same server group, attribute conversions with and without the extend keyword cannot both be configured.

  3. If the attribute to be converted is a private attribute in the sending direction, only the configuration carrying the extend keyword takes effect.

    For example, the first configuration takes effect whereas the second configuration does not.

    radius-attribute translate extend hw-qos-profile-name hw-domain-name account

    radius-attribute translate hw-qos-profile-name hw-domain-name account

  4. Attribute conversion in the sending direction takes effect only in packets supporting both the source and target attributes.

    For example, the Filter-Id (11) attribute is supported only in accounting request packets, not in authentication request packets. The Calling-Station-Id (31) attribute is supported both in accounting and authentication request packets.

    After the radius-attribute translate filter-id calling-station-id send or radius-attribute translate filter-id calling-station-id access-request account command is run, the Filter-Id (11) attribute can only be converted and sent in accounting request packets and cannot be converted or sent in authentication request packets.

    This limitation has exceptions. For details, see point 5.

  5. Attribute conversion in the sending direction specifies the specialty of the destination attributes through the vendor ID and sub-attribute ID attributes.

    Command: radius-attribute translate extend src-attr-description vendor-specific dest-vendor-id dest-sub-attr-id { access-request | account } *

    When the parameters dest-vendor-id and dest-sub-attr-id are not pre-defined attributes on a device (pre-defined attributes can be identified by a device and queried using the display radius-attribute command), attribute conversion is special. The destination attribute ID is the same as the configured parameters dest-vendor-id and dest-sub-attr-id, but the content in the destination attribute is the same as the content of the source attribute (src-attr-description). This mode allows the private attributes of an original vendor to be converted to any vendor's private attributes that are not pre-defined on a device.

  6. Attribute conversion in the receiving direction takes effect only in packets supporting destination attributes.

    For example, the HW-Policy-Route (HUAWEI-87) attribute is supported in Access-Accept packets but not in COA messages. The Acct-Interim-Interval(85) attribute is supported both in Access-Accept packets and COA messages. After the radius-attribute translate acct-interim-interval hw-policy-route receive command is run, attribute conversion takes effect only in Access-Accept packets. In COA packets, attribute conversion does not take effect, meaning that the Acct-Interim-Interval(85) attribute is processed in the form of itself.

  7. Attribute conversion in the receiving direction generally requires that the source attribute is a device pre-defined attribute.

    The source attribute must be a device pre-defined attribute (namely, an attribute that can be identified by a device and queried using the display radius-attribute command). Through configuration, a private attribute that is not pre-defined can also be converted into a pre-defined attribute that can be processed by a device.

    • Run the radius-attribute translate extend vendor-specific src-vendor-id src-sub-attr-id dest-attr-description access-accept command to configure src-vendor-id- and src-vendor-id-based private attribute conversion that is not pre-defined by a device.
    • Run the radius-attribute vendor vendor-id enable command to enable an NetEngine 8000 F to process private attributes that are pre-defined.

Examples of Common Attribute Conversion Applications

  • Conversion of the Same Attribute

    This is the most common application of RADIUS attribute conversion. This conversion allows attribute formats required by different carriers to be compatible. The following attribute conversions are possible:
    • NAS-Port (5): can be converted to HW-Own-NAS-Port-New, HW-Own-NAS-Port-QinQ, or HW-Own-NAS-Port-CID.
    • NAS-Identifier (32): can be converted to HW-Own-NAS-Identify-SIM.
    • Calling-Station-Id (31): can be converted to HW-Own-Calling-Station-Id-Old.
    • NAS-Port-Id (87): can be converted to HW-Own-NAS-Port-Identify-Old or HW-Own-NAS-Port-Id-Uppercase.
  • Conversion Among Different Attributes

    This conversion aims to improve the compatibility of RADIUS implementation on different vendor devices. The conversion can be performed when the previous rules of attribute conversion are met. The following are usage examples of such conversion.

    • In the receiving direction

      For example, an NetEngine 8000 F delivers the priority of a management user through the private attribute HW-Exec-Privilege (26-29), whereas another vendor's device delivers it through the Login-service (15) attribute. When the and the vendor's device use the same RADIUS server on the network, the carrier requires that the NetEngine 8000 F deliver the priority of a management user also through the Login-service (15) attribute. To meet this requirement, run the radius-attribute translate Login-service HW-Exec-Privilege receive command on the NetEngine 8000 F.

      After the command is run, an NetEngine 8000 F automatically treats the Login-service attribute as the HW-Exec-Privilege attribute when parsing the Login-service attribute in the received RADIUS authentication response packet. The priority of a management user is originally delivered through the HW-Exec-Privilege attribute. After the attribute conversion, the NetEngine 8000 F can deliver the Login-service attribute to manage the priority of the management user.

    • In the sending direction

      For example, an NetEngine 8000 F reports the name of a BRAS device through the NAS-Identifier (32) attribute and reports the location of an accessed user through the NAS-Port-Id (87) attribute. However, other vendor devices report the name of the BRAS device through the NAS-Port-Id attribute. The carrier requires that the Huawei NetEngine 8000 F also report the name of the BRAS device through the NAS-Port-Id attribute. To meet this requirement, run the radius-attribute translate NAS-Port-Id NAS-Identifier send command.

Before this command is run, the encapsulated content in the NAS-Port-Id attribute is the location of the accessed user when the NetEngine 8000 F sends the authentication request packet. After this command is run, the content encapsulated in the NAS-Port-Id attribute is the same as that of the NAS-Identifier attribute, namely, the device name, when the NetEngine 8000 F sends the authentication request packet.

Default Carrying Status of RADIUS Attributes

Different RADIUS server vendors have their own requirements on the maximum number of RADIUS attributes that can be carried in a packet. For example, the RADIUS servers manufactured by some vendors can process a packet carrying up to 50 RADIUS attributes. If a packet carries more RADIUS attributes, the RADIUS servers cannot function properly. The radius-attribute include attribute-name command has been added for NetEngine 8000 F to allow them to carry or not carry specific RADIUS attributes in packets to be sent to RADIUS servers by default.

Copyright © Huawei Technologies Co., Ltd.
Copyright © Huawei Technologies Co., Ltd.
< Previous topic Next topic >