5. AVP Occurrence Tables
The following tables present the AVPs used by NAS applications in NAS
messages and specify in which Diameter messages they may or may not
be present. Messages and AVPs defined in the Diameter Base protocol
[RFC6733] are not described in this document. Note that AVPs that
can only be present within a grouped AVP are not represented in this
The tables use the following symbols:
0 The AVP MUST NOT be present in the message.
0+ Zero or more instances of the AVP MAY be present in the
| Command |
Attribute Name | ACR | ACA |
NAS-Identifier | 0-1 | 0-1 |
NAS-IP-Address | 0-1 | 0-1 |
NAS-IPv6-Address | 0-1 | 0-1 |
NAS-Port | 0-1 | 0-1 |
NAS-Port-Id | 0-1 | 0-1 |
NAS-Port-Type | 0-1 | 0-1 |
Origin-AAA-Protocol | 0-1 | 0-1 |
Origin-Host | 1 | 1 |
Origin-Realm | 1 | 1 |
Origin-State-Id | 0-1 | 0-1 |
Originating-Line-Info | 0-1 | 0 |
Proxy-Info | 0+ | 0+ |
QoS-Filter-Rule | 0+ | 0 |
Route-Record | 0+ | 0 |
Result-Code | 0 | 1 |
Session-Id | 1 | 1 |
Service-Type | 0-1 | 0-1 |
Termination-Cause | 0-1 | 0-1 |
User-Name | 0-1 | 0-1 |
6. Unicode Considerations
A number of the AVPs in this RFC use the UTF8String type specified in
the Diameter Base protocol [RFC6733]. Implementation differences in
Unicode input processing may result in the same Unicode input
characters generating different UTF-8 strings that fail to match when
compared for equality. This may result in interoperability problems
between a network access server and a Diameter server when a UTF-8
string entered locally is compared with one received via Diameter.
Many of the uses of UTF8String in this RFC are limited to the 7-bit
US-ASCII-compatible subset of UTF-8, where this class of Unicode
string comparison problems does not arise.
Careful preparation of Unicode strings can increase the likelihood
that string comparison will work in ways that make sense for typical
users throughout the world; [RFC3454] is an example a framework for
such Unicode string preparation. The Diameter application specified
in this RFC has been deployed with use of Unicode in accordance with
[RFC4005], which does not require any Unicode string preparation. As
a result, additional requirements for Unicode string preparation in
this RFC would not be backwards compatible with existing usage.
The Diameter server and the network access servers that it serves can
be assumed to be under common administrative control, and all of the
UTF-8 strings involved are part of the configuration of these
servers. Therefore, administrative interfaces for implementations of
a. SHOULD accept direct UTF-8 input of all configuration strings for
AVPs that allow Unicode characters beyond the 7-bit US-ASCII-
compatible subset of Unicode (in addition to any provisions for
accepting Unicode characters for processing into UTF-8), and
b. SHOULD make all such configuration strings available as UTF-8
This functionality enables an administrator who encounters Unicode
string comparison problems to copy one instance of aproblematic UTF-8
string from one server to the other, after which the two (now
identical) copies should compare as expected.
7. IANA Considerations
Several of the namespaces used in this document are managed by the
Internet Assigned Numbers Authority [IANA], including the AVP Codes
[AVP-Codes], AVP Specific Values [AVP-Vals], Application IDs
[App-Ids], Command Codes [Command-Codes], and RADIUS Attribute Values
For the current values allocated, and the policies governing
allocation in those namespaces, please see the above-referenced
8. Security Considerations
This document describes the extension of Diameter for the NAS
application. Security considerations regarding the Diameter protocol
itself are discussed in [RFC6733]. Use of this application of
Diameter MUST take into consideration the security issues and
requirements of the Base protocol.
8.1. Authentication Considerations
This document does not contain a security protocol but does discuss
how PPP authentication protocols can be carried within the Diameter
protocol. The PPP authentication protocols described are PAP and
The use of PAP SHOULD be discouraged, as it exposes users' passwords
to possibly non-trusted entities. However, PAP is also frequently
used for use with one-time passwords, which do not expose a security
This document also describes how CHAP can be carried within the
Diameter protocol, which is required for RADIUS backward
compatibility. The CHAP protocol, as used in a RADIUS environment,
facilitates authentication replay attacks.
The use of the EAP authentication protocols [RFC4072] can offer
better security, given a method suitable for the circumstances.
Depending on the value of the Auth-Request-Type AVP, the Diameter
protocol allows authorization-only requests that contain no
authentication information from the client. This capability goes
beyond the Call Check capabilities provided by RADIUS (Section 5.6 of
[RFC2865]) in that no access decision is requested. As a result, a
new session cannot be started as a result of a response to an
authorization-only request without introducing a significant security
8.2. AVP Considerations
Diameter AVPs often contain security-sensitive data; for example,
user passwords and location data, network addresses and cryptographic
keys. With the exception of the Configuration-Token (Section 4.4.8),
QoS-Filter-Rule (Section 4.4.9), and Tunneling (Section 4.5.1) AVPs,
all of the AVPs defined in this document are considered to be
Diameter messages containing any AVPs considered to be security-
sensitive MUST only be sent protected via mutually authenticated TLS
or IPsec. In addition, those messages MUST NOT be sent via
intermediate nodes unless there is end-to-end security between the
originator and recipient or the originator has locally trusted
configuration that indicates that end-to-end security is not needed.
For example, end-to-end security may not be required in the case
where an intermediary node is known to be operated as part of the
same administrative domain as the endpoints so that an ability to
successfully compromise the intermediary would imply a high
probability of being able to compromise the endpoints as well. Note
that no end-to-end security mechanism is specified in this document.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, December
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes",
RFC 2548, March 1999.
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little,
W., and G. Zorn, "Point-to-Point Tunneling Protocol", RFC
2637, July 1999.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2867] Zorn, G., Aboba, B., and D. Mitton, "RADIUS Accounting
Modifications for Tunnel Protocol Support", RFC 2867, June
[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege,
M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol
Support", RFC 2868, June 2000.
[RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS
Extensions", RFC 2869, June 2000.
[RFC2881] Mitton, D. and M. Beadles, "Network Access Server
Requirements Next Generation (NASREQNG) NAS Model", RFC
2881, July 2000.
[RFC2989] Aboba, B., Calhoun, P., Glass, S., Hiller, T., McCann, P.,
Shiino, H., Walsh, P., Zorn, G., Dommety, G., Perkins, C.,
Patil, B., Mitton, D., Manning, S., Beadles, M., Chen, X.,
Sivalingham, S., Hameed, A., Munson, M., Jacobs, S., Lim,
B., Hirschman, B., Hsu, R., Koo, H., Lipford, M.,
Campbell, E., Xu, Y., Baba, S., and E. Jaques, "Criteria
for Evaluating AAA Protocols for Network Access", RFC
2989, November 2000.
[RFC3169] Beadles, M. and D. Mitton, "Criteria for Evaluating
Network Access Server Protocols", RFC 3169, September
[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec,
J., Courtney, W., Davari, S., Firoiu, V., and D.
Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, March 2002.
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
Internationalized Strings ("stringprep")", RFC 3454,
[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese,
"IEEE 802.1X Remote Authentication Dial In User Service
(RADIUS) Usage Guidelines", RFC 3580, September 2003.
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling
Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
"Diameter Network Access Server Application", RFC 4005,
[RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
Authentication Protocol (EAP) Application", RFC 4072,
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
Appendix A. Acknowledgements
A.1. This Document
The vast majority of the text in this document was taken directly
from RFC 4005; the editor owes a debt of gratitude to the authors
thereof (especially Dave Mitton, who somehow managed to make nroff
paginate the AVP Occurance Tables correctly!).
Thanks (in no particular order) to Jai-Jin Lim, Liu Hans, Sebastien
Decugis, Jouni Korhonen, Mark Jones, Hannes Tschofenig, Dave Crocker,
David Black, Barry Leiba, Peter Saint-Andre, Stefan Winter, and
Lionel Morand for their useful reviews and helpful comments.
A.2. RFC 4005
The authors would like to thank Carl Rigney, Allan C. Rubens, William
Allen Simpson, and Steve Willens for their work on the original
RADIUS protocol, from which many of the concepts in this
specification were derived. Thanks, also, to Carl Rigney for
[RFC2866] and [RFC2869]; Ward Willats for [RFC2869]; Glen Zorn,
Bernard Aboba, and Dave Mitton for [RFC2867] and [RFC3162]; and Dory
Leifer, John Shriver, Matt Holdrege, Allan Rubens, Glen Zorn, and
Ignacio Goyret for their work on [RFC2868]. This document stole text
and concepts from both [RFC2868] and [RFC2869]. Thanks go to Carl
Williams for providing IPv6-specific text.
The authors would also like to acknowledge the following people for
their contributions in the development of the Diameter protocol:
Bernard Aboba, Jari Arkko, William Bulley, Kuntal Chowdhury, Daniel
C. Fox, Lol Grant, Nancy Greene, Jeff Hagg, Peter Heitman, Paul
Krumviede, Fergal Ladley, Ryan Moats, Victor Muslin, Kenneth Peirce,
Sumit Vakil, John R. Vollbrecht, and Jeff Weisberg.
Finally, Pat Calhoun would like to thank Sun Microsystems, as most of
the effort put into this document was done while he was in their