Diameter Attributes
Diameter Attribute Value Pairs (AVPs) carry specific authentication, accounting, authorization, routing and security information as well as configuration details for the request and reply.
Some AVPs may be listed more than once. The effect of such an AVP is specific, and is specified in each case by the AVP description.
Each AVP of type OctetString must be padded to align on a 32-bit boundary, while other AVP types align naturally. A number of zero-valued bytes are added to the end of the AVP Data field till a word boundary is reached. The length of the padding is not reflected in the AVP Length field.
AVP Header
The AVP header contains the following three fields that requires IANA namespace management.
- AVP Code
- Vendor-ID
- Flags
The fields in the AVP header MUST be sent in network byte order. The format of the header is:
|
Field |
Description |
|---|---|
|
AVP Code |
The AVP Code, combined with the Vendor-ID field, identifies the attribute uniquely. AVP numbers 1 through 255 are reserved for backward compatibility with RADIUS, without setting the Vendor-ID field. AVP numbers 256 and above are used for Diameter, which are allocated by IANA. |
|
AVP Flags |
The AVP Flags field informs the receiver how each attribute must be handled. The 'r' (reserved) bits are unused and SHOULD be set to 0. Note that subsequent Diameter applications may define additional bits within the AVP Header, and an unrecognized bit SHOULD be considered an error. The 'P' bit indicates the need for encryption for end-to-end security. The 'M' Bit, known as the Mandatory bit, indicates whether support of the AVP is required. If an AVP with the 'M' bit set is received by a Diameter client, server, proxy, or translation agent and either the AVP or its value is unrecognized, the message MUST be rejected. Diameter Relay and redirect agents MUST NOT reject messages with unrecognized AVPs. The 'M' bit MUST be set according to the rules defined for the AVP containing it. In order to preserve interoperability, a Diameter implementation MUST be able to exclude from a Diameter message any Mandatory AVP which is neither defined in the base Diameter protocol nor in any of the Diameter Application specifications governing the message in which it appears. It may do this in one of the following ways:
Diameter implementations are required to support all Mandatory AVPs which are allowed by the message's formal syntax and defined either in the base Diameter standard or in one of the Diameter Application specifications governing the message. AVPs with the 'M' bit cleared are informational only and a receiver that receives a message with such an AVP that is not supported, or whose value is not supported, MAY simply ignore the AVP. 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. Unless otherwise noted, AVPs will have the following default AVP Flags field settings: The 'M' bit MUST be set. The 'V' bit MUST NOT be set. |
|
AVP Length |
The AVP Length field is three octets, and indicates the number of octets in this AVP including the AVP Code, AVP Length, AVP Flags, Vendor-ID field (if present) and the AVP data. If a message is received with an invalid attribute length, the message SHOULD be rejected. |
|
Vendor-ID |
This field is optional. The Vendor-ID field is present if the 'V' bit is set in the AVP Flags field. 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 a vendor-specific Diameter AVP MUST use their own Vendor-ID along with their privately managed AVP address space, guaranteeing that they will not collide with any other vendor's vendor-specific AVP(s), nor with future IETF applications. A vendor ID value of zero (0) corresponds to the IETF adopted AVP values, as managed by the IANA. Since the absence of the vendor ID field implies that the AVP in question is not vendor specific, implementations MUST NOT use the zero (0) vendor ID. |
Basic AVP Data Formats
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 Data field MUST be one of the following base data types or a data type derived from the base data types.
|
AVP Data Format |
Meaning |
|---|---|
|
OctetString |
The data contains arbitrary data of variable length. Unless otherwise noted, the AVP Length field MUST be set to at least 8 (12 if the 'V' bit is enabled). AVP Values of this type that are not a multiple of four-octets in length is followed by the necessary padding so that the next AVP (if any) will start on a 32-bit boundary. |
|
Integer32 |
32 bit signed value, in network byte order. The AVP Length field MUST be set to 12 (16 if the 'V' bit is enabled). |
|
Integer64 |
64 bit signed value, in network byte order. The AVP Length field MUST be set to 16 (20 if the 'V' bit is enabled). |
|
Unsigned32 |
32 bit unsigned value, in network byte order. The AVP Length field MUST be set to 12 (16 if the 'V' bit is enabled). |
|
Unsigned64 |
64 bit unsigned value, in network byte order. The AVP Length field MUST be set to 16 (20 if the 'V' bit is enabled). |
|
Float32 |
This represents floating point values of single precision. The 32-bit value is transmitted in network byte order. The AVP Length field MUST be set to 12 (16 if the 'V' bit is enabled). |
|
Float64 |
This represents floating point values of double precision. The 64-bit value is transmitted in network byte order. The AVP Length field MUST be set to 16 (20 if the 'V' bit is enabled). |
|
Grouped |
The Data field is specified as a sequence of AVPs. Each of these AVPs follows - in the order in which they are specified - including their headers and padding. The AVP Length field is set to 8 (12 if the 'V' bit is enabled) plus the total length of all included AVPs, including their headers and padding. Thus the AVP length field of an AVP of type Grouped is always a multiple of 4. |
Derived AVP Data Formats
In addition to using the Basic AVP Data Formats, applications may define data formats derived from the Basic AVP Data Formats. An application that defines new AVP Derived Data Formats MUST include them in a section entitled "AVP Derived Data Formats", using the same format as the definitions below. Each new definition must be either defined or listed with a reference to the RFC that defines the format.
The below AVP Derived Data Formats are commonly used by applications.
Address
The Address format is derived from the OctetString AVP Base Format. It is a discriminated union, representing, for example a 32-bit (IPv4) or 128-bit (IPv6) address, most significant octet first. The first two octets of the Address
AVP represents the AddressType, which contains an Address Family defined in IANAADFAM. The AddressType is used to discriminate the content and format of the remaining octets.
Time
The Time format is derived from the OctetString AVP Base Format. The string MUST contain four octets, in the same format as the first four bytes are in the NTP timestamp format.
This represents the number of seconds since 0h on 1 January 1900 with respect to the Coordinated Universal Time (UTC).
On 6h 28m 16s UTC, 7 February 2036 the time value will overflow. SNTP describes a procedure to extend the time to 2104. This procedure MUST be supported by all DIAMETER nodes.
UTF8String
The UTF8String format is derived from the OctetString AVP Base Format. This is a human readable string represented using the ISO/IEC IS 10646-1 character set, encoded as an OctetString using the UTF-8 [UFT8] transformation format described in RFC 2279.
Since additional code points are added by amendments to the 10646 standard from time to time, implementations MUST be prepared to encounter any code point from 0x00000001 to 0x7fffffff. Byte sequences that do not correspond to the valid encoding of a code point into UTF-8 charset or are outside this range are prohibited.
The use of control codes SHOULD be avoided. When it is necessary to represent a new line, the control code sequence CR LF SHOULD be used.
The use of leading or trailing white space SHOULD be avoided.
For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, MAY be provided.
For information encoded in 7-bit US-ASCII, the UTF-8 charset is identical to the US-ASCII charset.
UTF-8 may require multiple bytes to represent a single character / code point; thus the length of an UTF8String in octets may be different from the number of characters encoded.
Note that the AVP Length field of an UTF8String is measured in octets, not characters.
DiameterIdentity
The DiameterIdentity (DIAMIDENT) format is derived from the OctetString AVP Base Format.
DiameterIdentity = FQDN
DiameterIdentity value is used to uniquely identify a Diameter node for purposes of duplicate connection and routing loop detection.
The contents of the string MUST be the FQDN of the Diameter node. If multiple Diameter nodes run on the same host, each Diameter node MUST be assigned a unique DiameterIdentity. If a Diameter node can be identified by several FQDNs, a single FQDN should be picked at startup, and used as the only DiameterIdentity for that node, whatever the connection it is sent on.
DiameterURI
The DiameterURI (DIAMURI) MUST follow the Uniform Resource Identifiers (URI) syntax [URI] rules specified below:
"aaa://" FQDN [ port ] [ transport ] [ protocol ] – or –
"aaas://" FQDN [ port ] [ transport ] [ protocol ] |
Field |
Description |
|---|---|
|
FQDN |
Fully Qualified Host Name |
|
port |
One of the ports used to listen for incoming connections. If absent, the default Diameter port (3868) is assumed. |
|
transport |
One of the transport protocols used to listen for incoming connections. If absent, the default SCTP protocol is assumed. UDP MUST NOT be used when the aaa-protocol field is set to diameter. The transport protocol could be tcp, sctp, or udp. |
|
protocol |
This field denotes AAA protocol. If absent, the default AAA protocol is diameter. The AAA protocol could be diameter, radius, or tacacs+. |
The following are examples of valid Diameter host identities:
aaa://host.example.com;transport=tcp
aaa://host.example.com:6666;transport=tcp
aaa://host.example.com;protocol=diameter
aaa://host.example.com:6666;protocol=diameter
aaa://host.example.com:6666;transport=tcp;protocol=diameter
aaa://host.example.com:1813;transport=udp;protocol=radius Enumerated
Enumerated is derived from the Integer32 AVP Base Format. The definition contains a list of valid values and their interpretation and is described in the Diameter application introducing the AVP.
IPFilterRule
The IPFilterRule format is derived from the OctetString AVP Base Format. It uses the ASCII charset. Packets may be filtered based on the following information that is associated with it:
- Direction (in or out)
- Source and destination IP address (possibly masked)
- Protocol
- Source and destination port (lists or ranges)
- TCP flags
- IP fragment flag
- IP options
- ICMP types
Rules for the appropriate direction are evaluated in order, with the first matched rule terminating the evaluation. Each packet is evaluated once. If no rule matches, the packet is dropped if the last rule evaluated was a permit, and passed if the last rule was a deny.
IPFilterRule filters MUST follow the format:
action dir proto from src to dst [options] |
Field |
Description |
|---|---|
|
action |
This field can be set to one of the following:
|
|
dir |
"in" is from the terminal and "out" is to the terminal. |
|
proto |
An IP protocol specified by number. The "ip" keyword means any protocol will match. |
|
src and dst |
<address/mask> [ports] The <address/mask> may be specified as: ipno — An IPv4 or IPv6 number in dotted-quad or canonical IPv6 form. Only this exact IP number will match the rule. ipno/bits — An IP number as above with a mask width of the form 1.2.3.4/24. In this case, all IP numbers from 1.2.3.0 to 1.2.3.255 will match. The bit width MUST be valid for the IP version and the IP number MUST NOT have bits set beyond the mask. For a match to occur, the same IP version must be present in the packet that was used in describing the IP address. To test for a particular IP version, the bits part can be set to zero. The keyword "any" is 0.0.0.0/0 or the IPv6 equivalent. The keyword "assigned" is the address or set of addresses assigned to the terminal. For IPv4, a typical first rule is often "deny in ip! assigned" The sense of the match can be inverted by preceding an address with the not modifier (!), causing all other addresses to be matched instead. This does not affect the selection of port numbers. With the TCP, UDP and SCTP protocols, optional ports may be specified as: The '-' notation specifies a range of ports (including boundaries). Fragmented packets that have a non-zero offset (i.e., not the first fragment) will never match a rule that has one or more port specifications. See the frag option for details on matching fragmented packets. |
|
options |
The different options are as follows:
|
QoSFilterRule
The QosFilterRule format is derived from the OctetString AVP Base Format. It uses the ASCII charset. Packets may be marked or metered based on the following information that is associated with it:
- Direction (in or out)
- Source and destination IP address (possibly masked)
- Protocol
- Source and destination port (lists or ranges)
- DSCP values (no mask or range)
Rules for the appropriate direction are evaluated in order, with the first matched rule terminating the evaluation. Each packet is evaluated once. If no rule matches, the packet is treated as best effort. An access device that is unable to interpret or apply a QoS rule SHOULD NOT terminate the session
QoSFilterRule filters MUST follow the format:
action dir proto from src to dst [options] |
Field |
Description |
|---|---|
|
action |
This field can be set to one of the following:
|
|
dir |
The format is as described under IPFilterRule. |
|
proto |
The format is as described under IPFilterRule. |
|
src and dst |
The format is as described under IPFilterRule. |
|
options |
The following options are available in addition to the ones described under IPFilterRule:
|
Grouped AVP Values
The Diameter protocol allows AVP values of type 'Grouped.' This implies that the Data field is actually a sequence of AVPs. It is possible to include an AVP with a Grouped type within a Grouped type, that is, to nest them. AVPs within an AVP of type Grouped have the same padding requirements as non-Grouped AVPs.
The AVP Code numbering space of all AVPs included in a Grouped AVP is the same as for non-grouped AVPs. Further, if any of the AVPs encapsulated within a Grouped AVP has the 'M' (mandatory) bit set, the Grouped AVP itself MUST also include the 'M' bit set.
Every Grouped AVP defined MUST include a corresponding grammar, using ABNF (with modifications), as defined below.
grouped-avp-def = name "::=" avp
name-fmt = ALPHA *(ALPHA / DIGIT / "-")
name = name-fmt
avp = header [ *fixed] [ *required] [ *optional] [ *fixed]
header = "<" "AVP-Header:" avpcode [vendor] ">"
avpcode = 1*DIGIT
vendor = 1*DIGIT Where, name = the name of an AVP, defined in the base or extended Diameter specifications.
avp code = The AVP Code assigned to the Grouped AVP.
vendor = The Vendor-ID assigned to the Grouped AVP. If absent, the default value of zero is used.
The Example-AVP (AVP Code 999999) is of type Grouped and is used to clarify how Grouped AVP values work. The Grouped Data field has the following ABNF grammar:
Example-AVP ::= < AVP Header: 999999 >
{ Origin-Host }
1*{ Session-Id }
*[ AVP ] An Example-AVP with Grouped Data follows. The Origin-Host AVP is required.
In this case, Origin-Host = "example.com".
One or more Session-IDs must follow. Here there are two:
Session-Id = "grump.example.com:33041;23432;893;0AF3B81" Session-Id = "grump.example.com:33054;23561;2358;0AF3B82" Optional AVPs included are:
Recovery-Policy = <binary> 2163bc1d0ad82371f6bc09484133c3f09ad74a0dd5346d54195a7cf0b35 2cabc881839a4fdcfbc1769e2677a4c1fb499284c5f70b48f58503a45c5 c2d6943f82d5930f2b7c1da640f476f0e9c9572a50db8ea6e51e1c2c7bd f8bb43dc995144b8dbe297ac739493946803e1cee3e15d9b765008a1b2a cf4ac777c80041d72c01e691cf751dbf86e85f509f3988e5875dc905119 26841f00f0e29a6d1ddc1a842289d440268681e052b30fb638045f7779c 1d873c784f054f688f5001559ecff64865ef975f3e60d2fd7966b8c7f92
Futuristic-Acct-Record = <binary> fe19da5802acd98b07a5b86cb4d5d03f0314ab9ef1ad0b67111ff3b90a0 57fe29620bf3585fd2dd9fcc38ce62f6cc208c6163c008f4258d1bc88b8 17694a74ccad3ec69269461b14b2e7a4c111fb239e33714da207983f58c 41d018d56fe938f3cbf089aac12a912a2f0d1923a9390e5f789cb2e5067 d3427475e49968f841 The data for the optional AVPs is represented in hexadecimal since the format of these AVPs is neither known at the time of definition of the Example-AVP group, nor (likely) at the time when the example instance of this AVP is interpreted - except by Diameter implementations which support the same set of AVPs. Also note that AVPs may be present in the Grouped AVP value which the receiver cannot interpret (here, the Recover-Policy and Futuristic-Acct-Record AVPs).
Feedback