following AVPs, used to describe a compulsory tunnel service:
[RADTunnels], [RADTunlAcct]. Its data field has the following ABNF
grammar:
Tunneling ::= < AVP Header: 401 >
{ Tunnel-Type }
{ Tunnel-Medium-Type }
{ Tunnel-Client-Endpoint }
{ Tunnel-Server-Endpoint }
[ Tunnel-Preference ]
[ Tunnel-Client-Auth-Id ]
[ Tunnel-Server-Auth-Id ]
[ Tunnel-Assignment-Id ]
[ Tunnel-Password ]
[ Tunnel-Private-Group-Id ]
7.2. Tunnel-Type AVP
The Tunnel-Type AVP (AVP Code 64) is of type Enumerated and contains
the tunneling protocol(s) to be used (in the case of a tunnel
initiator) or in use (in the case of a tunnel terminator). It MAY be
used in an authorization request as a hint to the server that a
specific tunnel type is desired, but the server is not required to
honor the hint in the corresponding response.
The Tunnel-Type AVP SHOULD also be included in Accounting-Request
messages.
A tunnel initiator is not required to implement any of these tunnel
types. If a tunnel initiator receives a response that contains only
unknown or unsupported Tunnel-Types, the tunnel initiator MUST behave
as though a response were received with the Result-Code indicating a
failure.
The supported values are listed in [RADIUSTypes]. The following list
is informational:
1 Point-to-Point Tunneling Protocol (PPTP)
2 Layer Two Forwarding (L2F)
3 Layer Two Tunneling Protocol (L2TP)
4 Ascend Tunnel Management Protocol (ATMP)
5 Virtual Tunneling Protocol (VTP)
6 IP Authentication Header in the Tunnel-mode (AH)
7 IP-in-IP Encapsulation (IP-IP)
8 Minimal IP-in-IP Encapsulation (MIN-IP-IP)
9 IP Encapsulating Security Payload in the Tunnel-mode (ESP)
10 Generic Route Encapsulation (GRE)
11 Bay Dial Virtual Services (DVS)
12 IP-in-IP Tunneling
13 Virtual LANs (VLAN)
7.3. Tunnel-Medium-Type AVP
The Tunnel-Medium-Type AVP (AVP Code 65) is of type Enumerated and
contains the transport medium to use when creating a tunnel for
protocols (such as L2TP) that can operate over multiple transports.
It MAY be used in an authorization request as a hint to the server
that a specific medium is desired, but the server is not required to
honor the hint in the corresponding response.
The supported values are listed in [RADIUSTypes]. The following list
is informational:
1 IPv4 (IP version 4)
2 IPv6 (IP version 6)
3 NSAP
4 HDLC (8-bit multidrop)
5 BBN 1822
6 802 (includes all 802 media plus Ethernet "canonical
format")
7 E.163 (POTS)
8 E.164 (SMDS, Frame Relay, ATM)
9 F.69 (Telex)
10 X.121 (X.25, Frame Relay)
11 IPX
12 Appletalk
13 Decnet IV
14 Banyan Vines
15 E.164 with NSAP format subaddress
7.4. Tunnel-Client-Endpoint AVP
The Tunnel-Client-Endpoint AVP (AVP Code 66) is of type UTF8String
and contains the address of the initiator end of the tunnel. It MAY
be used in an authorization request as a hint to the server that a
specific endpoint is desired, but the server is not required to honor
the hint in the corresponding response.
This AVP SHOULD be included in the corresponding Accounting-Request
messages, in which case it indicates the address from which the
tunnel was initiated. This AVP, along with the Tunnel-Server-
Endpoint and Session-Id AVP [BASE], MAY be used to provide a globally
unique means to identify a tunnel for accounting and auditing
purposes.
If Tunnel-Medium-Type is IPv4 (1), then this string is either the
fully qualified domain name (FQDN) of the tunnel client machine, or a
"dotted-decimal" IP address. Implementations MUST support the
dotted-decimal format and SHOULD support the FQDN format for IP
addresses.
If Tunnel-Medium-Type is IPv6 (2), then this string is either the
FQDN of the tunnel client machine, or a text representation of the
address in either the preferred or alternate form [IPv6Addr].
Conforming implementations MUST support the preferred form and SHOULD
support both the alternate text form and the FQDN format for IPv6
addresses.
If Tunnel-Medium-Type is neither IPv4 nor IPv6, then this string is a
tag referring to configuration data local to the Diameter client that
describes the interface or medium-specific client address to use.
7.5. Tunnel-Server-Endpoint AVP
The Tunnel-Server-Endpoint AVP (AVP Code 67) is of type UTF8String
and contains the address of the server end of the tunnel. It MAY be
used in an authorization request as a hint to the server that a
specific endpoint is desired, but the server is not required to honor
the hint in the corresponding response.
This AVP SHOULD be included in the corresponding Accounting-Request
messages, in which case it indicates the address from which the
tunnel was initiated. This AVP, along with the Tunnel-Client-
Endpoint and Session-Id AVP [BASE], MAY be used to provide a globally
unique means to identify a tunnel for accounting and auditing
purposes.
If Tunnel-Medium-Type is IPv4 (1), then this string is either the
fully qualified domain name (FQDN) of the tunnel server machine, or a
"dotted-decimal" IP address. Implementations MUST support the
dotted-decimal format and SHOULD support the FQDN format for IP
addresses.
If Tunnel-Medium-Type is IPv6 (2), then this string is either the
FQDN of the tunnel server machine, or a text representation of the
address in either the preferred or alternate form [IPv6Addr].
Implementations MUST support the preferred form and SHOULD support
both the alternate text form and the FQDN format for IPv6 addresses.
If Tunnel-Medium-Type is not IPv4 or IPv6, this string is a tag
referring to configuration data local to the Diameter client that
describes the interface or medium-specific server address to use.
7.6. Tunnel-Password AVP
The Tunnel-Password AVP (AVP Code 69) is of type OctetString and may
contain a password to be used to authenticate to a remote server.
The Tunnel-Password AVP contains sensitive information. This value
is not protected in the same manner as RADIUS [RADTunnels].
As required in [BASE], Diameter messages are encrypted by using IPsec
or TLS. The Tunnel-Password AVP SHOULD NOT be used in untrusted
proxy environments without encrypting it by using end-to-end security
techniques, such as CMS Security [DiamCMS].
7.7. Tunnel-Private-Group-Id AVP
The Tunnel-Private-Group-Id AVP (AVP Code 81) is of type OctetString
and contains the group Id for a particular tunneled session. The
Tunnel-Private-Group-Id AVP MAY be included in an authorization
request if the tunnel initiator can predetermine the group resulting
from a particular connection. It SHOULD be included in the
authorization response if this tunnel session is to be treated as
belonging to a particular private group. Private groups may be used
to associate a tunneled session with a particular group of users.
For example, it MAY be used to facilitate routing of unregistered IP
addresses through a particular interface. This AVP SHOULD be
included in the Accounting-Request messages that pertain to the
tunneled session.
7.8. Tunnel-Assignment-Id AVP
The Tunnel-Assignment-Id AVP (AVP Code 82) is of type OctetString and
is used to indicate to the tunnel initiator the particular tunnel to
which a session is to be assigned. Some tunneling protocols, such as
[PPTP] and [L2TP], allow for sessions between the same two tunnel
endpoints to be multiplexed over the same tunnel and also for a given
session to use its own dedicated tunnel. This attribute provides a
mechanism for Diameter to inform the tunnel initiator (e.g., PAC,
LAC) whether to assign the session to a multiplexed tunnel or to a
separate tunnel. Furthermore, it allows for sessions sharing
multiplexed tunnels to be assigned to different multiplexed tunnels.
A particular tunneling implementation may assign differing
characteristics to particular tunnels. For example, different
tunnels may be assigned different QoS parameters. Such tunnels may
be used to carry either individual or multiple sessions. The
Tunnel-Assignment-Id attribute thus allows the Diameter server to
indicate that a particular session is to be assigned to a tunnel
providing an appropriate level of service. It is expected that any
QoS-related Diameter tunneling attributes defined in the future
accompanying this one will be associated by the tunnel initiator with
the Id given by this attribute. In the meantime, any semantic given
to a particular Id string is a matter left to local configuration in
the tunnel initiator.
The Tunnel-Assignment-Id AVP is of significance only to Diameter and
the tunnel initiator. The Id it specifies is only intended to be of
local use to Diameter and the tunnel initiator. The Id assigned by
the tunnel initiator is not conveyed to the tunnel peer.
This attribute MAY be included in authorization responses. The
tunnel initiator receiving this attribute MAY choose to ignore it and
to assign the session to an arbitrary multiplexed or non-multiplexed
tunnel between the desired endpoints. This AVP SHOULD also be
included in the Accounting-Request messages pertaining to the
tunneled session.
If a tunnel initiator supports the Tunnel-Assignment-Id AVP, then it
should assign a session to a tunnel in the following manner:
- If this AVP is present and a tunnel exists between the
specified endpoints with the specified Id, then the session
should be assigned to that tunnel.
- If this AVP is present and no tunnel exists between the
specified endpoints with the specified Id, then a new tunnel
should be established for the session and the specified Id
should be associated with the new tunnel.
- If this AVP is not present, then the session is assigned to an
unnamed tunnel. If an unnamed tunnel does not yet exist
between the specified endpoints, then it is established and
used for this session and for subsequent ones established
without the Tunnel-Assignment-Id attribute. A tunnel initiator
MUST NOT assign a session for which a Tunnel-Assignment-Id AVP
was not specified to a named tunnel (i.e., one that was
initiated by a session specifying this AVP).
Note that the same Id may be used to name different tunnels if these
tunnels are between different endpoints.
7.9. Tunnel-Preference AVP
The Tunnel-Preference AVP (AVP Code 83) is of type Unsigned32 and is
used to identify the relative preference assigned to each tunnel when
more than one set of tunneling AVPs is returned within separate
Grouped-AVP AVPs. It MAY be used in an authorization request as a
hint to the server that a specific preference is desired, but the
server is not required to honor the hint in the corresponding
response.
For example, suppose that AVPs describing two tunnels are returned by
the server, one with a Tunnel-Type of PPTP and the other with a
Tunnel-Type of L2TP. If the tunnel initiator supports only one of
the Tunnel-Types returned, it will initiate a tunnel of that type.
If, however, it supports both tunnel protocols, it SHOULD use the
value of the Tunnel-Preference AVP to decide which tunnel should be
started. The tunnel with the lowest numerical value in the Value
field of this AVP SHOULD be given the highest preference. The values
assigned to two or more instances of the Tunnel-Preference AVP within
a given authorization response MAY be identical. In this case, the
tunnel initiator SHOULD use locally configured metrics to decide
which set of AVPs to use.
7.10. Tunnel-Client-Auth-Id AVP
The Tunnel-Client-Auth-Id AVP (AVP Code 90) is of type UTF8String and
specifies the name used by the tunnel initiator during the
authentication phase of tunnel establishment. It MAY be used in an
authorization request as a hint to the server that a specific
preference is desired, but the server is not required to honor the
hint in the corresponding response. This AVP MUST be present in the
authorization response if an authentication name other than the
default is desired. This AVP SHOULD be included in the Accounting-
Request messages pertaining to the tunneled session.
7.11. Tunnel-Server-Auth-Id AVP
The Tunnel-Server-Auth-Id AVP (AVP Code 91) is of type UTF8String and
specifies the name used by the tunnel terminator during the
authentication phase of tunnel establishment. It MAY be used in an
authorization request as a hint to the server that a specific
preference is desired, but the server is not required to honor the
hint in the corresponding response. This AVP MUST be present in the
authorization response if an authentication name other than the
default is desired. This AVP SHOULD be included in the Accounting-
Request messages pertaining to the tunneled session.
8. NAS Accounting
Applications implementing this specification use Diameter Accounting,
as defined in [BASE], and the AVPs in the following section.
Service-specific AVP usage is defined in the tables in section 10.
If accounting is active, Accounting Request (ACR) messages SHOULD be
sent after the completion of any Authentication or Authorization
transaction and at the end of a Session. The Accounting-Record-Type
value indicates the type of event. All other AVPs identify the
session and provide additional information relevant to the event.
The successful completion of the first Authentication or
Authorization transaction SHOULD cause a START_RECORD to be sent. If
additional Authentications or Authorizations occur in later
transactions, the first exchange should generate a START_RECORD, and
the later an INTERIM_RECORD. For a given session, there MUST only be
one set of matching START and STOP records, with any number of
INTERIM_RECORDS in between, or one EVENT_RECORD indicating the reason
a session wasn’t started.
The following table describes the AVPs; their AVP Code values, types,
and possible flag values; and whether the AVP MAY be encrypted.
+---------------------+
| AVP Flag rules |
|----+-----+----+-----|----+
AVP Section | | |SHLD| MUST| |
Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr|
-----------------------------------------|----+-----+----+-----|----|
Accounting- 363 8.1 Unsigned64 | M | P | | V | Y |
Input-Octets | | | | | |
Accounting- 364 8.2 Unsigned64 | M | P | | V | Y |
Output-Octets | | | | | |
Accounting- 365 8.3 Unsigned64 | M | P | | V | Y |
Input-Packets | | | | | |
Accounting- 366 8.4 Unsigned64 | M | P | | V | Y |
Output-Packets | | | | | |
Acct-Session-Time 46 8.5 Unsigned32 | M | P | | V | Y |
Acct-Authentic 45 8.6 Enumerated | M | P | | V | Y |
Acounting-Auth- 406 8.7 Enumerated | M | P | | V | Y |
Method | | | | | |
Acct-Delay-Time 41 8.8 Unsigned32 | M | P | | V | Y |
Acct-Link-Count 51 8.9 Unsigned32 | M | P | | V | Y |
Acct-Tunnel- 68 8.10 OctetString| M | P | | V | Y |
Connection | | | | | |
Acct-Tunnel- 86 8.11 Unsigned32 | M | P | | V | Y |
Packets-Lost | | | | | |
-----------------------------------------|----+-----+----+-----|----|
8.1. Accounting-Input-Octets AVP
The Accounting-Input-Octets AVP (AVP Code 363) is of type Unsigned64
and contains the number of octets received from the user.
For NAS usage, this AVP indicates how many octets have been received
from the port in the course of this session. It can only be present
in ACR messages with an Accounting-Record-Type of INTERIM_RECORD or
STOP_RECORD.
8.2. Accounting-Output-Octets AVP
The Accounting-Output-Octets AVP (AVP Code 364) is of type Unsigned64
and contains the number of octets sent to the user.
For NAS usage, this AVP indicates how many octets have been sent to
the port in the course of this session. It can only be present in
ACR messages with an Accounting-Record-Type of INTERIM_RECORD or
STOP_RECORD.
8.3. Accounting-Input-Packets AVP
The Accounting-Input-Packets (AVP Code 365) is of type Unsigned64 and
contains the number of packets received from the user.
For NAS usage, this AVP indicates how many packets have been received
from the port over the course of a session being provided to a Framed
User. It can only be present in ACR messages with an Accounting-
Record-Type of INTERIM_RECORD or STOP_RECORD.
8.4. Accounting-Output-Packets AVP
The Accounting-Output-Packets (AVP Code 366) is of type Unsigned64
and contains the number of IP packets sent to the user.
For NAS usage, this AVP indicates how many packets have been sent to
the port over the course of a session being provided to a Framed
User. It can only be present in ACR messages with an Accounting-
Record-Type of INTERIM_RECORD or STOP_RECORD.
8.5. Acct-Session-Time AVP
The Acct-Session-Time AVP (AVP Code 46) is of type Unsigned32 and
indicates the length of the current session in seconds. It can only
be present in ACR messages with an Accounting-Record-Type of
INTERIM_RECORD or STOP_RECORD.
8.6. Acct-Authentic AVP
The Acct-Authentic AVP (AVP Code 45) is of type Enumerated and
specifies how the user was authenticated. The supported values are
listed in [RADIUSTypes]. The following list is informational:
1 RADIUS
2 Local
3 Remote
4 Diameter
8.7. Accounting-Auth-Method AVP
The Accounting-Auth-Method AVP (AVP Code 406) is of type Enumerated.
A NAS MAY include this AVP in an Accounting-Request message to
indicate the method used to authenticate the user. (Note that this
is equivalent to the RADIUS MS-Acct-Auth-Type VSA attribute).
The following values are defined:
1 PAP
2 CHAP
3 MS-CHAP-1
4 MS-CHAP-2
5 EAP
7 None
8.8. Acct-Delay-Time
The Acct-Delay-Time AVP (AVP Code 41) is of type Unsigned32 and
indicates the number of seconds the Diameter client has been trying
to send the Accounting-Request (ACR). The accounting server may
subtract this value from the time when the ACR arrives at the server
to calculate the approximate time of the event that caused the ACR to
be generated.
This AVP is not used for retransmissions at the transport level (TCP
or SCTP). Rather, it may be used when an ACR command cannot be
transmitted because there is no appropriate peer to transmit it to or
was rejected because it could not be delivered. In these cases, the
command MAY be buffered and transmitted later, when an appropriate
peer-connection is available or after sufficient time has passed that
the destination-host may be reachable and operational. If the ACR is
resent in this way, the Acct-Delay-Time AVP SHOULD be included. The
value of this AVP indicates the number of seconds that elapsed
between the time of the first attempt at transmission and the current
attempt.
8.9. Acct-Link-Count
The Acct-Link-Count AVP (AVP Code 51) is of type Unsigned32 and
indicates the total number of links that have been active (current or
closed) in a given multilink session at the time the accounting
record is generated. This AVP MAY be included in Accounting-Requests
for any session that may be part of a multilink service.
The Acct-Link-Count AVP may be used to make it easier for an
accounting server to know when it has all the records for a given
multilink service. When the number of Accounting-Requests received
with Accounting-Record-Type = STOP_RECORD and with the same Acct-
Multi-Session-Id and unique Session-Ids equals the largest value of
Acct-Link-Count seen in those Accounting-Requests, all STOP_RECORD
Accounting-Requests for that multilink service have been received.
The following example, showing eight Accounting-Requests, illustrates
how the Acct-Link-Count AVP is used. In the table below, only the
relevant AVPs are shown, although additional AVPs containing
accounting information will be present in the Accounting-Requests.
Acct-Multi- Accounting- Acct-
Session-Id Session-Id Record-Type Link-Count
--------------------------------------------------------
"...10" "...10" START_RECORD 1
"...10" "...11" START_RECORD 2
"...10" "...11" STOP_RECORD 2
"...10" "...12" START_RECORD 3
"...10" "...13" START_RECORD 4
"...10" "...12" STOP_RECORD 4
"...10" "...13" STOP_RECORD 4
"...10" "...10" STOP_RECORD 4
8.10. Acct-Tunnel-Connection AVP
The Acct-Tunnel-Connection AVP (AVP Code 68) is of type OctetString
and contains the identifier assigned to the tunnel session. This
AVP, along with the Tunnel-Client-Endpoint and Tunnel-Server-Endpoint
AVPs, may be used to provide a means to uniquely identify a tunnel
session for auditing purposes.