32-bit vendor-extended-type vendor specific attribute

1. Field of the Disclosure

The disclosure relates generally to data communications, and in particular, to a 32-bit vendor specific attribute extension to the RADIUS RFC.

2. The Prior Art

RADIUS (Remote Authentication Dial In User Service) is a standards-based protocol for AAA (Authentication, Authorization, and Accounting) and enables systems to securely determine the identity and privileges of a user and track that user's activities. As is known by those skilled in the art, RADIUS exchanges attributes between clients and servers in a Type, Length, Value (TLV) format.

FIG. 1 is a diagram of a prior art RADIUS packet 100 . The packet 100 typically includes a Type field of 8 bits; a Length field of 8 bits for specifying the total length of the attribute; a Vendor-ID field of 32 bits; a Vendor-Type field of 8 bits; a second length field of 8 bits for specifying the length of the inner value; and an inner value field of 1 or more bytes.

The RADIUS protocol allows for extensions via the Vendor Specific attribute. This attribute is designated for Vendor Specific Extensions and is known as the Vendor Specific Attribute (VSA) and has a fixed outer type of 26. As is known by those of ordinary skill in the art, the RFC is an IETF document describing a standard protocol, for RADIUS it is #RFC2865. The RFC suggests that this attribute should accommodate a maximum of 255 possible Vendor-Types.

At the time of design of the protocol, 255 possible Vendor-Types was considered to be an adequate space and it was further thought that most of the attributes that are commonly needed by all Vendors would be introduced in the standard space (from 1–255 excluding Vendor Specific Type 26).

However, as the number of protocols utilized by Network Access Servers (NAS) has grown, the need for more extensions has also increased. As is known by those skilled in the art, extensions may be triggered by VSAs stored in the user profile of a given NAS. This widespread growth of the number of protocols supported by a NAS has led to the Vendor space being completely utilized.

Method and apparatus for generating and receiving an extended Vendor Specific Attribute (VSA) are disclosed. In one aspect, an extended format VSA may be generated containing at least a Vendor-Type field having a predetermined value and a Extended Vendor-Type field.

A Vendor Specific Attribute packet generated and received in accordance with the teachings of this disclosure may have a field sequence of <Type> <Length> <Vendor-ID> <Vendor-Type> <Length> <Vendor-Extended-Type> <Value>.

A Vendor Specific Attribute packet generated and received in accordance with the teachings of this disclosure may have a field lengths of Type 8 bits; Length=8 bits; Vendor-ID=32 bits; Vendor-Type 8 bits; Length=8 bits; Vendor-Extended-Type=32 bits; and Value=1 or more bytes.

FIG. 1 is a diagram of a prior art VSA.

FIG. 2 is a diagram of an extended format VSA in accordance with the teaching of this disclosure.

FIG. 3 is a flow diagram of a method for generating an extended format VSA in accordance with this disclosure.

FIG. 4 is a flow diagram of a method for receiving an extended format VSA in accordance with this disclosure.

FIG. 5 is a flow diagram of a further method for receiving an extended format VSA in accordance with this disclosure.

Persons of ordinary skill in the art will realize that the following description is illustrative only and not in any way limiting. Other modifications and improvements will readily suggest themselves to such skilled persons having the benefit of this disclosure. In the following description, like reference numerals refer to like elements throughout.

This disclosure may relate to data communications. Various disclosed aspects may be embodied in various computer and machine readable data structures. Furthermore, it is contemplated that data structures embodying the teachings of the disclosure may be transmitted across computer and machine readable media, and through communications systems by use of standard protocols such as those used to enable the Internet and other computer networking standards.

The disclosure may relate to machine readable media on which are stored various aspects of the disclosure. It is contemplated that any media suitable for retrieving instructions is within the scope of the present disclosure. By way of example, such media may take the form of magnetic, optical, or semiconductor media, and may be configured to be accessible by a machine as is known in the art.

Various aspects of the disclosure may be described through the use of flowcharts. Often, a single instance of an aspect of the present disclosure may be shown. As is appreciated by those of ordinary skill in the art, however, the protocols, processes, and procedures described herein may be repeated continuously or as often as necessary to satisfy the needs described herein. Accordingly, the representation of various aspects of the present disclosure through the use of flowcharts should not be used to limit the scope of the present disclosure.

This disclosure introduces a new Vendor Specific Attribute (VSA). In a one aspect, the fields of a VSA configured in accordance with the teachings of this disclosure may have the following fields with lengths as follows:

Type=8 bits Length=8 bits Vendor-ID=32 bits Vendor-Type 8 bits Length=8 bits Vendor-Extended-Type=32 bits Value=1 or more bytes

FIG. 2 is a diagram of one aspect of a Vendor Specific Attribute (VSA) 200 configured in accordance with the teachings of this disclosure. The VSA 200 may have a field sequence of:

<Type> <Length> <Vendor-ID> <Vendor-Type> <Length> <Vendor-Extended-Type> {<Flags>+} [[<Tag>] [<Salt>] . . . ] <Value>

In the VSA of this disclosure, a single Vendor-Type field value is reserved to indicate that the attribute contains the extended format. The actual expanded field may follow the inner length field as shown in FIG. 2 . Thus, when the Vendor-Type field contains a predetermined value, the VSA contains an extended format. When the Vendor-Type field does not contain a predetermined value, the VSA does not contain the extended format.

As will be appreciated by those skilled in the art, when the VSA contains the extended format, the capacity of the VSA is increased from 8-bits to 32-bits, or from 256 Vendor Types to approximately 4G Vendor Types, a great increase in capacity. The length of the actual value portion may be further reduced by 4 bytes.

Ensuring backwards capability can be important where the request and response must pass through proxy chains formed by broker networks. In these situations, proxy chains may be made aware of extensions independent of the upstream or downstream proxies to which it is connected. This can be significant in environments such as Voice over Internet Protocol (VoIP), Wholesale Service Providers and Wireless Networks.

FIG. 3 is a flowchart of a method for generating a VSA in accordance with the teachings of this disclosure. The process of FIG. 3 may begin in query 300 , where it is determined whether it is desired to use the extended format VSA. If it is so desired, a predetermined value is placed in the Vendor-Type field in act 302 . The Vendor Extended Type field may then be used as desired.

If it is not desired to use the extended format, then a Vendor-Type value other than the predetermined value may be used, and the VSA may be used as normal in act 304 .

FIG. 4 is a flowchart of a method for receiving and processing a VSA in accordance with the teachings of this disclosure. The process of FIG. 4 may begin in act 400 where the receiving machine determines whether a received packet contains a Vendor-Extended-Type field according to this disclosure. If the received packet contains a Vendor-Extended-Type field, the extended value contained therein may be read by the receiving machine in act 402 . If the received packet does not contain a Vendor-Extended-Type field, the packet may be processed as normal by the receiving machine in act 404 .

The receiving machine may look for a predetermined value in the Vendor Type field to determined whether the received packet contains a Vendor-Extended-Type field.

FIG. 5 is a flowchart of a further method for receiving and processing a VSA in accordance with the teachings of this disclosure. The process of FIG. 5 may begin in act 500 where the receiving machine determines whether it is capable of processing a Vendor-Extended-Type field according to this disclosure. If the receiving machine can process a Vendor-Extended-Type field, the extended value contained therein (if present) may be read by the receiving machine in act 502 . If the receiving machine is not capable of processing a Vendor-Extended-Type field, the packet may be processed as normal by the receiving machine in act 504 .

It is contemplated that the processes described herein may be performed by a wide variety of machines. For example, it is contemplated that any RADIUS server may be configured to generate or process the VSA of this disclosure. Such a server may include a processor and memory as is known in the art. For example, embodiments of the present disclosure may be run wherever the RADIUS client is run, or on proxies.

While embodiments and applications of this disclosure have been shown and described, it would be apparent to those skilled in the art that many more modifications and improvements than mentioned above are possible without departing from the inventive concepts herein. The disclosure, therefore, is not to be restricted except in the spirit of the appended claims.