INTERNET DRAFT Pat R. Calhoun
Category: Standards Track Sun Laboratories, Inc.
Title: draft-calhoun-diameter-07.txt Allan C. Rubens
Date: November 1998 Ascend Communications
DIAMETER Base Protocol
Status of this Memo
Comments should be submitted to the diameter@ipass.com mailing list.
Distribution of this memo is unlimited.
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as ``work in progress.''
To view the entire list of current Internet-Drafts, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Abstract
The DIAMETER base protocol is intended to provide a framework for any
services which require AAA/Policy support. The protocol is intended
to be flexible enough to allow services to add building blocks (or
extensions) to DIAMETER in order to meet their requirements.
This draft specifies the message format and transport to be used by
all DIAMETER extensions and MUST be supported by all DIAMETER
implementations, regardless of the specific underlying service.
Calhoun, Rubens expires April 1999 [Page 1]
INTERNET DRAFT November 1998
Table of Contents
1.0 Introduction
1.1 Definitions
1.2 Terminology
2.0 Protocol Overview
2.1 Header Format
2.2 AVP Format
2.3 Error Reporting
3.0 DIAMETER AVPs
3.1 DIAMETER-Command AVP
3.1.1 Message-Reject-Ind
3.1.2 Device-Reboot-Ind
3.1.3 Device-Watchdog-Ind
3.2 Host-IP-Address
3.3 Host-Name
3.4 State
3.5 Class
3.6 Session-Timeout
3.7 Extension-Id
3.8 Integrity-Check-Vector
3.9 Initialization-Vector
3.10 Timestamp
3.11 Session-Id
3.12 Vendor-Name
3.13 Firmware-Revision
3.14 Result-Code
3.15 Error-Code
3.16 Unrecognized-Command-Code
3.17 Reboot-Type
3.18 Reboot-Time
3.19 Failed-AVP-Code
3.20 User-Name
4.0 Protocol Definition
4.1 DIAMETER Bootstrap Message
4.2 Keepalive Exchange
4.3 Unrecognized Command Support
4.4 The art of AVP Tagging
4.5 Using the Integrity-Check-Vector
4.6 AVP Encryption with Shared Secrets
5.0 References
6.0 Acknowledgements
7.0 Author's Address
Calhoun, Rubens expires April 1999 [Page 2]
INTERNET DRAFT November 1998
1.0 Introduction
Since the RADIUS protocol is being used today for much more than
simple authentication and accounting of dial-up users (i.e.
authentication of WWW clients, etc), a more extensible protocol was
necessary which could support new services being deployed in the
internet and corporate networks.
RADIUS in itself is not an extensible protocol largely due to its
very limited command and attribute address space. In addition, the
RADIUS protocol assumes that there cannot be any unsolicited messages
from a server to a client. In order to support new services it is
imperative that a server be able to send unsolicited messages to
clients on a network, and this is a requirement for any DIAMETER
implementation.
This document describes the base DIAMETER protocol, which is used as
the transport for all DIAMETER extensions. This document in itself is
not complete and MUST be used with an accompanying applicability
extension document.
An example of such a document would be [7] that defines extensions to
the base protocol to support user authentication and [XXX] which
defines extensions to support accounting.
1.1 Definitions
In this document, several words are used to signify the requirements
of the specification. These words are often capitalized.
MUST This word, or the adjective "required", means that the
definition is an absolute requirement of the
specification.
MUST NOT This phrase means that the definition is an absolute
prohibition of the specification.
SHOULD This word, or the adjective "recommended", means that
there may exist valid reasons in particular circumstances
to ignore this item, but the full implications must be
understood and carefully weighed before choosing a
different course.
MAY This word, or the adjective "optional", means that this
item is one of an allowed set of alternatives. An
implementation which does not include this option MUST
be prepared to interoperate with another implementation
Calhoun, Rubens expires April 1999 [Page 3]
INTERNET DRAFT November 1998
which does include the option.
1.2 Terminology
AVP
The DIAMETER protocol consists of a header followed by objects.
Each object is encapsulated in a header known as an Attribute-
Value-Pair (AVP).
DIAMETER Device
A Diameter device is a client or server system that supports the
Diameter Base protocol and 0 or more extensions.
ICV
An Integrity Check Vector (ICV) is a hash of the packet with a
shared secret.
2.0 Protocol Overview
2.1 Header Format
The base DIAMETER protocol MAY be transmitted over TCP. The document
[11] defines the extensions required to transmit DIAMETER over UDP.
The destination port field for DIAMETER is 1812.
Each DIAMETER Service Extension (i.e. Mobile IP, ROAMOPS, etc) MUST
define the transport layer required.
For UDP, when a reply is generated the source and destination ports
are reversed.
A summary of the DIAMETER data format is shown below. The fields are
transmitted from left to right.
Calhoun, Rubens expires April 1999 [Page 4]
INTERNET DRAFT November 1998
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RADIUS PCC | Flags |W| Ver | Packet Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Send (Ns) | Next Received (Nr) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVPs ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
RADIUS PCC (Packet Compatibility Code)
The RADIUS PCC field is a one octet field which is used for
backward compatibility with RADIUS. In order to easily distinguish
DIAMETER packets from RADIUS a special value has been reserved and
allows an implementation to support both protocols concurrently
using the first octet in the header. The RADIUS PCC field MUST be
set as follows:
254 DIAMETER packet
PKT Flags
The Packet Flags field is five bits, and is used in order to
identify any options. This field MUST be initialized to zero. The
following flag may be set:
The 'W' bit is set when the Next Send (Ns) and Next Received
(Nr) fields are present in the header. This SHOULD be set
unless the underlying layer provides reliability (i.e. TCP).
Version
The Version field is three bits, and indicates the version number
which is associated with the packet received. This field MUST be
set to 1 to indicate DIAMETER Version 1.
Packet Length
The Packet Length field is two octets. It indicates the length of
the packet including the header fields. For messages received via
UDP, octets outside the range of the Length field should be
treated as padding and should be ignored upon receipt.
Identifier
Calhoun, Rubens expires April 1999 [Page 5]
INTERNET DRAFT November 1998
The Identifier field is four octets, and aids in matching requests
and replies. The sender MUST ensure that the identifier in a
message is locally unique (to the sender) at any given time, and
MAY attempt to ensure that the number is unique across reboots.
The identifier is normally a monotonically increasing number, but
using a random value is also permitted. Given the size of the
Identifier field it is unlikely that 2^32 requests could be
outstanding at any given time.
Next Send
This field is defined in [11].
Next Received
This field is defined in [11].
AVPs
AVPs is a method of encapsulating information relevant to the
DIAMETER message. See section 2.2 for more information on AVPs.
2.2 AVP Format
DIAMETER Attributes carry specific authentication, accounting and
authorization information as well as configuration details for the
request and reply.
Some Attributes MAY be listed more than once. The effect of this is
Attribute specific, and is specified in each case by the attribute
description.
Each AVP MUST be padded to align on a 32 bit boundary. Although this
is not problematic for most attribute types, it does require that AVP
of string and data type be padded with zeroes accordingly. The
Padding size can be calculated using the following formula:
if( Length mod 4 != 0 )
padding_size = 4 - ( Length mod 0 )
else
padding_size = 0
The end of the list of attributes is defined by the length of the
DIAMETER packet minus the length of the header.
The attribute format is shown below and MUST be sent in network byte
order.
Calhoun, Rubens expires April 1999 [Page 6]
INTERNET DRAFT November 1998
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor ID (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-+-+-+-+
AVP Code
The AVP Code field is four octets. The first 256 AVP numbers are
reserved for backward RADIUS compatibility. Up-to-date values of
the RADIUS Type field are specified in the most recent "Assigned
Numbers" RFC [2].
AVP numbers 256 and above are used for DIAMETER. Each service MUST
allocate AVP numbers through the IANA.
If the Vendor-Specific-AVP flag is set, the AVP Code is allocated
from the vendor's private address space.
AVP Length
The AVP Length field is two octets, and indicates the length of
this Attribute including the AVP Code, AVP Length, AVP Flags,
Reserved, the Tag and Vendor ID fields if present and the AVP
data. If a packet is received with an Invalid attribute length,
the packet SHOULD be rejected.
Reserved
The Reserved field MUST be set to zero (0).
AVP Flags
The AVP Flags field informs the DIAMETER host how each attribute
must be handled.
The 'M' Bit, known as the Mandatory bit, indicates whether support
of the AVP is required. If an AVP is received with the 'M' bit
enabled and the receiver does not support the AVP, the request
MUST be rejected.
Calhoun, Rubens expires April 1999 [Page 7]
INTERNET DRAFT November 1998
AVPs without the 'M' bit enabled are informational only and a
receiver that receives a message with such an AVP that is not
supported MAY simply ignore the AVP.
When the 'H' bit is enabled it indicates that the AVP data is
encrypted using hop-by-hop encryption. See section 4.5 for more
information.
When the 'E' bit is enabled it indicates that the AVP data is
encrypted using end-to-end encryption. See [12] for more
information.
The 'V' bit, known as the Vendor-Specific bit, indicates whether
the optional Vendor ID field is present in the AVP header. When
set the AVP Code belongs to the specific vendor code address
space.
The 'T' bit, known as the Tag bit, is used to group sets of AVPs
together. Grouping of AVPs is necessary when more than one AVP is
needed to express a condition.
The 'P' bit, known as the protected AVP bit, is used to indicate
whether the AVP is protected by a Digital Signature AVP. When set,
the AVP is protected and the contents cannot be changed by a
DIAMETER proxy server. See [12] for more information.
Vendor ID
The optional four octet Vendor ID field contains the IANA assigned
"SMI Network Management Private Enterprise Codes" value, encoded
in network byte order. Any vendor wishing to implement DIAMETER
extensions can use their own Vendor ID along with private
Attribute values, guaranteeing that they will not collide with any
other vendor's extensions, nor with future IETF extensions.
The value zero, reserved in this protocol, corresponds to IETF
adopted Attribute values, defined within this document; zero MUST
NOT be used in an AVP.
Tag
The Tag field is four octet in length and is intended to provide a
means of grouping attributes in the same packet which refer to the
same tunnel. If the Tag field is unused, the 'T' bit MUST NOT be
set..
Data
Calhoun, Rubens expires April 1999 [Page 8]
INTERNET DRAFT November 1998
The Data field is zero or more octets and contains information
specific to the Attribute. The format and length of the Data field
is determined by the AVP Code and AVP Length fields.
The format of the value field MAY be one of six data types. It is
possible for an attribute to have a structure and this MUST be
defined along with the attribute.
Data
0-65400 octets of arbitrary data.
String
0-65400 octets of string data using the UTF-8 character set.
Address
32 bit or 128 bit value, most significant octet first. The
length of the attribute is determined by the length.
Integer32
32 bit value, most significant octet first.
Integer64
64 bit value, most significant octet first.
Time
32 bit value, most significant octet first -- seconds since
00:00:00 GMT, January 1, 1970.
2.3 Error Reporting
There are five different types of errors within DIAMETER. The first
being where a DIAMETER message is poorly formatted and
unrecognizable, indicated below by "Bad Packet".
The second case involves receiving a DIAMETER-Command-AVP that is not
supported, which is shown below by "Unknown Command". The third case
is where an AVP is received, marked mandatory and is unknown by the
receiver, which is labeled below as "Unknown AVP".
This fourth case involves receiving a message with a known AVP, yet
the value is either unknown or illegal, which is shown below as "Bad
Calhoun, Rubens expires April 1999 [Page 9]
INTERNET DRAFT November 1998
Value". The last case occurs when an error occurs while processing a
specific extension command, which is not related to the packet format
and is labeled "Extension Error" below.
Error Type Ignore Message Send Extension
Message-Reject-Ind Response /w
Result-Code
Bad Packet X
Unknown Command X
Unknown AVP X
Bad Value X
Extension Error X
"Ignore Message" indicates that the message is simply dropped. The
"Message-Reject-Ind" indicates that a Message-Reject-Ind message MUST
be sent to the peer as described in the appropriate section. The
"Extension Error w/ Result-Code" indicates that the appropriate
Response to the message MUST be sent with the Result-Code or Error-
Code AVP set to a value that enables the peer to understand the
nature of the problem.
3.0 DIAMETER AVPs
This section will define the mandatory AVPs that MUST be supported by
all DIAMETER implementations. Note the first 256 AVP numbers are
reserved for RADIUS compatibility.
The following AVPs are defined in this document:
Attribute Name Attribute Code
-----------------------------------
DIAMETER-Command 256
Host-IP-Address 4
Host-Name 32
State 24
Class 25
Session-Timeout 27
Extension-Id 258
Integrity-Check-Vector 259
Initialization-Vector 261
Timestamp 262
Session-Id 263
Vendor-Name 266
Firmware-Revision 267
Result-Code 268
Error-Code 269
Unrecognized-Command-Code 270
Calhoun, Rubens expires April 1999 [Page 10]
INTERNET DRAFT November 1998
Reboot-Type 271
Reboot-Time 272
Failed-AVP-Code 279
3.1 DIAMETER-Command AVP
Description
The DIAMETER-Command AVP MUST be the first AVP following the
DIAMETER header. This AVP is used in order to communicate the
command associated with the message. A DIAMETER message can have
at most one DIAMETER-Command AVP. The format of the AVP is as
follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
256 DIAMETER-Command
AVP Length
The length of this attribute MUST be at least 12. The exact
length of the AVP is determined by the actual Command and is
defined with each command.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V' MAY be set if the Command
Code is vendor specific. The 'T' and the 'P' bits MUST NOT be
set.
Command Code
The Command Code field contains the command number. The
following commands are defined and MUST be supported by all
DIAMETER implementations in order to conform to the base
protocol specification:
Calhoun, Rubens expires April 1999 [Page 11]
INTERNET DRAFT November 1998
Command Name Command Code
-----------------------------------
Message-Reject-Ind 256
Device-Reboot-Ind 257
Device-Watchdog-Ind 258
3.1.1 Message-Reject-Ind (MRI)
Description
The Message-Reject-Ind command provides a generic means of
completing transactions by indicating errors in the messages which
initiated them. The Message-Reject-Ind command is a possible
response to any DIAMETER command, but some DIAMETER commands MAY
expect more specialized error messages, depending on the error
type.
The Message-Reject-Ind message MUST contain the same
identification in the header and include the Session-Id if it was
present in the original message that it is responding to, even if
the identification is erroneous. The receiver of a Message-
Reject-Ind SHOULD examine the Result-Code AVP provided before
processing the identification, in order to handle the letter
appropriately.
Message Format
The structure of the Message-Reject message is defined as follows:
<Message-Reject-Ind message> ::= <DIAMETER Header>
<Message-Reject-Ind Command AVP>
<Host-IP-Address AVP>
[<Host-Name AVP>]
[<Session-Id AVP>]
<Result-Code AVP>
[<Error-Code AVP> ]
{<Failed-AVP-Code AVP> ||
<Unrecognized-Command-Code AVP>}
<Timestamp AVP>
<Initialization-Vector AVP>
{<Integrity-Check-Vector AVP> ||
<Digital-Signature AVP }
where the Identifier value in the message header and optionally
the Session-Id AVP are copied from the message being rejected and
the DIAMETER-Command AVP has the format described below. The
Result-Code and conditionally-present Error-Code AVPs indicate the
Calhoun, Rubens expires April 1999 [Page 12]
INTERNET DRAFT November 1998
nature of the error causing rejection, and the conditionally-
present Failed-AVP-Code AVP provides some minimal debugging data
by indicating a specific AVP type which caused the problem. See
the description of the Result-Code AVP for indication of when the
Error-Code and/or Failed-AVP-Code AVPs will be present in the
message. The Unrecognized-Command-Code AVP is present only when
the reason for message rejection is an unrecognized or unsupported
command code.
AVP Format
The format of the DIAMETER-Command AVP for Message-Reject-Ind is
as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
256 DIAMETER-Command
AVP Length
The length of this attribute MUST be at exactly 12.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'P' bits
MUST NOT be set.
Command Code
The Command Code field MUST be set to 256 (Message-Reject-Ind)
3.1.2 Device-Reboot-Ind (DRI)
Description
A DIAMETER device sends the Device-Reboot-Ind message to inform
Calhoun, Rubens expires April 1999 [Page 13]
INTERNET DRAFT November 1998
all of its peers either of an upcoming reboot or that it has just
rebooted.
The Reboot-Type AVP MUST be present and indicates the type of
reboot associated with this command. Note that a DIAMETER device
should only send this message once it is able to receive network
traffic.
This message is also used by a DIAMETER device in order to
exchange the supported protocol version number as well as all
supported extensions. The originator of this message MUST insert
it's highest supported version number within the DIAMETER header.
The response message MUST include the highest supported version up
to and including the version number within the request.
Similarly the originator of this message MUST include all
supported extensions within the message. The responder MUST
include all supported extensions as long as they were present
within the request message.
In the case where the receiver of this message is a proxy device,
it is responsible for inserting the highest version number which
it supports in the version field before sending the proxy request
to the remote DIAMETER peer. The proxy device may then retain the
version number of the remote peers as received in the message, and
must insert its highest version number (with the limitations
described above) in the response to the initiator.
It is desirable for a DIAMETER device to retain the supported
extensions as well as the version number in order to ensure that
any requests issued to a peer will be processed.
This message MUST contain the Vendor-Name and Extension-Id AVPs.
In the case where a DIAMETER device is configured to communicate
with many peers, this message MUST be issued to each peer.
No explicit DIAMETER message is necessary to acknowledge this
message since it is handled by DIAMETER's reliable transport.
Message Format
Calhoun, Rubens expires April 1999 [Page 14]
INTERNET DRAFT November 1998
<Device-Reboot-Ind> ::= <DIAMETER Header>
<Device-Reboot-Ind Command AVP>
<Reboot-Type AVP>
[<Reboot-Time AVP>]
<Host-IP-Address AVP>
[<Host-Name AVP>]
<Vendor-Name AVP>
<Extension-Id AVPs>
<Firmware-Revision AVP>
[<X509-Certificate AVP>]
[<X509-Certificate-URL AVP>]
<Timestamp AVP>
<Initialization-Vector AVP>
{<Integrity-Check-Vector AVP> ||
<Digital-Signature AVP }
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
256 DIAMETER-Command
AVP Length
The length of this attribute MUST be 12.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'P' bits
MUST NOT be set.
Command Code
The Command Code field MUST be set to 257 (Device-Reboot-
Indication).
Calhoun, Rubens expires April 1999 [Page 15]
INTERNET DRAFT November 1998
3.1.3 Device-Watchdog-Ind (WDI)
Description
The Device-Watchdog-Ind is used as a keepalive mechanism between
two DIAMETER peers. This message MUST contain the Host-IP-Address
or Host-Name AVP as well as any security related AVPs.
No explicit DIAMETER message is necessary to acknowledge this
message since it is handled by DIAMETER's reliable transport.
Message Format
<Device-Watchdog-Ind> ::= <DIAMETER Header>
<Device-Watchdog-Ind Command AVP>
<Host-IP-Address AVP>
[<Host-Name AVP>]
<Timestamp AVP>
<Initialization-Vector AVP>
{<Integrity-Check-Vector AVP> ||
<Digital-Signature AVP }
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
256 DIAMETER-Command
AVP Length
The length of this attribute MUST be 12.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'P' bits
MUST NOT be set.
Calhoun, Rubens expires April 1999 [Page 16]
INTERNET DRAFT November 1998
Command Code
The Command Code field MUST be set to 258 (Device-Watchdog-
Ind).
3.2 Host-IP-Address
Description
The Host-IP-Address attribute is used to inform a DIAMETER peer of
the sender's identity.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
4 Host-IP-Address
AVP Length
The length of this attribute MUST be at least 12.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'P' bits
MUST NOT be set.
Address
The Address field contains the sender's IP address.
3.3 Host-Name
Description
Calhoun, Rubens expires April 1999 [Page 17]
INTERNET DRAFT November 1998
The Host-Name attribute is used to inform a DIAMETER peer of the
sender's identity.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| String ...
+-+-+-+-+-+-+-+-+
AVP Code
32 Host-Name
AVP Length
The length of this attribute MUST be at least 9.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'P' bits
MUST NOT be set.
String
The String field is one or more octets, and should be unique to
the DIAMETER host. The Host Name MUST follow the NAI [8] naming
conventions.
3.4 State
Description
This AVP is available to be sent by the server to the client when
the DIAMETER exchange can span multiple round-trip messages and is
used to maintain server state information. The opaque data MUST be
sent unmodified by the client to the server in subsequent messages
for the same Session-Id.
Usage of the State AVP is implementation dependent.
Calhoun, Rubens expires April 1999 [Page 18]
INTERNET DRAFT November 1998
AVP Format
A summary of the State AVP format is shown below. The fields are
transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-+-+-+-+
Type
24 for State.
AVP Length
The length of this attribute MUST be at least 9.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'P' bits
MUST NOT be set.
Data
The Data field is one or more octets. The actual format of the
information is site or application specific, and a robust
implementation SHOULD support the field as undistinguished
octets.
3.5 Class
Description
The server sends this AVP to the client during authentication or
authorization and MUST be sent unmodified by the client to the
accounting server as part of the accounting message if accounting
is supported. No interpretation of the opaque data should be made
by the client.
A summary of the Class AVP format is shown below. The fields are
Calhoun, Rubens expires April 1999 [Page 19]
INTERNET DRAFT November 1998
transmitted from left to right.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-+-+-+-+
Type
25 for Class.
AVP Length
The length of this attribute MUST be at least 9.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'P' bits
MUST NOT be set.
Data
The Data field is one or more octets. The actual format of the
information is site or application specific, and a robust
implementation SHOULD support the field as undistinguished
octets.
3.6 Session-Timeout
Description
This Attribute sets the maximum number of seconds of service to
be provided to the user before termination of the session or
prompt. This Attribute is available to be sent by the server
to the client in an AA-Answer or AA-Challenge.
A summary of the Session-Timeout Attribute format is shown
below. The fields are transmitted from left to right.
Calhoun, Rubens expires April 1999 [Page 20]
INTERNET DRAFT November 1998
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
27 for Session-Timeout.
AVP Length
The length of this attribute MUST be 12.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'P' bits
MUST NOT be set.
Integer32
The Integer32 field is 4 octets, containing a 32-bit unsigned
integer with the maximum number of seconds this user should be
allowed to remain connected by the NAS.
A value of zero means that this session has an unlimited number
of seconds before termination or prompt.
3.7 Extension-Id
Description
The Extension-Id AVP is used in order to identify a specific
DIAMETER extension. This AVP MAY be used in the Device-Reboot-Ind
and the Device-Feature-Reply command in order to inform the peer
what extensions are locally supported.
Each DIAMETER extension draft MUST have an Extension-Id assigned
to it by the IANA. The base protocol does not require a
Extension-Id since its support is mandatory.
Calhoun, Rubens expires April 1999 [Page 21]
INTERNET DRAFT November 1998
There MAY be more than one Extension-Id AVP within a DIAMETER
message.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
258 Extension-Id
AVP Length
The length of this attribute MUST be 12.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'P' bits
MUST NOT be set.
Integer32
The Integer32 field contains the extension identifier as
defined in the extension's document.
3.8 Integrity-Check-Vector
Description
The Integrity-Check-Vector AVP is used for hop-by-hop
authentication and integrity, and is not recommended for use with
untrusted proxy servers.
The DIAMETER header as well as all AVPs (including padding) up to
this AVP is protected by the Integrity-Check-Vector. The Timestamp
AVP MUST be present to provide replay protection and the
Initialization-Vector AVP must be present to add randomness to the
packet.
Calhoun, Rubens expires April 1999 [Page 22]
INTERNET DRAFT November 1998
The Integrity-Check-Vector is generated in the method described in
section 4.5.1.
All DIAMETER implementations MUST support this AVP.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transform ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-+-+-+-+
AVP Code
259 Integrity-Check-Vector
AVP Length
The length of this attribute MUST be at least 13.
AVP Flags
The 'M' bit MUST be set. The 'E', 'H', 'V', 'T' and the 'P'
bits MUST NOT be set.
Transform ID
The Transform ID field contains a value that identifies the
transform that was used to compute the ICV. The following
values are defined in this document:
HMAC-MD5-96[6] 1
Data
The Data field contains an ICV of the message up to this AVP.
3.9 Initialization-Vector
Description
Calhoun, Rubens expires April 1999 [Page 23]
INTERNET DRAFT November 1998
The Initialization-Vector AVP MUST be present prior to the
Integrity-Check-Vector AVPs within a message and is used to ensure
randomness within a message. The content of this AVP MUST be a
random value of at least 128 bits.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-+-+-+-+
AVP Code
261 Initialization-Vector
AVP Length
The length of this attribute MUST be at least 24.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'P' bits
MUST NOT be set.
Data
The Data field contains a random value of at least 128 bits.
3.10 Timestamp
Description
The Timestamp AVP is used to add replay protection to the DIAMETER
protocol. This AVP MUST appear prior to the Integrity-Check-Vector
AVP or any other Integrity AVP defined in separate extensions. The
value of time is the most significant four octets returned from an
NTP server that indicates the number of seconds expired since Jan.
1, 1970.
This document does not specify the window which an implementation
Calhoun, Rubens expires April 1999 [Page 24]
INTERNET DRAFT November 1998
will accept packets, however it is strongly encouraged to make
this value user configurable with a reasonable default value (i.e.
4 seconds).
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
262 Timestamp
AVP Length
The length of this attribute MUST be 12.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'P' bits
MUST NOT be set.
Time
The Time field contains the number of seconds since Jan. 1,
1970 when the message was created.
3.11 Session-Id
Description
The Session-Id field is used in order to identify a specific
session. All messages pertaining to a specific session MUST
include this AVP and the same value MUST be used throughout the
life of a session. When present, the Session-Id SHOULD appear
immediately following the DIAMETER-Command AVP.
Note that in some applications there is no concept of a session
(i.e. data flow) and this field MAY be used to identify objects
Calhoun, Rubens expires April 1999 [Page 25]
INTERNET DRAFT November 1998
other than a session.
The Session-Id MUST be globally unique at any given time since it
is used by the server to identify the session (or flow). It is
recommended that the format of the AVP be as follow:
<Sender's IP Address><monotonically increasing 32 bit
value><optional value>
It is suggested that the monotonically increasing 32 bit value NOT
start at zero upon reboot, but rather start at a random value.
This will minimize the possibility of overlapping Session-Ids
after a reboot. The optional value is implementation specific but
may include a modem's device Id, a random value, etc.
The session Id is created by the DIAMETER device initiating the
session, which in most cases is done by the client. Note that a
Session-Id can be used by more than one extension.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-+-+-+-+
AVP Code
263 Session-Id
AVP Length
The length of this attribute MUST be at least 9.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'P' bits
MUST NOT be set.
Data
The Data field contains the session identifier assigned to the
Calhoun, Rubens expires April 1999 [Page 26]
INTERNET DRAFT November 1998
session.
3.12 Vendor-Name
Description
The Vendor-Name attribute is used in order to inform a DIAMETER
peer of the Vendor Name of the DIAMETER device. This MAY be used
in order to know which vendor specific attributes may be sent to
the peer.
It is also envisioned that the combination of the Vendor-Name and
the Firmware-Revision AVPs can provide very useful debugging
information.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| String ...
+-+-+-+-+-+-+-+-+
AVP Code
266 Vendor-Name
AVP Length
The length of this attribute MUST be at least 9.
AVP Flags
The 'H' and 'E' MAY be set depending upon the security model
used. The 'M', 'V', 'T' and the 'P' bits MUST NOT be set.
String
The String field contains the vendor name.
3.13 Firmware-Revision
Calhoun, Rubens expires April 1999 [Page 27]
INTERNET DRAFT November 1998
Description
The Firmware-Revision AVP is used to inform a DIAMETER peer of the
firmware revision of the issuing device.
For devices which do not have a firmware revision (general purpose
computers running DIAMETER software modules, for instance), the
revision of the DIAMETER software module may be reported instead.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
267 Firmware-Revision
AVP Length
The length of this attribute MUST be at least 12.
AVP Flags
The 'H' and 'E' MAY be set depending upon the security model
used. The 'M', 'V', 'T' and the 'P' bits MUST NOT be set.
Integer32
The Integer32 field contains the firmware revision number of
the issuing device.
3.14 Result-Code
Description
The Result-Code AVP is used in order to indicate whether a
particular command was completed successfully or whether an error
occurred. The Result-Code AVP MUST be present in all DIAMETER
messages of type -Request or -Answer.
Calhoun, Rubens expires April 1999 [Page 28]
INTERNET DRAFT November 1998
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
268 Result-Code
AVP Length
The length of this attribute MUST be 12.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'P' bits
MUST NOT be set.
Integer32
The Integer32 field contains the result code associated with
the DIAMETER command. The following codes have been defined:
DIAMETER_SUCCESS 0
The Request was successfully completed.
DIAMETER_FAILURE 1
The Request was not successfully completed for an
unspecified reason. A DIAMETER Message-Reject message
returning this result SHOULD whenever possible also
contain one or more Failed-AVP-Code AVPs indicating the
attributes which caused the failure.
DIAMETER_POOR_REQUEST 2
The Request was poorly constructed. A DIAMETER Message-
Reject message returning this result SHOULD whenever
possible also contain one or more Failed-AVP-Code AVPs
indicating the attributes which caused the failure.
DIAMETER_INVALID_MAC 3
Calhoun, Rubens expires April 1999 [Page 29]
INTERNET DRAFT November 1998
The Request did not contain a valid Integrity-Check-
Vector or Digital-Signature [12].
DIAMETER_UNKNOWN_SESSION_ID 4
The Request contained an unknown Session-Id.
DIAMETER_SEE_ERROR_CODE 5
The Request failed. The message MUST also contain an
Error-Code AVP which provides command-specific
information on the failure. A DIAMETER Message-Reject-
Ind message returning this result SHOULD whenever
possible also contain one or more Failed-AVP-Code AVPs
indicating the attributes which caused the failure.
DIAMETER_COMMAND_UNSUPPORTED 6
The Request contained a command code which the DIAMETER
implementation does not recognize or does not support.
The Message-Reject-Ind message MUST also contain an
Unrecognized-Command-Code AVP which contains the Command
Code value which was rejected.
DIAMETER_ATTRIBUTE_UNSUPPORTED 8
The Request contained an AVP with an AVP Code which the
DIAMETER implementation does not recognize or does not
support. An DIAMETER Message-Reject-Ind message returning
this result MUST also contain one or more Failed-AVP-Code
AVPs indicating the AVP Codes which caused the failure.
3.15 Error-Code
Description
The Error-Code AVP contains the message specific error code, if
any. This AVP only needs to be present if the Result-Code AVP is
present with the DIAMETER_SEE_ERROR_CODE.
Error-Code values and corresponding semantics are specific to the
command to which the Error-Code is a response, and MUST therefore
be documented as part of the description of that command.
AVP Format
Calhoun, Rubens expires April 1999 [Page 30]
INTERNET DRAFT November 1998
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
269 Error-Code
AVP Length
The length of this attribute MUST be 12.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'P' bits
MUST NOT be set.
Integer32
The Integer32 field contains the error code.
3.16 Unrecognized-Command-Code
Description
The Unrecognized-Command-Code AVP contains the offending Command
Code that resulted in sending the Message-Reject-Ind message.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Calhoun, Rubens expires April 1999 [Page 31]
INTERNET DRAFT November 1998
AVP Code
270 Unrecognized-Command-Code
AVP Length
The length of this attribute MUST be 12.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'P' bits
MUST NOT be set.
Integer32
The Integer32 field contains the unrecognized command code that
resulted in sending an Message-Reject-Ind message.
3.17 Reboot-Type
Description
The Reboot-Type AVP MUST be present in the Device-Reboot-
Indication message and contains an indication of the type of
reboot.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
271 Reboot-Type
AVP Length
The length of this attribute MUST be 12.
Calhoun, Rubens expires April 1999 [Page 32]
INTERNET DRAFT November 1998
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'P' bits
MUST NOT be set.
Integer32
The Integer32 field contains the reboot type associated with
the DRI command. The following value are currently defined:
REBOOT_IMMINENT 1
When the Reboot-Type AVP is set to this value it is an
indication that the DIAMETER peer is about to reboot and
should not be sent any additional DIAMETER messages
besides the acknowledgement.
REBOOTED 2
When the Reboot-Type AVP is set to this value it is an
indication that the DIAMETER peer has recently rebooted
and is ready to accept new DIAMETER messages.
CLEAN_REBOOT 3
When the Reboot-Type AVP is set to this value the server
is in the process of shutting down and MAY be available
at some time in the future.
3.18 Reboot-Time
Description
The Reboot-Time AVP MAY be present in the DRI and indicates the
number of seconds before the issuer expects to be ready to receive
new DIAMETER messages. This AVP MUST only be present when the
Reboot-Type AVP is set to REBOOT_IMMINENT. The value indicated by
this AVP should be used as an estimate and is not a hard rule.
AVP Format
Calhoun, Rubens expires April 1999 [Page 33]
INTERNET DRAFT November 1998
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
272 Reboot-Time
AVP Length
The length of this attribute MUST be 12.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'P' bits
MUST NOT be set.
Integer32
The Integer32 field contains the expected amount of seconds
before the issuer of the DRI expects to be receive to receive
new DIAMETER messages.
3.19 Failed-AVP-Code
Description
The Failed-AVP-Code AVP provides debugging information in cases
where a request is rejected or not fully processed due to
erroneous information in a specific AVP. The documentation of the
Result-Code AVP and of the Message-Reject-Ind command provide
information on the use of the Failed-AVP-Code AVP. This AVP has
the following format:
AVP Format
Calhoun, Rubens expires April 1999 [Page 34]
INTERNET DRAFT November 1998
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data...
+-+-+-+-+-+-+-+-+
AVP Code
279 Failed-AVP-Code
AVP Length
The length of this attribute MUST be 12.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'P' bits
MUST NOT be set.
Data
The Data field contains the complete AVP that could not be
processed successfully.Possible reasons for this are an
improperly-constructed AVP, an unsupported or unrecognized AVP
Code, or an invalid value.
3.20 User-Name
Description
This attribute contains the User-Name in a format consistent with
the NAI specification [8].
A summary of the User-Name AVP format is shown below. The fields
are transmitted from left to right.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
Calhoun, Rubens expires April 1999 [Page 35]
INTERNET DRAFT November 1998
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| String ...
+-+-+-+-+-+-+-+-+
Type
1 for User-Name.
AVP Length
The length of this AVP MUST be at least 9.
AVP Flags
The 'M' bit MUST be set. The 'H' MAY be set, but the 'E' bit
MUST NOT be set since proxy servers would have no knowledge of
the user's domain. The 'V', 'T' and the 'P' bits MUST NOT be
set.
String
The String field is one or more octets. All DIAMETER systems
SHOULD support User-Name lengths of at least 63 octets. The
format of the User-Name SHOULD follow the format defined in
[8].
4.0 Protocol Definition
This section will describe how the base protocol works (or is at
least an attempt to).
4.1 DIAMETER Bootstrap Message
DIAMETER provides a message that is used to indicate either an
imminent reboot, or that a reboot has occurred. The DRI message MUST
be sent to all known DIAMETER peers both previous to a reboot when
possible as well as following a reboot.
The Reboot-Type AVP is used to indicate the type of reboot associated
with the DRI. When set to REBOOT_IMMINENT, all peers should be warned
that any new DIAMETER requests sent to the issuer will probably not
be received or processed. If a request MUST be sent it would be
preferable to issue the request to an alternate peer if available.
Calhoun, Rubens expires April 1999 [Page 36]
INTERNET DRAFT November 1998
The message includes an optional Reboot-Time AVP that specifies an
estimate of how long before the issuer is available to receive new
DIAMETER messages.
Upon reboot, the host MUST issue a DRI message with the Reboot-Type
AVP set to REBOOTED. This is an indication that new DIAMETER messages
may be sent to the transmitter of the DRI.
Note that the Reboot-Time AVP is not required, and when present
provides an estimate and should not be used as a hard value. In the
case of a software implementation (server) running on a general
purpose operating system, the Reboot-Time AVP will probably not be
present since it is possible that the DIAMETER server has been
stopped and it is not possible to know how long before (and if) it
will be restarted.
Upon receipt of this message the peer's Ss and Sr variables must be
reset. It is possible for this message to be received outside the
window (Ns and Nr set to zero) when it follows a reboot.
The DIAMETER Reboot-Ind message does not require a reply. The message
is acknowledged using DIAMETER's reliable transport.
4.2 Keepalive Exchange
DIAMETER uses the Device-Watchdog-Ind message as a keepalive
mechanism. DIAMETER entities that need to ensure that connectivity
with a peer is not lost may use this mechanism.
A DIAMETER Client can use this mechanism to ensure that failover to
an alternate server occurs even without any AAA traffic. Redundant
DIAMETER Servers use this mechanism to identify when the primary
server is no longer available.
The DIAMETER Device-Watchdog-Ind message does not require a reply.
The message is acknowledged using DIAMETER's reliable transport.
4.3 Unrecognized Command Support
The DIAMETER protocol provides a message that is used to inform a
peer that a DIAMETER message was received with an unrecognized
command. The following provides a DIAMETER message that is sent to a
peer:
Calhoun, Rubens expires April 1999 [Page 37]
INTERNET DRAFT November 1998
<Take-A-Hike-Req> ::= <DIAMETER Header>
<Take-A-Hike-Req Command AVP>
<Host-IP-Address AVP>
[<Host-Name AVP>]
<Timestamp AVP>
<Initialization-Vector AVP>
{<Integrity-Check-Vector AVP> ||
<Digital-Signature AVP }
Upon receipt of the above message, the receiver notices that it does
not support the command and sends the following message:
<Message-Reject-Ind> ::= <DIAMETER Header>
<Message-Reject-Ind Command AVP>
<Unrecognized-Command-Code AVP>
<Host-IP-Address AVP>
[<Host-Name AVP>]
<Timestamp AVP>
<Initialization-Vector AVP>
{<Integrity-Check-Vector AVP> ||
<Digital-Signature AVP }
4.4 The art of AVP Tagging
The AVP Header provides the 'T' bit that is used for grouping AVPs
together. Although the base protocol does not define any AVPs that
need to be grouped, it is envisioned that DIAMETER extensions will
require tag support.
In the case where multiple AVPs are needed to indicate a specific
authorization "rule" tagging is appropriate. Such an example is taken
from [10] that discusses Tunneling attributes. In this case multiple
AVPs are required in order to specify tunnel parameter, and more than
one set of AVPs MAY be present in the message. This is necessary in
order to support redundant tunnel servers.
In this case, the AVPs that need to be grouped together would have a
specific tag value, and each group would use a different tag value.
4.5 Using the Integrity-Check-Vector
The use of the Integrity-Check-Vector (ICV) AVP requires a pre-
configured shared secret. Although this mechanism does not scale as
well as the Digital Signature, it may be desirable to use this
mechanism in the case where asymmetric technology is not required or
available.
Calhoun, Rubens expires April 1999 [Page 38]
INTERNET DRAFT November 1998
Note that in the case where two DIAMETER nodes need to communicate
through an intermediate node (i.e. Proxy) it does not offer any end-
to-end data integrity or encryption as each node must re-compute the
Integrity-Check-Vector AVP.
The Data field of the AVP contains an HMAC-MD5-96[6] of the message
up to the ICV AVP. Using the example code provided in [6], the
following call would be used to generate the Integrity-Check-Vector:
The Timestamp and Initialization-Vector AVPs MUST be present in the
message PRIOR to the Integrity-Check-Vector AVP. The Timestamp AVP
provides replay protection and the Initialization-Vector AVP provides
randomness.
hmac_md5(DiameterMessage, MessageLength, Secret, Secretlength,
Output)
The following is an example of a message that include hop-by-hop
security:
<DIAMETER Message> ::= <DIAMETER Header>
<DIAMETER-Command AVP>
[<Additional AVPs>]
<Timestamp AVP>
<Initialization-Vector AVP>
<Integrity-Check-Vector AVP>
Any AVPs in a message that is not succeeded by the Integrity-Check-
Vector AVP MUST be ignored.
4.6 AVP Encryption with Shared Secrets
This method of encrypting AVP data is the simplest to use and MUST be
supported by all DIAMETER implementations. However, local policy MAY
determine that the use of this mechanism is not permitted.
The 'H' bit MUST only be set if a shared secret exists between both
DIAMETER peers. If the 'H' bit is set in any DIAMETER AVP, the
Initialization-Vector AVP MUST be present prior to the first
encrypted AVP.
The length of the AVP value to be encrypted is first encoded in the
following Subformat, which is included in the AVP's data field.
Calhoun, Rubens expires April 1999 [Page 39]
INTERNET DRAFT November 1998
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of ClearText Data | ClearText Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length
The Length field contains the length of the decrypted data.
ClearText Data
Data of AVP that is to be obscured.
Padding
Random additional octets used to obscure length of the ClearText
Data.
The resulting subformat MAY be padded to a multiple of 16 octets in
length. For example, if the ClearText Data to be obscured is a string
containing 6 characters (e.g. password 'foobar'), then 8 + n * 16
octets of padding would be applied. Padding does NOT alter the value
placed in the Length of the ClearText Data, only the length of the
AVP itself.
Next, An MD5 hash is performed on the concatenation of:
- the two octet Command Code of the AVP
- the shared authentication secret
- an arbitrary length random vector
The value of the random vector used in this hash is passed in the
Data field of a Initialization-Vector AVP. This Initialization-
Vector AVP must appear in the message before any hidden AVPs. The
same Initialization-Vector may be used for more than one hidden AVP
in the same message. If a different Initialization-Vector is used
for the hiding of subsequent AVPs then a new Initialization-Vector
AVP must be placed before the first AVP to which it applies.
The MD5 hash value is then XORed with the first 16 octet or less
segment of the AVP Subformat and placed in the Data field of the AVP.
If the AVP Subformat is less than 16 octets, the Subformat is
transformed as if the Value field had been padded to 16 octets before
the XOR, but only the actual octets present in the Subformat are
modified, and the length of the AVP is not altered.
Calhoun, Rubens expires April 1999 [Page 40]
INTERNET DRAFT November 1998
If the Subformat is longer than 16 octets, a second one-way MD5 hash
is calculated over a stream of octets consisting of the shared secret
followed by the result of the first XOR. That hash is XORed with the
second 16 octet or less segment of the Subformat and placed in the
corresponding octets of the Data field of the AVP.
If necessary, this operation is repeated, with each XOR result being
used along with the shared secret to generate the next hash to XOR
the next segment of the value with. This technique results in the
content of the AVP being obscured, although the length of the AVP is
still known.
On receipt, the Initialization-Vector is taken from the last
Initialization-Vector AVP encountered in the message prior to the AVP
to be decrypted. The above process is then reversed to yield the
original value. For more details on this hiding method, consult
RFC2138 [1].
Please note that in the case where the DIAMETER message needs to be
processed by an intermediate non-trusted DIAMETER server (also known
as a proxy server, depicted as DIA2 in the figure below) the AVP
needs to be decrypted using Shared-Secret-1 and re-encrypted by DIA2
using Shared-Secret-2.
(Shared-Secret-1) (Shared-Secret-2)
+------+ -----> +------+ ------> +------+
| | | | | |
| DIA1 +-------------------+ DIA2 +-------------------+ DIA3 |
| | | | | |
+------+ +------+ +------+
Unfortunately in this case the non-trusted server DIA2 has access to
sensitive information (such as a password).
5.0 References
[1] Rigney, et alia, "RADIUS", RFC-2138, April 1997
[2] Reynolds, Postel, "Assigned Numbers", RFC 1700,
October 1994.
[3] Postel, "User Datagram Protocol", RFC 768, August 1980.
[4] Rivest, Dusse, "The MD5 Message-Digest Algorithm",
RFC 1321, April 1992.
[5] Kaufman, Perlman, Speciner, "Network Security: Private
Communications in a Public World", Prentice Hall,
March 1995, ISBN 0-13-061466-1.
[6] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for Message
Authentication", RFC 2104, January 1997.
Calhoun, Rubens expires April 1999 [Page 41]
INTERNET DRAFT November 1998
[7] Calhoun, Bulley, "DIAMETER User Authentication Extensions",
draft-calhoun-diameter-authen-04.txt, Work in Progress,
August 1998.
[8] Aboba, Beadles, "Network Address Identifier", Internet-Draft,
draft-ietf-roamops-nai-10.txt, Work in Progress,
February 1998.
[9] Calhoun, Zorn, Pan, "DIAMETER Framework",
draft-calhoun-diameter-framework-01.txt, Work in Progress,
August 1998
[10] Zorn, Leifer, Rubens, Shriver, "RADIUS attributes for
Tunnel Protocol Support",
draft-ietf-radius-tunnel-auth-05.txt, Work in Progress,
April 1998.
[11] Calhoun, Bulley, "DIAMETER Reliable Transport Extension",
draft-calhoun-diameter-reliable-00.txt,
Work in Progress, August 1998.
[12] Calhoun, Bulley, "DIAMETER Proxy Extension",
draft-calhoun-diameter-proxy-00.txt, Work in Progress,
August 1998.
6.0 Acknowledgements
The Authors would like to acknowledge the following people for their
contribution in the development of the DIAMETER protocol:
Bernard Aboba, Jari Arkko, William Bulley, Daniel C. Fox, Lol Grant,
Ignacio Goyret, Nancy Greene, Erik Guttman, Peter Heitman, Fergal
Ladley, Ryan Moats, Victor Muslin, Kenneth Peirce, Nenad Trifunovic,
Sumit Vakil, John R. Vollbrecht, Jeff Weisberg and Glen Zorn
7.0 Author's Address
Questions about this memo can be directed to:
Pat R. Calhoun
Technology Development
Sun Microsystems, Inc.
15 Network Circle
Menlo Park, California, 94025
USA
Phone: 1-650-786-7733
Fax: 1-650-786-6445
E-mail: pcalhoun@eng.sun.com
Calhoun, Rubens expires April 1999 [Page 42]
INTERNET DRAFT November 1998
Allan C. Rubens
Ascend Communications
1678 Broadway
Ann Arbor, MI 48105-1812
USA
Phone: 1-734-761-6025
E-Mail: acr@del.com
Calhoun, Rubens expires April 1999 [Page 43]