Internet Engineering Task Force (IETF) G. Zorn, Ed.
Request for Comments: 7155 Network Zen
Obsoletes: 4005 April 2014
Category: Standards Track
Diameter Network Access Server Application
This document describes the Diameter protocol application used for
Authentication, Authorization, and Accounting services in the Network
Access Server (NAS) environment; it obsoletes RFC 4005. When
combined with the Diameter Base protocol, Transport Profile, and
Extensible Authentication Protocol specifications, this application
specification satisfies typical network access services requirements.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
First, this document describes the operation of a Diameter NAS
application. Then, it defines the Diameter message command codes.
The following sections list the AVPs used in these messages, grouped
by common usage. These are session identification, authentication,
authorization, tunneling, and accounting. The authorization AVPs are
further broken down by service type.
1.1. Changes from RFC 4005
This document obsoletes [RFC4005] and is not backward compatible with
that document. An overview of some of the major changes is given
o All of the material regarding RADIUS/Diameter protocol
interactions has been removed; however, where AVPs are derived
from RADIUS Attributes, the range and format of those Attribute
values have been retained for ease of transition.
o The Command Code Format (CCF) [RFC6733] for the Accounting-Request
and Accounting-Answer messages has been changed to explicitly
require the inclusion of the Acct-Application-Id AVP and exclude
the Vendor-Specific-Application-Id AVP. Normally, this type of
change would require the allocation of a new command code (see
Section 1.3.3 of [RFC6733]) and consequently, a new application-
id. However, the presence of an instance of the Acct-Application-
Id AVP was required in [RFC4005], as well:
The Accounting-Request (ACR) message [BASE] is sent by the NAS
to report its session information to a target server
Either the Acct-Application-Id or the Vendor-Specific-
Application-Id AVP MUST be present. If the Vendor-Specific-
Application-Id grouped AVP is present, it must have an Acct-
Thus, though the syntax of the commands has changed, the semantics
have not (with the caveat that the Acct-Application-Id AVP can no
longer be contained in the Vendor-Specific-Application-Id AVP).
o The lists of RADIUS attribute values have been deleted in favor of
references to the appropriate IANA registries.
o The accounting model to be used is now specified (see
There are many other miscellaneous fixes that have been introduced in
this document that may not be considered significant, but they are
useful nonetheless. Examples are fixes to example IP addresses,
addition of clarifying references, etc. Errata reports filed against
[RFC4005] at the time of writing have been reviewed and incorporated
as necessary. A comprehensive list of changes is not shown here for
Section 1.2 of the Diameter Base protocol specification [RFC6733]
defines most of the terminology used in this document. Additionally,
the following terms and acronyms are used in this application:
NAS (Network Access Server)
A device that provides an access service for a user to a network.
The service may be a network connection or a value-added service
such as terminal emulation [RFC2881].
PPP (Point-to-Point Protocol)
A multiprotocol serial datalink. PPP is the primary IP datalink
used for dial-in NAS connection service [RFC1661].
CHAP (Challenge Handshake Authentication Protocol)
An authentication process used in PPP [RFC1994].
PAP (Password Authentication Protocol)
A deprecated PPP authentication process, but often used for
backward compatibility [RFC1334].
SLIP (Serial Line Internet Protocol)
A serial datalink that only supports IP. A design prior to PPP.
ARAP (AppleTalk Remote Access Protocol)
A serial datalink for accessing AppleTalk networks [ARAP].
IPX (Internetwork Packet Exchange)
The network protocol used by NetWare networks [IPX].
L2TP (Layer Two Tunneling Protocol)
L2TP [RFC3931] provides a dynamic mechanism for tunneling Layer 2
"circuits" across a packet-oriented data network.
LAC (L2TP Access Concentrator)
An L2TP Control Connection Endpoint being used to cross-connect an
L2TP session directly to a datalink [RFC3931].
LAT (Local Area Transport)
A Digital Equipment Corp. LAN protocol for terminal services
LCP (Link Control Protocol)
One of the three major components of PPP [RFC1661]. LCP is used
to automatically agree upon encapsulation format options, handle
varying limits on sizes of packets, detect a looped-back link and
other common misconfiguration errors, and terminate the link.
Other optional facilities provided are authentication of the
identity of its peer on the link, and determination when a link is
functioning properly and when it is failing.
PPTP (Point-to-Point Tunneling Protocol)
A protocol that allows PPP to be tunneled through an IP network
VPN (Virtual Private Network)
In this document, this term is used to describe access services
that use tunneling methods.
1.3. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
The use of "MUST" and "MUST NOT" in the AVP Flag Rules columns of AVP
Tables in this document refers to AVP flags ([RFC6733], Section 4.1)
o MUST be set to 1 in the AVP Header ("MUST" column) and
o MUST NOT be set to 1 ("MUST NOT" column)
1.4. Advertising Application Support
Diameter nodes conforming to this specification MUST advertise
support by including the value of one (1) in the Auth-Application-Id
of the Capabilities-Exchange-Request (CER) message [RFC6733].
1.5. Application Identification
When used in this application, the Auth-Application-Id AVP MUST be
set to the value one (1) in the following messages
o AA-Request (Section 3.1)
o Re-Auth-Request(Section 3.3)
o Session-Termination-Request (Section 3.5)
o Abort-Session-Request (Section 3.7)
1.6. Accounting Model
It is RECOMMENDED that the coupled accounting model (RFC 6733,
Section 9.3) be used with this application; therefore, the value of
the Acct-Application-Id AVP in the Accounting-Request (Section 3.9)
and Accounting-Answer (Section 3.10) messages SHOULD be set to one
2. NAS Calls, Ports, and Sessions
The arrival of a new call or service connection at a port of a
Network Access Server (NAS) starts a Diameter NAS Application message
exchange. Information about the call, the identity of the user, and
the user's authentication information are packaged into a Diameter
AA-Request (AAR) message and sent to a server.
The server processes the information and responds with a Diameter AA-
Answer (AAA) message that contains authorization information for the
NAS or a failure code (Result-Code AVP). A value of
DIAMETER_MULTI_ROUND_AUTH indicates an additional authentication
exchange, and several AAR and AAA messages may be exchanged until the
2.1. Diameter Session Establishment
When the authentication or authorization exchange completes
successfully, the NAS application SHOULD start a session context. If
the Result-Code of DIAMETER_MULTI_ROUND_AUTH is returned, the
exchange continues until a success or error is returned.
If accounting is active, the application MUST also send an Accounting
message [RFC6733]. An Accounting-Record-Type of START_RECORD is sent
for a new session. If a session fails to start, the EVENT_RECORD
message is sent with the reason for the failure described.
Note that the return of an unsupportable Accounting-Realtime-Required
value [RFC6733] would result in a failure to establish the session.
2.2. Diameter Session Reauthentication or Reauthorization
The Diameter Base protocol allows users to be periodically
reauthenticated and/or reauthorized. In such instances, the Session-
Id AVP in the AAR message MUST be the same as the one present in the
original authentication/authorization message.
A Diameter server informs the NAS of the maximum time allowed before
reauthentication or reauthorization via the Authorization-Lifetime
AVP [RFC6733]. A NAS MAY reauthenticate and/or reauthorize before
the end, but a NAS MUST reauthenticate and/or reauthorize at the end
of the period provided by the Authorization-Lifetime AVP. The
failure of a reauthentication exchange will terminate the service.
Furthermore, it is possible for Diameter servers to issue an
unsolicited reauthentication and/or reauthorization request (e.g.,
Re-Auth-Request (RAR) message [RFC6733]) to the NAS. Upon receipt of
such a message, the NAS MUST respond to the request with a Re-Auth-
Answer (RAA) message [RFC6733].
If the RAR properly identifies an active session, the NAS will
initiate a new local reauthentication or authorization sequence as
indicated by the Re-Auth-Request-Type value. This will cause the NAS
to send a new AAR message using the existing Session-Id. The server
will respond with an AAA message to specify the new service
If accounting is active, every change of authentication or
authorization SHOULD generate an accounting message. If the NAS
service is a continuation of the prior user context, then an
Accounting-Record-Type of INTERIM_RECORD indicating the new session
attributes and cumulative status would be appropriate. If a new user
or a significant change in authorization is detected by the NAS, then
the service may send two messages of the types STOP_RECORD and
START_RECORD. Accounting may change the subsession identifiers
(Acct-Session-Id, or Acct-Sub-Session-Id) to indicate such
subsessions. A service may also use a different Session-Id value for
accounting (see Section 9.6 of [RFC6733]).
However, the Diameter Session-Id AVP value used for the initial
authorization exchange MUST be used to generate an STR message when
the session context is terminated.
2.3. Diameter Session Termination
When a NAS receives an indication that a user's session is being
disconnected by the client (e.g., an LCP Terminate-Request message
[RFC1661] is received) or an administrative command, the NAS MUST
issue a Session-Termination-Request (STR) [RFC6733] to its Diameter
server. This will ensure that any resources maintained on the
servers are freed appropriately.
Furthermore, a NAS that receives an Abort-Session-Request (ASR)
[RFC6733] MUST issue an Abort-Session-Answer (ASA) if the session
identified is active and disconnect the PPP (or tunneling) session.
If accounting is active, an Accounting STOP_RECORD message [RFC6733]
MUST be sent upon termination of the session context.
More information on Diameter Session Termination can be found in
Sections 8.4 and 8.5 of [RFC6733].