Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 

Attributes

 

You work with RADIUS attributes while setting up users, profiles, and RADIUS clients in Steel-Belted Radius Carrier. The Web GUI lets you select RADIUS attributes by name from a predefined list. For each attribute, the Web GUI prompts you to enter values using familiar data types such as string, integer, or network address.

Dictionaries

Dictionaries

Steel-Belted Radius Carrier uses dictionary files to define RADIUS and Diameter attributes, as well as some attributes defined by Microsoft, 3GPP, and others used internally by SBR. Steel-Belted Radius Carrier uses these definitions to parse authentication/accounting requests and generate responses.

The main Steel-Belted Radius Carrier dictionary files (radius.dct and radius.dic) list attributes defined by the RADIUS and Diameter standards. The radius.dct and radius.dic files reside in the same directory as Steel-Belted Radius Carrier (usually /opt/JNPRsbr/radius on Solaris and Linux systems).

Vendor-Specific Attributes

Vendor-Specific Attributes

In addition to the standard attributes, many network access servers use Vendor-Specific Attributes (VSAs). Steel-Belted Radius Carrier supports a large number of specific network access servers by providing vendor-specific dictionary files. These files also reside in the server directory and use the filename extensions .dct and .dic.

The Steel-Belted Radius Carrier package contains juniper.dct and juniper.dic dictionary files that list all Juniper VSAs that are used for fixed and mobile subscriber management (ERX Series and MX Series routers, with vendor ID 4874) and router administration (vendor ID 2636). Dictionaries for many versions of Juniper products, including the E Series and MX Series routers, are available at https://www.juniper.net/support/downloads/ (in the Documentation tab for the specific product). For more information about how to add the dictionaries to SBR Carrier, see the “Dictionary Files” section in the SBR Carrier Reference Guide.

Dictionaries and the Make/Model Field

Dictionaries and the Make/Model Field

During Steel-Belted Radius Carrier configuration, when you make a selection in the RADIUS Client Make/Model field, you are telling the server which dictionary file contains the VSAs for this client device. Thereafter, whenever the server receives a RADIUS packet from this client device, it can consult this dictionary file for any nonstandard attributes that it encounters in the packet. Standard RADIUS attributes are always defined by the radius.dct file. If you are not sure which make/model you should specify for a RADIUS Client, choose - Standard RADIUS -.

The selections available in the Make/model field identify devices whose vendors have provided attribute dictionaries for use with Steel-Belted Radius Carrier.

Updating Attribute Information

Updating Attribute Information

If your NAS vendor announces a new product, a new attribute, or a new value for an attribute, you can add this information to your Steel-Belted Radius Carrier configuration. You can edit the dictionary file for that vendor to add new attributes or attribute values, or you can create a new vendor-specific dictionary file that contains new attributes and values. For more information about dictionary files, refer to the SBR Carrier Reference Guide.

Structured Attributes

Structured Attributes

Steel-Belted Radius Carrier natively supports structured attributes that contain subattributes.

Subattributes are values in a RADIUS packet that are not stored as a RADIUS AVP or vendor-specific-attribute (VSA), but rather are packed with other subattributes into a RADIUS VSA. In a RADIUS packet, multiple RADIUS VSAs might contain subattributes. The RADIUS VSA, which consists of multiple subattributes, is sometimes referred to as a structured attribute because it contains structured data.

Earlier Steel-Belted Radius products, such as the SIM Server product and Mobile IP Module, only interpreted AVPs and not the subattributes contained within the AVP. These earlier products included plug-ins that copied the subattributes from the AVP container and represented them in the RADIUS request as if they had been received as separate AVPs. In the response, the RADIUS AVPs were reassembled from their contained subattribute values. This process was known as packet flattening and unflattening.

The dictionary mechanism of Steel-Belted Radius Carrier has been extended to allow for XML declaration of structured AVP contents. When an AVP with an associated structure definition is received, its internal subattribute values are automatically parsed and become available to any component within Steel-Belted Radius Carrier that processes RADIUS requests. Similarly, any subattribute values that are populated into the RADIUS response are formatted as part of the structured RADIUS AVP according to the same XML structure definition.

Subattribute dictionary definitions are defined in .jdict files. The .jdict definition files reside in the radiusdir/subattributes directory. All files ending in .jdict are parsed by Steel-Belted Radius Carrier as subattribute files. Once parsed, the definitions are merged into the .dct definitions.

If you used the packet flattening/unflattening method in Steel-Belted Radius Carrier 7.2 and previous versions, we recommend that you migrate to using subattributes.

Note
  • *.dic dictionary files do not support structured attribute definitions.

  • The Class attribute cannot contain structured attributes.

User Attribute Lists

User Attribute Lists

Each user entry in the Steel-Belted Radius Carrier database provides the information necessary for the server to try to authenticate a connection request using a specific authentication method. When you view a user entry using the Web GUI, this method is identified in the User type field.

You can control authentication at finer levels of detail than simple username/ password checking allow. The check list, return list, or profile fields in the user entry in the database provide powerful tools for the authentication and authorization of users. These fields direct the server how to handle RADIUS attributes while authenticating a connection request and can be used to configure the authorization of the session.

Check List Attributes

Check List Attributes

A check list is a set of attributes that must accompany the authentication request before the request can be accepted. The NAS must send attributes that match the check list associated with a user entry; otherwise, Steel-Belted Radius Carrier rejects the user even if the user’s name and password are valid.

By including appropriate attributes in the check list, a variety of rules can be enforced. For example, only specific users might be permitted to use ISDN or dial-in connections to a particular NAS, or Caller ID might be used to validate a user against a list of acceptable originating telephone numbers.

A check list is created by selecting attributes from a list of all RADIUS attributes known to the Steel-Belted Radius Carrier server. This list can include a variety of vendor-specific attributes.

During authentication, Steel-Belted Radius Carrier filters the check list based on the dictionary for the RADIUS client that sent the authentication request. The server ignores any check list attribute that is not valid for this device.

Return List Attributes

Return List Attributes

A return list is a set of attributes that Steel-Belted Radius Carrier must return to the NAS after authentication succeeds. The return list usually provides additional parameters that the NAS needs to complete the connection. Return list attributes can thus be considered to be authorization configuration parameters.

By including appropriate attributes in the return list, you can create a variety of connection policies. Specific users can be assigned particular IP addresses; IP header compression can be turned on or off; or a time limit can be assigned to the connection.

You create a return list by selecting attributes from a list of all RADIUS attributes known to Steel-Belted Radius Carrier. This list can include a variety of vendor-specific attributes.

During authentication, Steel-Belted Radius Carrier filters the return list based on the dictionary for the RADIUS client that sent the authentication request. The server omits any return list attribute that is not valid for this device.

Structured Attributes in Check Lists and Return Lists

Structured Attributes in Check Lists and Return Lists

When configuring check list and return list attributes, if the selected attribute has corresponding subattributes defined in the Steel-Belted Radius Carrier dictionaries, an Add Child button is available, which enables you to add the corresponding subattributes.

Attribute Values

Attribute Values

The value of each RADIUS attribute has a well-defined data type: numeric, string, IP address, time, or hexadecimal. For example, Callback-Number is of type string and is a telephone number entered by the administrator, whereas NAS-Port-Type is an integer attribute that has defined values in the dictionary which appear in the GUI and can be Sync, Async, and so forth.

Note

Steel-Belted Radius Carrier supports signed integers (negative numbers) for attributes received in packets. However, Web GUI do not support signed integers, and treats signed and unsigned integers as unsigned integers.

Single- and Multi-Valued Attributes

Single- and Multi-Valued Attributes

Attributes can be single- or multi-valued. Single-valued attributes appear at most once in the check list or return list; multi-valued attributes may appear several times.

If an attribute appears more than once in the check list, this means that any one of the values is valid. For example, you can set up a check list to include multiple telephone numbers for attribute Calling-Station-ID. A user trying to dial into your network would then have to call from one of the designated telephone numbers to be authenticated.

If an attribute appears more than once in the return list, each value of the attribute is sent as part of the response packet.

Orderable Multi-Valued Attributes

Orderable Multi-Valued Attributes

Certain multi-valued return list attributes are also orderable, which means the attribute can appear more than once in a RADIUS response, and the order in which the attributes appear is important.

For example, the Reply-Message attribute allows text messages to be sent back to the user for display. A multi-line message is sent by including this attribute multiple times in the return list, with each line of the message in its proper sequence.

System Assigned Values

System Assigned Values

Some attributes do not allow the administrator to set a value. Steel-Belted Radius Carrier retrieves the appropriate value for this attribute when it is needed.

Echo Property

Echo Property

Using the echo property, you can force an attribute from the RADIUS request to be echoed in the RADIUS response. For example, you might add Callback-Number to the return list and select the echo check box. Steel-Belted Radius Carrier takes the value of the Callback-Number it receives in the RADIUS request and echoes it back to the client in the RADIUS response; if it receives no Callback-Number, it echoes nothing.

You enter Callback-Number one or more times into the check list. This indicates that one of the callback numbers you supplied must be present in the RADIUS request, and that number should be echoed in the RADIUS response.

Note

The echo property is disabled for multi-valued return list attributes.

Default Values

Default Values

Selecting default for a check list attribute specifies that, if the RADIUS request does not include this attribute, the request should not be rejected. Instead, the value supplied as the default should be used as if it were received as part of the request. One use for default values is to require that an attribute in a RADIUS request must have one of several values, or must not be present at all. Another use is to provide a default value for an attribute in conjunction with the echo property in the return list.

Steel-Belted Radius Carrier can provide alternate values when an attribute appears in the check list marked as default, and the same attribute appears in the return list marked as echo. The server echoes the actual value of the attribute in the RADIUS response if the attribute appears in the RADIUS request and echoes the default value (from the check list) in the response if the attribute does not appear in the RADIUS request.

If you add multiple values of the same attribute to the check list, only one of them can be marked as default.

For example, an administrator adds several Callback-Number values to the check list and marks one of them as default. The administrator adds Callback-Number to the return list and specifies it as echo.

  • If a Callback-Number value is present in the RADIUS request, it must match one of the check list values or the user is rejected.

  • If it does match, the user is accepted and the value supplied is echoed in the RADIUS response.

  • If no Callback-Number is supplied in the request, the user is accepted and the default value is echoed in the response.

Other check list attributes are used to provide configuration for the user, such as time-of-day and concurrent-login-limit information.

Wildcard Support

Wildcard Support

Steel-Belted Radius Carrier supports wildcards (? and *) for string-type attributes in check list items.

To allow backward compatibility with check list items that treat the string literally, a string containing wildcards must be prefixed with a caret (^). When the caret is present, the remainder of the string is parsed using escape rules.

A ? wildcard matches any character and a * wildcard matches the remainder of the string (but can appear only at the end of a string). Wildcard characters can be treated as literals by using escape codes (for example, \?). Table 10 lists the non-ASCII characters that can also be present in the wildcard string:

Table 10: Non-ASCII Characters in Wildcard Strings

Code

Meaning

\a

BEL

\b

Backspace

\f

Form feed

\n

Linefeed

\r

Carriage return

\t

Horizontal tab

\v

Vertical tab

\\

Backslash

\*

Literal ‘*’ (not wildcard)

\?

Literal ‘?’ (not wildcard)

\xnn

Where nn is a hexadecimal value

\nnn

Where nnn is a decimal value

A ‘\’ followed by any other character represents that character’s value.

The following is a wildcard example for string type attributes:

  Called-Station-ID = ^800*

Where Called-Station-ID indicates any 800 number.

Attribute Filtering

Attribute Filtering

You can filter specific RADIUS attribute/value pairs into and out of RADIUS packets as they travel to and from directed realms and proxy RADIUS realms. Attribute filtering can be useful if there is data in the packets that is needed for routing, but not for authentication or accounting.

Adding NAS Location Attributes to Access-Requests

Adding NAS Location Attributes to Access-Requests

Steel-Belted Radius Carrier core provides an attribute handling feature, which allows you to add NAS location information to proxied Access-Request messages.

Service providers might require the location of the mobile device requesting access. For example, a service provider might offer weather reports or advertising based on the location of the mobile device.

You can configure an Access-Request to include the location of the NAS through which the proxied request was processed. Because the NAS is geographically near the mobile device, it closely approximates the location of the mobile device.

When a mobile device is outside the area of its provider, it roams by sending the request to a local foreign AAA (FAAA) server that is owned by another provider. The FAAA server proxies (forwards) the request to the appropriate home AAA (HAAA) server for the user.

For proxied requests, Steel-Belted Radius Carrier can perform a lookup to find a NAS location based on an attribute (usually NAS-Identifier or NAS-IP-Address). Steel-Belted Radius Carrier can perform a query to find the value of the attribute that identifies the NAS location. The NAS location is then added to the Access-Request that is sent to the service provider’s home AAA server. The attribute that is used to look up the NAS location is user-configurable as the AttributeToIdentifyNAS in the locspec.ctrl file.

For details on configuring this feature, see Adding NAS Location Information to Access-Request Messages in the Attribute Processing Files section of the SBR Carrier Reference Guide.

Specifying IPv4 Address Classes

Specifying IPv4 Address Classes

You can specify IPv4 address classes using class-based subnetting. Table 11 lists example usages for class-based subnetting.

Table 11: Example Usages for Class-Based Subnetting

Class

Example IP Address Range

Class-Based Subnetting

A

10.0.0.0–10.255.255.255

10.0.0.0

B

176.1.0.0–176.1.255.255

176.1.0.0

C

192.168.15.0–192.168.15.255

192.168.15.0

D

225.224.224.15

225.224.224.15

Address match required