diff options
| author | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
|---|---|---|
| committer | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
| commit | 4bfd864f10b68b71482b35c818559068ef8d5797 (patch) | |
| tree | e3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc7155.txt | |
| parent | ea76e11061bda059ae9f9ad130a9895cc85607db (diff) | |
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc7155.txt')
| -rw-r--r-- | doc/rfc/rfc7155.txt | 3923 |
1 files changed, 3923 insertions, 0 deletions
diff --git a/doc/rfc/rfc7155.txt b/doc/rfc/rfc7155.txt new file mode 100644 index 0000000..49a154f --- /dev/null +++ b/doc/rfc/rfc7155.txt @@ -0,0 +1,3923 @@ + + + + + + +Internet Engineering Task Force (IETF) G. Zorn, Ed. +Request for Comments: 7155 Network Zen +Obsoletes: 4005 April 2014 +Category: Standards Track +ISSN: 2070-1721 + + + Diameter Network Access Server Application + +Abstract + + 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 + http://www.rfc-editor.org/info/rfc7155. + +Copyright Notice + + 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. + + + + + +Zorn Standards Track [Page 1] + +RFC 7155 Diameter NASREQ April 2014 + + +Table of Contents + + 1. Introduction ....................................................4 + 1.1. Changes from RFC 4005 ......................................5 + 1.2. Terminology ................................................6 + 1.3. Requirements Language ......................................7 + 1.4. Advertising Application Support ............................8 + 1.5. Application Identification .................................8 + 1.6. Accounting Model ...........................................8 + 2. NAS Calls, Ports, and Sessions ..................................8 + 2.1. Diameter Session Establishment .............................9 + 2.2. Diameter Session Reauthentication or Reauthorization .......9 + 2.3. Diameter Session Termination ..............................10 + 3. Diameter NAS Application Messages ..............................11 + 3.1. AA-Request (AAR) Command ..................................11 + 3.2. AA-Answer (AAA) Command ...................................13 + 3.3. Re-Auth-Request (RAR) Command .............................15 + 3.4. Re-Auth-Answer (RAA) Command ..............................16 + 3.5. Session-Termination-Request (STR) Command .................17 + 3.6. Session-Termination-Answer (STA) Command ..................17 + 3.7. Abort-Session-Request (ASR) Command .......................18 + 3.8. Abort-Session-Answer (ASA) Command ........................19 + 3.9. Accounting-Request (ACR) Command ..........................20 + 3.10. Accounting-Answer (ACA) Command ..........................22 + 4. Diameter NAS Application AVPs ..................................23 + 4.1. Derived AVP Data Formats ..................................23 + 4.1.1. QoSFilterRule ......................................23 + 4.2. NAS Session AVPs ..........................................24 + 4.2.1. Call and Session Information .......................24 + 4.2.2. NAS-Port AVP .......................................25 + 4.2.3. NAS-Port-Id AVP ....................................25 + 4.2.4. NAS-Port-Type AVP ..................................26 + 4.2.5. Called-Station-Id AVP ..............................26 + 4.2.6. Calling-Station-Id AVP .............................26 + 4.2.7. Connect-Info AVP ...................................27 + 4.2.8. Originating-Line-Info AVP ..........................27 + 4.2.9. Reply-Message AVP ..................................28 + 4.3. NAS Authentication AVPs ...................................28 + 4.3.1. User-Password AVP ..................................29 + 4.3.2. Password-Retry AVP .................................29 + 4.3.3. Prompt AVP .........................................29 + 4.3.4. CHAP-Auth AVP ......................................29 + 4.3.5. CHAP-Algorithm AVP .................................30 + 4.3.6. CHAP-Ident AVP .....................................30 + 4.3.7. CHAP-Response AVP ..................................30 + 4.3.8. CHAP-Challenge AVP .................................30 + 4.3.9. ARAP-Password AVP ..................................30 + 4.3.10. ARAP-Challenge-Response AVP .......................31 + + + +Zorn Standards Track [Page 2] + +RFC 7155 Diameter NASREQ April 2014 + + + 4.3.11. ARAP-Security AVP .................................31 + 4.3.12. ARAP-Security-Data AVP ............................31 + 4.4. NAS Authorization AVPs ....................................31 + 4.4.1. Service-Type AVP ...................................33 + 4.4.2. Callback-Number AVP ................................34 + 4.4.3. Callback-Id AVP ....................................34 + 4.4.4. Idle-Timeout AVP ...................................34 + 4.4.5. Port-Limit AVP .....................................34 + 4.4.6. NAS-Filter-Rule AVP ................................35 + 4.4.7. Filter-Id AVP ......................................35 + 4.4.8. Configuration-Token AVP ............................35 + 4.4.9. QoS-Filter-Rule AVP ................................35 + 4.4.10. Framed Access Authorization AVPs ..................36 + 4.4.10.1. Framed-Protocol AVP ......................36 + 4.4.10.2. Framed-Routing AVP .......................36 + 4.4.10.3. Framed-MTU AVP ...........................37 + 4.4.10.4. Framed-Compression AVP ...................37 + 4.4.10.5. IP Access Authorization AVPs .............37 + 4.4.10.5.1. Framed-IP-Address AVP .........37 + 4.4.10.5.2. Framed-IP-Netmask AVP .........37 + 4.4.10.5.3. Framed-Route AVP ..............38 + 4.4.10.5.4. Framed-Pool AVP ...............38 + 4.4.10.5.5. Framed-Interface-Id AVP .......38 + 4.4.10.5.6. Framed-IPv6-Prefix AVP ........39 + 4.4.10.5.7. Framed-IPv6-Route AVP .........39 + 4.4.10.5.8. Framed-IPv6-Pool AVP ..........39 + 4.4.10.6. IPX Access AVPs ..........................39 + 4.4.10.6.1. Framed-IPX-Network AVP ........40 + 4.4.10.7. AppleTalk Network Access AVPs ............40 + 4.4.10.7.1. Framed-Appletalk-Link AVP .....40 + 4.4.10.7.2. Framed-Appletalk-Network AVP ..40 + 4.4.10.7.3. Framed-Appletalk-Zone AVP .....41 + 4.4.10.8. AppleTalk Remote Access AVPs .............41 + 4.4.10.8.1. ARAP-Features AVP .............41 + 4.4.10.8.2. ARAP-Zone-Access AVP ..........41 + 4.4.11. Non-Framed Access Authorization AVPs ..............41 + 4.4.11.1. Login-IP-Host AVP ........................41 + 4.4.11.2. Login-IPv6-Host AVP ......................42 + 4.4.11.3. Login-Service AVP ........................42 + 4.4.11.4. TCP Services .............................42 + 4.4.11.4.1. Login-TCP-Port AVP ............42 + 4.4.11.5. LAT Services .............................43 + 4.4.11.5.1. Login-LAT-Service AVP .........43 + 4.4.11.5.2. Login-LAT-Node AVP ............43 + 4.4.11.5.3. Login-LAT-Group AVP ...........44 + 4.4.11.5.4. Login-LAT-Port AVP ............44 + 4.5. NAS Tunneling AVPs ........................................45 + 4.5.1. Tunneling AVP ......................................45 + + + +Zorn Standards Track [Page 3] + +RFC 7155 Diameter NASREQ April 2014 + + + 4.5.2. Tunnel-Type AVP ....................................46 + 4.5.3. Tunnel-Medium-Type AVP .............................46 + 4.5.4. Tunnel-Client-Endpoint AVP .........................46 + 4.5.5. Tunnel-Server-Endpoint AVP .........................47 + 4.5.6. Tunnel-Password AVP ................................48 + 4.5.7. Tunnel-Private-Group-Id AVP ........................48 + 4.5.8. Tunnel-Assignment-Id AVP ...........................48 + 4.5.9. Tunnel-Preference AVP ..............................50 + 4.5.10. Tunnel-Client-Auth-Id AVP .........................50 + 4.5.11. Tunnel-Server-Auth-Id AVP .........................50 + 4.6. NAS Accounting AVPs .......................................51 + 4.6.1. Accounting-Input-Octets AVP ........................52 + 4.6.2. Accounting-Output-Octets AVP .......................52 + 4.6.3. Accounting-Input-Packets AVP .......................52 + 4.6.4. Accounting-Output-Packets AVP ......................53 + 4.6.5. Acct-Session-Time AVP ..............................53 + 4.6.6. Acct-Authentic AVP .................................53 + 4.6.7. Accounting-Auth-Method AVP .........................53 + 4.6.8. Acct-Delay-Time AVP ................................53 + 4.6.9. Acct-Link-Count AVP ................................54 + 4.6.10. Acct-Tunnel-Connection AVP ........................55 + 4.6.11. Acct-Tunnel-Packets-Lost AVP ......................55 + 5. AVP Occurrence Tables ..........................................55 + 5.1. AA-Request / AA-Answer AVP Table ..........................56 + 5.2. Accounting AVP Tables .....................................58 + 5.2.1. Framed Access Accounting AVP Table .................59 + 5.2.2. Non-Framed Access Accounting AVP Table .............61 + 6. Unicode Considerations .........................................62 + 7. IANA Considerations ............................................63 + 8. Security Considerations ........................................63 + 8.1. Authentication Considerations .............................63 + 8.2. AVP Considerations ........................................64 + 9. References .....................................................65 + 9.1. Normative References ......................................65 + 9.2. Informative References ....................................65 + Appendix A. Acknowledgements ......................................69 + A.1. This Document ..............................................69 + A.2. RFC 4005 ...................................................69 + +1. Introduction + + This document describes the Diameter protocol application used for + Authentication, Authorization, and Accounting in the Network Access + Server (NAS) environment. When combined with the Diameter Base + protocol [RFC6733], Transport Profile [RFC3539], and Extensible + Authentication Protocol (EAP) [RFC4072] specifications, this + specification satisfies the NAS-related requirements defined in + [RFC2989] and [RFC3169]. + + + +Zorn Standards Track [Page 4] + +RFC 7155 Diameter NASREQ April 2014 + + + 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 + below. + + 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 + downstream. + + 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- + Application-Id inside. + + 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 + Section 1.6). + + + + + + +Zorn Standards Track [Page 5] + +RFC 7155 Diameter NASREQ April 2014 + + + 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 + practical reasons. + +1.2. Terminology + + 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]. + + + + + + +Zorn Standards Track [Page 6] + +RFC 7155 Diameter NASREQ April 2014 + + + 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 + [LAT]. + + 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 + [RFC2637]. + + 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 + [RFC2119]. + + + + + + + + + + +Zorn Standards Track [Page 7] + +RFC 7155 Diameter NASREQ April 2014 + + + 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) + that: + + 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 + (1). + +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 + + + + + +Zorn Standards Track [Page 8] + +RFC 7155 Diameter NASREQ April 2014 + + + DIAMETER_MULTI_ROUND_AUTH indicates an additional authentication + exchange, and several AAR and AAA messages may be exchanged until the + transaction completes. + +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 + parameters. + + + + + + +Zorn Standards Track [Page 9] + +RFC 7155 Diameter NASREQ April 2014 + + + 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]. + + + + + + + + + + + + + + + + + +Zorn Standards Track [Page 10] + +RFC 7155 Diameter NASREQ April 2014 + + +3. Diameter NAS Application Messages + + This section defines the Diameter message Command Code [RFC6733] + values that MUST be supported by all Diameter implementations + conforming to this specification. The Command Codes are as follows: + + +-----------------------------------+---------+------+--------------+ + | Command Name | Abbrev. | Code | Reference | + +-----------------------------------+---------+------+--------------+ + | AA-Request | AAR | 265 | Section 3.1 | + | AA-Answer | AAA | 265 | Section 3.2 | + | Re-Auth-Request | RAR | 258 | Section 3.3 | + | Re-Auth-Answer | RAA | 258 | Section 3.4 | + | Session-Termination-Request | STR | 275 | Section 3.5 | + | Session-Termination-Answer | STA | 275 | Section 3.6 | + | Abort-Session-Request | ASR | 274 | Section 3.7 | + | Abort-Session-Answer | ASA | 274 | Section 3.8 | + | Accounting-Request | ACR | 271 | Section 3.9 | + | Accounting-Answer | ACA | 271 | Section 3.10 | + +-----------------------------------+---------+------+--------------+ + + Note that the message formats in the following subsections use the + standard Diameter Command Code Format ([RFC6733], Section 3.2). + +3.1. AA-Request (AAR) Command + + The AA-Request (AAR), which is indicated by setting the Command Code + field to 265 and the 'R' bit in the Command Flags field, is used to + request authentication and/or authorization for a given NAS user. + The type of request is identified through the Auth-Request-Type AVP + [RFC6733]. The recommended value for most situations is + AUTHORIZE_AUTHENTICATE. + + If Authentication is requested, the User-Name attribute SHOULD be + present, as well as any additional authentication AVPs that would + carry the password information. A request for authorization SHOULD + only include the information from which the authorization will be + performed, such as the User-Name, Called-Station-Id, or Calling- + Station-Id AVPs. All requests SHOULD contain AVPs uniquely + identifying the source of the call, such as Origin-Host and NAS-Port. + Certain networks MAY use different AVPs for authorization purposes. + A request for authorization will include some AVPs defined in + Section 4.4. + + It is possible for a single session to be authorized first and then + for an authentication request to follow. + + + + + +Zorn Standards Track [Page 11] + +RFC 7155 Diameter NASREQ April 2014 + + + This AA-Request message MAY be the result of a multi-round + authentication exchange, which occurs when the AA-Answer message is + received with the Result-Code AVP set to DIAMETER_MULTI_ROUND_AUTH. + A subsequent AAR message SHOULD be sent, with the User-Password AVP + that includes the user's response to the prompt and MUST include any + State AVPs that were present in the AAA message. + + Message Format + + <AA-Request> ::= < Diameter Header: 265, REQ, PXY > + < Session-Id > + { Auth-Application-Id } + { Origin-Host } + { Origin-Realm } + { Destination-Realm } + { Auth-Request-Type } + [ Destination-Host ] + [ NAS-Identifier ] + [ NAS-IP-Address ] + [ NAS-IPv6-Address ] + [ NAS-Port ] + [ NAS-Port-Id ] + [ NAS-Port-Type ] + [ Origin-AAA-Protocol ] + [ Origin-State-Id ] + [ Port-Limit ] + [ User-Name ] + [ User-Password ] + [ Service-Type ] + [ State ] + [ Authorization-Lifetime ] + [ Auth-Grace-Period ] + [ Auth-Session-State ] + [ Callback-Number ] + [ Called-Station-Id ] + [ Calling-Station-Id ] + [ Originating-Line-Info ] + [ Connect-Info ] + [ CHAP-Auth ] + [ CHAP-Challenge ] + * [ Framed-Compression ] + [ Framed-Interface-Id ] + [ Framed-IP-Address ] + * [ Framed-IPv6-Prefix ] + [ Framed-IP-Netmask ] + [ Framed-MTU ] + [ Framed-Protocol ] + [ ARAP-Password ] + + + +Zorn Standards Track [Page 12] + +RFC 7155 Diameter NASREQ April 2014 + + + [ ARAP-Security ] + * [ ARAP-Security-Data ] + * [ Login-IP-Host ] + * [ Login-IPv6-Host ] + [ Login-LAT-Group ] + [ Login-LAT-Node ] + [ Login-LAT-Port ] + [ Login-LAT-Service ] + * [ Tunneling ] + * [ Proxy-Info ] + * [ Route-Record ] + * [ AVP ] + +3.2. AA-Answer (AAA) Command + + The AA-Answer (AAA) message is indicated by setting the Command Code + field to 265 and clearing the 'R' bit in the Command Flags field. It + is sent in response to the AA-Request (AAR) message. If + authorization was requested, a successful response will include the + authorization AVPs appropriate for the service being provided, as + defined in Section 4.4. + + For authentication exchanges requiring more than a single round trip, + the server MUST set the Result-Code AVP to DIAMETER_MULTI_ROUND_AUTH. + + An AAA message with this result code MAY include one Reply-Message or + more and MAY include zero or one State AVPs. + + If the Reply-Message AVP was present, the network access server + SHOULD send the text to the user's client to display to the user, + instructing the client to prompt the user for a response. For + example, this can be achieved in PPP via PAP. If it is impossible to + deliver the text prompt to the user, the Diameter NAS Application + client MUST treat the AA-Answer (AAA) with the Reply-Message AVP as + an error and deny access. + + Message Format + + <AA-Answer> ::= < Diameter Header: 265, PXY > + < Session-Id > + { Auth-Application-Id } + { Auth-Request-Type } + { Result-Code } + { Origin-Host } + { Origin-Realm } + [ User-Name ] + [ Service-Type ] + * [ Class ] + + + +Zorn Standards Track [Page 13] + +RFC 7155 Diameter NASREQ April 2014 + + + * [ Configuration-Token ] + [ Acct-Interim-Interval ] + [ Error-Message ] + [ Error-Reporting-Host ] + * [ Failed-AVP ] + [ Idle-Timeout ] + [ Authorization-Lifetime ] + [ Auth-Grace-Period ] + [ Auth-Session-State ] + [ Re-Auth-Request-Type ] + [ Multi-Round-Time-Out ] + [ Session-Timeout ] + [ State ] + * [ Reply-Message ] + [ Origin-AAA-Protocol ] + [ Origin-State-Id ] + * [ Filter-Id ] + [ Password-Retry ] + [ Port-Limit ] + [ Prompt ] + [ ARAP-Challenge-Response ] + [ ARAP-Features ] + [ ARAP-Security ] + * [ ARAP-Security-Data ] + [ ARAP-Zone-Access ] + [ Callback-Id ] + [ Callback-Number ] + [ Framed-Appletalk-Link ] + * [ Framed-Appletalk-Network ] + [ Framed-Appletalk-Zone ] + * [ Framed-Compression ] + [ Framed-Interface-Id ] + [ Framed-IP-Address ] + * [ Framed-IPv6-Prefix ] + [ Framed-IPv6-Pool ] + * [ Framed-IPv6-Route ] + [ Framed-IP-Netmask ] + * [ Framed-Route ] + [ Framed-Pool ] + [ Framed-IPX-Network ] + [ Framed-MTU ] + [ Framed-Protocol ] + [ Framed-Routing ] + * [ Login-IP-Host ] + * [ Login-IPv6-Host ] + [ Login-LAT-Group ] + [ Login-LAT-Node ] + [ Login-LAT-Port ] + + + +Zorn Standards Track [Page 14] + +RFC 7155 Diameter NASREQ April 2014 + + + [ Login-LAT-Service ] + [ Login-Service ] + [ Login-TCP-Port ] + * [ NAS-Filter-Rule ] + * [ QoS-Filter-Rule ] + * [ Tunneling ] + * [ Redirect-Host ] + [ Redirect-Host-Usage ] + [ Redirect-Max-Cache-Time ] + * [ Proxy-Info ] + * [ AVP ] + +3.3. Re-Auth-Request (RAR) Command + + A Diameter server can initiate reauthentication and/or + reauthorization for a particular session by issuing a Re-Auth-Request + (RAR) message [RFC6733]. + + For example, for prepaid services, the Diameter server that + originally authorized a session may need some confirmation that the + user is still using the services. + + If a NAS receives an RAR message with Session-Id equal to a currently + active session and a Re-Auth-Type that includes authentication, it + MUST initiate a reauthentication toward the user, if the service + supports this particular feature. + + Message Format + + <RA-Request> ::= < Diameter Header: 258, REQ, PXY > + < Session-Id > + { Origin-Host } + { Origin-Realm } + { Destination-Realm } + { Destination-Host } + { Auth-Application-Id } + { Re-Auth-Request-Type } + [ User-Name ] + [ Origin-AAA-Protocol ] + [ Origin-State-Id ] + [ NAS-Identifier ] + [ NAS-IP-Address ] + [ NAS-IPv6-Address ] + [ NAS-Port ] + [ NAS-Port-Id ] + [ NAS-Port-Type ] + [ Service-Type ] + [ Framed-IP-Address ] + + + +Zorn Standards Track [Page 15] + +RFC 7155 Diameter NASREQ April 2014 + + + [ Framed-IPv6-Prefix ] + [ Framed-Interface-Id ] + [ Called-Station-Id ] + [ Calling-Station-Id ] + [ Originating-Line-Info ] + [ Acct-Session-Id ] + [ Acct-Multi-Session-Id ] + [ State ] + * [ Class ] + [ Reply-Message ] + * [ Proxy-Info ] + * [ Route-Record ] + * [ AVP ] + +3.4. Re-Auth-Answer (RAA) Command + + The Re-Auth-Answer (RAA) message [RFC6733] is sent in response to the + RAR. The Result-Code AVP MUST be present and indicates the + disposition of the request. + + A successful RAA transaction MUST be followed by an AAR message. + + Message Format + + <RA-Answer> ::= < Diameter Header: 258, PXY > + < Session-Id > + { Result-Code } + { Origin-Host } + { Origin-Realm } + [ User-Name ] + [ Origin-AAA-Protocol ] + [ Origin-State-Id ] + [ Error-Message ] + [ Error-Reporting-Host ] + * [ Failed-AVP ] + * [ Redirected-Host ] + [ Redirected-Host-Usage ] + [ Redirected-Host-Cache-Time ] + [ Service-Type ] + * [ Configuration-Token ] + [ Idle-Timeout ] + [ Authorization-Lifetime ] + [ Auth-Grace-Period ] + [ Re-Auth-Request-Type ] + [ State ] + * [ Class ] + * [ Reply-Message ] + [ Prompt ] + + + +Zorn Standards Track [Page 16] + +RFC 7155 Diameter NASREQ April 2014 + + + * [ Proxy-Info ] + * [ AVP ] + +3.5. Session-Termination-Request (STR) Command + + The Session-Termination-Request (STR) message [RFC6733] is sent by + the NAS to inform the Diameter server that an authenticated and/or + authorized session is being terminated. + + Message Format + + <ST-Request> ::= < Diameter Header: 275, REQ, PXY > + < Session-Id > + { Origin-Host } + { Origin-Realm } + { Destination-Realm } + { Auth-Application-Id } + { Termination-Cause } + [ User-Name ] + [ Destination-Host ] + * [ Class ] + [ Origin-AAA-Protocol ] + [ Origin-State-Id ] + * [ Proxy-Info ] + * [ Route-Record ] + * [ AVP ] + +3.6. Session-Termination-Answer (STA) Command + + The Session-Termination-Answer (STA) message [RFC6733] is sent by the + Diameter server to acknowledge the notification that the session has + been terminated. The Result-Code AVP MUST be present and MAY contain + an indication that an error occurred while the STR was being + serviced. + + Upon sending the STA, the Diameter server MUST release all resources + for the session indicated by the Session-Id AVP. Any intermediate + server in the Proxy-Chain MAY also release any resources, if + necessary. + + + + + + + + + + + + +Zorn Standards Track [Page 17] + +RFC 7155 Diameter NASREQ April 2014 + + + Message Format + + <ST-Answer> ::= < Diameter Header: 275, PXY > + < Session-Id > + { Result-Code } + { Origin-Host } + { Origin-Realm } + [ User-Name ] + * [ Class ] + [ Error-Message ] + [ Error-Reporting-Host ] + * [ Failed-AVP ] + [ Origin-AAA-Protocol ] + [ Origin-State-Id ] + * [ Redirect-Host ] + [ Redirect-Host-Usage ] + [ Redirect-Max-Cache-Time ] + * [ Proxy-Info ] + * [ AVP ] + +3.7. Abort-Session-Request (ASR) Command + + The Abort-Session-Request (ASR) message [RFC6733] can be sent by any + Diameter server to the NAS providing session service to request that + the session identified by the Session-Id be stopped. + + Message Format + + <AS-Request> ::= < Diameter Header: 274, REQ, PXY > + < Session-Id > + { Origin-Host } + { Origin-Realm } + { Destination-Realm } + { Destination-Host } + { Auth-Application-Id } + [ User-Name ] + [ Origin-AAA-Protocol ] + [ Origin-State-Id ] + [ NAS-Identifier ] + [ NAS-IP-Address ] + [ NAS-IPv6-Address ] + [ NAS-Port ] + [ NAS-Port-Id ] + [ NAS-Port-Type ] + [ Service-Type ] + [ Framed-IP-Address ] + [ Framed-IPv6-Prefix ] + [ Framed-Interface-Id ] + + + +Zorn Standards Track [Page 18] + +RFC 7155 Diameter NASREQ April 2014 + + + [ Called-Station-Id ] + [ Calling-Station-Id ] + [ Originating-Line-Info ] + [ Acct-Session-Id ] + [ Acct-Multi-Session-Id ] + [ State ] + * [ Class ] + * [ Reply-Message ] + * [ Proxy-Info ] + * [ Route-Record ] + * [ AVP ] + +3.8. Abort-Session-Answer (ASA) Command + + The ASA message [RFC6733] is sent in response to the ASR. The + Result-Code AVP MUST be present and indicates the disposition of the + request. + + If the session identified by Session-Id in the ASR was successfully + terminated, the Result-Code is set to DIAMETER_SUCCESS. If the + session is not currently active, the Result-Code AVP is set to + DIAMETER_UNKNOWN_SESSION_ID. If the access device does not stop the + session for any other reason, the Result-Code AVP is set to + DIAMETER_UNABLE_TO_COMPLY. + + Message Format + + <AS-Answer> ::= < Diameter Header: 274, PXY > + < Session-Id > + { Result-Code } + { Origin-Host } + { Origin-Realm } + [ User-Name ] + [ Origin-AAA-Protocol ] + [ Origin-State-Id ] + [ State] + [ Error-Message ] + [ Error-Reporting-Host ] + * [ Failed-AVP ] + * [ Redirected-Host ] + [ Redirected-Host-Usage ] + [ Redirected-Max-Cache-Time ] + * [ Proxy-Info ] + * [ AVP ] + + + + + + + +Zorn Standards Track [Page 19] + +RFC 7155 Diameter NASREQ April 2014 + + +3.9. Accounting-Request (ACR) Command + + The ACR message [RFC6733] is sent by the NAS to report its session + information to a target server downstream. + + The Acct-Application-Id AVP MUST be present. + + The AVPs listed in the Diameter Base protocol specification [RFC6733] + MUST be assumed to be present, as appropriate. NAS service-specific + accounting AVPs SHOULD be present as described in Section 4.6 and the + rest of this specification. + + Message Format + + <AC-Request> ::= < Diameter Header: 271, REQ, PXY > + < Session-Id > + { Origin-Host } + { Origin-Realm } + { Destination-Realm } + { Accounting-Record-Type } + { Accounting-Record-Number } + { Acct-Application-Id } + [ User-Name ] + [ Accounting-Sub-Session-Id ] + [ Acct-Session-Id ] + [ Acct-Multi-Session-Id ] + [ Origin-AAA-Protocol ] + [ Origin-State-Id ] + [ Destination-Host ] + [ Event-Timestamp ] + [ Acct-Delay-Time ] + [ NAS-Identifier ] + [ NAS-IP-Address ] + [ NAS-IPv6-Address ] + [ NAS-Port ] + [ NAS-Port-Id ] + [ NAS-Port-Type ] + * [ Class ] + [ Service-Type ] + [ Termination-Cause ] + [ Accounting-Input-Octets ] + [ Accounting-Input-Packets ] + [ Accounting-Output-Octets ] + [ Accounting-Output-Packets ] + [ Acct-Authentic ] + [ Accounting-Auth-Method ] + [ Acct-Link-Count ] + [ Acct-Session-Time ] + + + +Zorn Standards Track [Page 20] + +RFC 7155 Diameter NASREQ April 2014 + + + [ Acct-Tunnel-Connection ] + [ Acct-Tunnel-Packets-Lost ] + [ Callback-Id ] + [ Callback-Number ] + [ Called-Station-Id ] + [ Calling-Station-Id ] + * [ Connection-Info ] + [ Originating-Line-Info ] + [ Authorization-Lifetime ] + [ Session-Timeout ] + [ Idle-Timeout ] + [ Port-Limit ] + [ Accounting-Realtime-Required ] + [ Acct-Interim-Interval ] + * [ Filter-Id ] + * [ NAS-Filter-Rule ] + * [ QoS-Filter-Rule ] + [ Framed-Appletalk-Link ] + [ Framed-Appletalk-Network ] + [ Framed-Appletalk-Zone ] + [ Framed-Compression ] + [ Framed-Interface-Id ] + [ Framed-IP-Address ] + [ Framed-IP-Netmask ] + * [ Framed-IPv6-Prefix ] + [ Framed-IPv6-Pool ] + * [ Framed-IPv6-Route ] + [ Framed-IPX-Network ] + [ Framed-MTU ] + [ Framed-Pool ] + [ Framed-Protocol ] + * [ Framed-Route ] + [ Framed-Routing ] + * [ Login-IP-Host ] + * [ Login-IPv6-Host ] + [ Login-LAT-Group ] + [ Login-LAT-Node ] + [ Login-LAT-Port ] + [ Login-LAT-Service ] + [ Login-Service ] + [ Login-TCP-Port ] + * [ Tunneling ] + * [ Proxy-Info ] + * [ Route-Record ] + * [ AVP ] + + + + + + +Zorn Standards Track [Page 21] + +RFC 7155 Diameter NASREQ April 2014 + + +3.10. Accounting-Answer (ACA) Command + + The ACA message [RFC6733] is used to acknowledge an Accounting- + Request command. The Accounting-Answer command contains the same + Session-Id as the Request. + + Only the target Diameter server or home Diameter server SHOULD + respond with the Accounting-Answer command. + + The Acct-Application-Id AVP MUST be present. + + The AVPs listed in the Diameter Base protocol specification [RFC6733] + MUST be assumed to be present, as appropriate. NAS service-specific + accounting AVPs SHOULD be present as described in Section 4.6 and the + rest of this specification. + + Message Format + + <AC-Answer> ::= < Diameter Header: 271, PXY > + < Session-Id > + { Result-Code } + { Origin-Host } + { Origin-Realm } + { Accounting-Record-Type } + { Accounting-Record-Number } + { Acct-Application-Id } + [ User-Name ] + [ Accounting-Sub-Session-Id ] + [ Acct-Session-Id ] + [ Acct-Multi-Session-Id ] + [ Event-Timestamp ] + [ Error-Message ] + [ Error-Reporting-Host ] + * [ Failed-AVP ] + [ Origin-AAA-Protocol ] + [ Origin-State-Id ] + [ NAS-Identifier ] + [ NAS-IP-Address ] + [ NAS-IPv6-Address ] + [ NAS-Port ] + [ NAS-Port-Id ] + [ NAS-Port-Type ] + [ Service-Type ] + [ Termination-Cause ] + [ Accounting-Realtime-Required ] + + + + + + +Zorn Standards Track [Page 22] + +RFC 7155 Diameter NASREQ April 2014 + + + [ Acct-Interim-Interval ] + * [ Class ] + * [ Proxy-Info ] + * [ AVP ] + +4. Diameter NAS Application AVPs + + The following sections define a new derived AVP data format, define a + set of application-specific AVPs, and describe the use of AVPs + defined in other documents by the Diameter NAS Application. + +4.1. Derived AVP Data Formats + +4.1.1. QoSFilterRule + + The QosFilterRule format is derived from the OctetString AVP Base + Format. It uses the US-ASCII charset. Packets may be marked or + metered based on the following information: + + o Direction (in or out) + + o Source and destination IP address (possibly masked) + + o Protocol + + o Source and destination port (lists or ranges) + + o Differentiated Services Code Point (DSCP) values (no mask or + range) + + Rules for the appropriate direction are evaluated in order; the first + matched rule terminates the evaluation. Each packet is evaluated + once. If no rule matches, the packet is treated as best effort. An + access device unable to interpret or apply a QoS rule SHOULD NOT + terminate the session. + + + + + + + + + + + + + + + + +Zorn Standards Track [Page 23] + +RFC 7155 Diameter NASREQ April 2014 + + + QoSFilterRule filters MUST follow the following format: + + action dir proto from src to dst [options] + + where + + action + + tag Mark packet with a specific DSCP [RFC2474] + + meter Meter traffic + + + dir The format is as described under IPFilterRule + [RFC6733] + + + proto The format is as described under IPFilterRule + [RFC6733] + + + src and dst The format is as described under IPFilterRule + [RFC6733] + + + The options are described in Section 4.4.9. + + The rule syntax is a modified subset of ipfw(8) from FreeBSD, and the + ipfw.c code may provide a useful base for implementations. + +4.2. NAS Session AVPs + + Diameter reserves the AVP Codes 0 - 255 for RADIUS Attributes that + are implemented in Diameter. + +4.2.1. Call and Session Information + + This section describes the AVPs specific to Diameter applications + that are needed to identify the call and session context and status + information. On a request, this information allows the server to + qualify the session. + + These AVPs are used in addition to the following AVPs from the + Diameter Base protocol specification [RFC6733]: + + Session-Id Auth-Application-Id Origin-Host Origin-Realm + Auth-Request-Type Termination-Cause + + + + +Zorn Standards Track [Page 24] + +RFC 7155 Diameter NASREQ April 2014 + + + The following table gives the possible flag values for the session + level AVPs. + + +-----------+ + | AVP Flag | + | Rules | + |-----+-----+ + |MUST | MUST| + Attribute Name Section Defined | | NOT| + -----------------------------------------|-----+-----| + NAS-Port 4.2.2 | M | V | + NAS-Port-Id 4.2.3 | M | V | + NAS-Port-Type 4.2.4 | M | V | + Called-Station-Id 4.2.5 | M | V | + Calling-Station-Id 4.2.6 | M | V | + Connect-Info 4.2.7 | M | V | + Originating-Line-Info 4.2.8 | M | V | + Reply-Message 4.2.9 | M | V | + -----------------------------------------|-----+-----| + +4.2.2. NAS-Port AVP + + The NAS-Port AVP (AVP Code 5) is of type Unsigned32 and contains the + physical or virtual port number of the NAS, which authenticates the + user. Note that "port" is meant in its sense as a service connection + on the NAS, not as an IP protocol identifier; hence, the format and + contents of the string that identifies the port are specific to the + NAS implementation. + + Either the NAS-Port AVP or the NAS-Port-Id AVP (Section 4.2.3) SHOULD + be present in the AA-Request (AAR, Section 3.1) command if the NAS + differentiates among its ports. + +4.2.3. NAS-Port-Id AVP + + The NAS-Port-Id AVP (AVP Code 87) is of type UTF8String and consists + of 7-bit US-ASCII text identifying the port of the NAS authenticating + the user. Note that "port" is meant in its sense as a service + connection on the NAS, not as an IP protocol identifier. + + Either the NAS-Port-Id AVP or the NAS-Port AVP (Section 4.2.2) SHOULD + be present in the AA-Request (AAR, Section 3.1) command if the NAS + differentiates among its ports. NAS-Port-Id is intended for use by + NASes that cannot conveniently number their ports. + + + + + + + +Zorn Standards Track [Page 25] + +RFC 7155 Diameter NASREQ April 2014 + + +4.2.4. NAS-Port-Type AVP + + The NAS-Port-Type AVP (AVP Code 61) is of type Enumerated and + contains the type of the port on which the NAS is authenticating the + user. This AVP SHOULD be present if the NAS uses the same NAS-Port + number ranges for different service types concurrently. + + The currently supported values of the NAS-Port-Type AVP are listed in + [RADIUSAttrVals]. + +4.2.5. Called-Station-Id AVP + + The Called-Station-Id AVP (AVP Code 30) is of type UTF8String and + contains a 7-bit US-ASCII string sent by the NAS to describe the + Layer 2 address the user contacted in the request. For dialup + access, this can be a phone number obtained by using the Dialed + Number Identification Service (DNIS) or a similar technology. Note + that this may be different from the phone number the call comes in + on. For use with IEEE 802 access, the Called-Station-Id MAY contain + a Media Access Control (MAC) address formatted as described in + [RFC3580]. + + If the Called-Station-Id AVP is present in an AAR message, the Auth- + Request-Type AVP is set to AUTHORIZE_ONLY, and the User-Name AVP is + absent, the Diameter server MAY perform authorization based on this + AVP. This can be used by a NAS to request whether a call should be + answered based on the DNIS result. + + Further codification of this field's allowed content and usage is + outside the scope of this specification. + +4.2.6. Calling-Station-Id AVP + + The Calling-Station-Id AVP (AVP Code 31) is of type UTF8String and + contains a 7-bit US-ASCII string sent by the NAS to describe the + Layer 2 address from which the user connected in the request. For + dialup access, this is the phone number the call came from, using + Automatic Number Identification (ANI) or a similar technology. For + use with IEEE 802 access, the Calling-Station-Id AVP MAY contain a + MAC address, formatted as described in RFC 3580. + + If the Calling-Station-Id AVP is present in an AAR message, the Auth- + Request-Type AVP is set to AUTHORIZE_ONLY, and the User-Name AVP is + absent, the Diameter server MAY perform authorization based on the + value of this AVP. This can be used by a NAS to request whether a + call should be answered based on the Layer 2 address (ANI, MAC + Address, etc.) + + + + +Zorn Standards Track [Page 26] + +RFC 7155 Diameter NASREQ April 2014 + + + Further codification of this field's allowed content and usage is + outside the scope of this specification. + +4.2.7. Connect-Info AVP + + The Connect-Info AVP (AVP Code 77) is of type UTF8String and is sent + in the AA-Request message or an ACR message with the value of the + Accounting-Record-Type AVP set to STOP. When sent in the AA-Request, + it indicates the nature of the user's connection. The connection + speed SHOULD be included at the beginning of the first Connect-Info + AVP in the message. If the transmit and receive connection speeds + differ, both may be included in the first AVP with the transmit speed + listed first (the speed at which the NAS modem transmits), then a + slash (/), then the receive speed, and then other optional + information. + + For example: "28800 V42BIS/LAPM" or "52000/31200 V90" + + If sent in an ACR message with the value of the Accounting-Record- + Type AVP set to STOP, this attribute may summarize statistics + relating to session quality. For example, in IEEE 802.11, the + Connect-Info AVP may contain information on the number of link layer + retransmissions. The exact format of this attribute is + implementation specific. + +4.2.8. Originating-Line-Info AVP + + The Originating-Line-Info AVP (AVP Code 94) is of type OctetString + and is sent by the NAS system to convey information about the origin + of the call from a Signaling System 7 (SS7). + + The Originating Line Information (OLI) element indicates the nature + and/or characteristics of the line from which a call originated + (e.g., pay phone, hotel phone, cellular phone). Telephone companies + are starting to offer OLI to their customers as an option over + Primary Rate Interface (PRI). Internet Service Providers (ISPs) can + use OLI in addition to Called-Station-Id and Calling-Station-Id + attributes to differentiate customer calls and to define different + services. + + The Value field contains two octets (00 - 99). ANSI T1.113 and + BELLCORE 394 can be used for additional information about these + values and their use. For information on the currently assigned + values, see [ANITypes]. + + + + + + + +Zorn Standards Track [Page 27] + +RFC 7155 Diameter NASREQ April 2014 + + +4.2.9. Reply-Message AVP + + The Reply-Message AVP (AVP Code 18) is of type UTF8String and + contains text that MAY be displayed to the user. When used in an AA- + Answer message with a successful Result-Code AVP, it indicates + success. When found in an AAA message with a Result-Code other than + DIAMETER_SUCCESS, the AVP contains a failure message. + + The Reply-Message AVP MAY contain text to prompt the user before + another AA-Request attempt. When used in an AA-Answer message + containing a Result-Code AVP with the value DIAMETER_MULTI_ROUND_AUTH + or in a Re-Auth-Request message, it MAY contain text to prompt the + user for a response. + +4.3. NAS Authentication AVPs + + This section defines the AVPs necessary to carry the authentication + information in the Diameter protocol. The functionality defined here + provides a RADIUS-like Authentication, Authorization, and Accounting + service [RFC2865] over a more reliable and secure transport, as + defined in the Diameter Base protocol [RFC6733]. + + The following table gives the possible flag values for the session + level AVPs. + + +----------+ + | AVP Flag | + | Rules | + |----+-----| + |MUST| MUST| + Attribute Name Section Defined | | NOT| + -----------------------------------------|----+-----| + User-Password 4.3.1 | M | V | + Password-Retry 4.3.2 | M | V | + Prompt 4.3.3 | M | V | + CHAP-Auth 4.3.4 | M | V | + CHAP-Algorithm 4.3.5 | M | V | + CHAP-Ident 4.3.6 | M | V | + CHAP-Response 4.3.7 | M | V | + CHAP-Challenge 4.3.8 | M | V | + ARAP-Password 4.3.9 | M | V | + ARAP-Challenge-Response 4.3.10 | M | V | + ARAP-Security 4.3.11 | M | V | + ARAP-Security-Data 4.3.12 | M | V | + -----------------------------------------|----+-----| + + + + + + +Zorn Standards Track [Page 28] + +RFC 7155 Diameter NASREQ April 2014 + + +4.3.1. User-Password AVP + + The User-Password AVP (AVP Code 2) is of type OctetString and + contains the password of the user to be authenticated or the user's + input in a multi-round authentication exchange. + + The User-Password AVP contains a user password or one-time password + and therefore represents sensitive information. As required by the + Diameter Base protocol [RFC6733], Diameter messages are encrypted by + using IPsec [RFC4301] or Transport Layer Security (TLS) [RFC5246]. + Unless this AVP is used for one-time passwords, the User-Password AVP + SHOULD NOT be used in untrusted proxy environments without encrypting + it by using end-to-end security techniques. + + The clear-text password (prior to encryption) MUST NOT be longer than + 128 bytes in length. + +4.3.2. Password-Retry AVP + + The Password-Retry AVP (AVP Code 75) is of type Unsigned32 and MAY be + included in the AA-Answer if the Result-Code indicates an + authentication failure. The value of this AVP indicates how many + authentication attempts a user is permitted before being + disconnected. This AVP is primarily intended for use when the + Framed-Protocol AVP (Section 4.4.10.1) is set to ARAP. + +4.3.3. Prompt AVP + + The Prompt AVP (AVP Code 76) is of type Enumerated and MAY be present + in the AA-Answer message. When present, it is used by the NAS to + determine whether the user's response, when entered, should be + echoed. + + The supported values are listed in [RADIUSAttrVals]. + +4.3.4. CHAP-Auth AVP + + The CHAP-Auth AVP (AVP Code 402) is of type Grouped and contains the + information necessary to authenticate a user using the PPP Challenge- + Handshake Authentication Protocol (CHAP) [RFC1994]. If the CHAP-Auth + AVP is found in a message, the CHAP-Challenge AVP (Section 4.3.8) + MUST be present as well. The optional AVPs containing the CHAP + response depend upon the value of the CHAP-Algorithm AVP + (Section 4.3.8). The grouped AVP has the following ABNF [RFC5234] + grammar: + + + + + + +Zorn Standards Track [Page 29] + +RFC 7155 Diameter NASREQ April 2014 + + + CHAP-Auth ::= < AVP Header: 402 > + { CHAP-Algorithm } + { CHAP-Ident } + [ CHAP-Response ] + * [ AVP ] + +4.3.5. CHAP-Algorithm AVP + + The CHAP-Algorithm AVP (AVP Code 403) is of type Enumerated and + contains the algorithm identifier used in the computation of the CHAP + response [RFC1994]. The following values are currently supported: + + CHAP with MD5 5 + + The CHAP response is computed by using the procedure described in + [RFC1994]. This algorithm requires that the CHAP-Response AVP + (Section 4.3.7) MUST be present in the CHAP-Auth AVP + (Section 4.3.4). + +4.3.6. CHAP-Ident AVP + + The CHAP-Ident AVP (AVP Code 404) is of type OctetString and contains + the 1 octet CHAP Identifier used in the computation of the CHAP + response [RFC1994]. + +4.3.7. CHAP-Response AVP + + The CHAP-Response AVP (AVP Code 405) is of type OctetString and + contains the 16-octet authentication data provided by the user in + response to the CHAP challenge [RFC1994]. + +4.3.8. CHAP-Challenge AVP + + The CHAP-Challenge AVP (AVP Code 60) is of type OctetString and + contains the CHAP Challenge sent by the NAS to the CHAP peer + [RFC1994]. + +4.3.9. ARAP-Password AVP + + The ARAP-Password AVP (AVP Code 70) is of type OctetString and is + only present when the Framed-Protocol AVP (Section 4.4.10.1) is + included in the message and is set to ARAP. This AVP MUST NOT be + present if either the User-Password or the CHAP-Auth AVP is present. + See [RFC2869] for more information on the contents of this AVP. + + + + + + + +Zorn Standards Track [Page 30] + +RFC 7155 Diameter NASREQ April 2014 + + +4.3.10. ARAP-Challenge-Response AVP + + The ARAP-Challenge-Response AVP (AVP Code 84) is of type OctetString + and is only present when the Framed-Protocol AVP (Section 4.4.10.1) + is included in the message and is set to ARAP. This AVP contains an + 8-octet response to the dial-in client's challenge. The Diameter + server calculates this value by taking the dial-in client's challenge + from the high-order 8 octets of the ARAP-Password AVP and performing + DES encryption on this value with the authenticating user's password + as the key. If the user's password is fewer than 8 octets in length, + the password is padded at the end with NULL octets to a length of 8 + before it is used as a key. + +4.3.11. ARAP-Security AVP + + The ARAP-Security AVP (AVP Code 73) is of type Unsigned32 and MAY be + present in the AA-Answer message if the Framed-Protocol AVP + (Section 4.4.10.1) is set to the value of ARAP, and the Result-Code + AVP ([RFC6733], Section 7.1) is set to DIAMETER_MULTI_ROUND_AUTH. + See RFC 2869 for more information on the contents of this AVP. + +4.3.12. ARAP-Security-Data AVP + + The ARAP-Security-Data AVP (AVP Code 74) is of type OctetString and + MAY be present in the AA-Request or AA-Answer message if the Framed- + Protocol AVP (Section 4.4.10.1) is set to the value of ARAP and the + Result-Code AVP ([RFC6733], Section 7.1) is set to + DIAMETER_MULTI_ROUND_AUTH. This AVP contains the security module + challenge or response associated with the ARAP Security Module + specified in the ARAP-Security AVP (Section 4.3.11). + +4.4. NAS Authorization AVPs + + This section contains the authorization AVPs supported in the NAS + Application. The Service-Type AVP SHOULD be present in all messages + and, based on its value, additional AVPs defined in this section and + Section 4.5 MAY be present. + + The following table gives the possible flag values for the session- + level AVPs. + + + + + + + + + + + +Zorn Standards Track [Page 31] + +RFC 7155 Diameter NASREQ April 2014 + + + +----------+ + | AVP Flag | + | Rules | + |----+-----| + |MUST| MUST| + Attribute Name Section Defined | | NOT| + -----------------------------------------|----+-----| + Service-Type 4.4.1 | M | V | + Callback-Number 4.4.2 | M | V | + Callback-Id 4.4.3 | M | V | + Idle-Timeout 4.4.4 | M | V | + Port-Limit 4.4.5 | M | V | + NAS-Filter-Rule 4.4.6 | M | V | + Filter-Id 4.4.7 | M | V | + Configuration-Token 4.4.8 | M | V | + QoS-Filter-Rule 4.4.9 | | | + Framed-Protocol 4.4.10.1 | M | V | + Framed-Routing 4.4.10.2 | M | V | + Framed-MTU 4.4.10.3 | M | V | + Framed-Compression 4.4.10.4 | M | V | + Framed-IP-Address 4.4.10.5.1 | M | V | + Framed-IP-Netmask 4.4.10.5.2 | M | V | + Framed-Route 4.4.10.5.3 | M | V | + Framed-Pool 4.4.10.5.4 | M | V | + Framed-Interface-Id 4.4.10.5.5 | M | V | + Framed-IPv6-Prefix 4.4.10.5.6 | M | V | + Framed-IPv6-Route 4.4.10.5.7 | M | V | + Framed-IPv6-Pool 4.4.10.5.8 | M | V | + Framed-IPX-Network 4.4.10.6.1 | M | V | + Framed-Appletalk-Link 4.4.10.7.1 | M | V | + Framed-Appletalk-Network 4.4.10.7.2 | M | V | + Framed-Appletalk-Zone 4.4.10.7.3 | M | V | + ARAP-Features 4.4.10.8.1 | M | V | + ARAP-Zone-Access 4.4.10.8.2 | M | V | + Login-IP-Host 4.4.11.1 | M | V | + Login-IPv6-Host 4.4.11.2 | M | V | + Login-Service 4.4.11.3 | M | V | + Login-TCP-Port 4.4.11.4.1 | M | V | + Login-LAT-Service 4.4.11.5.1 | M | V | + Login-LAT-Node 4.4.11.5.2 | M | V | + Login-LAT-Group 4.4.11.5.3 | M | V | + Login-LAT-Port 4.4.11.5.4 | M | V | + -----------------------------------------|----+-----| + + + + + + + + +Zorn Standards Track [Page 32] + +RFC 7155 Diameter NASREQ April 2014 + + +4.4.1. Service-Type AVP + + The Service-Type AVP (AVP Code 6) is of type Enumerated and contains + the type of service the user has requested or the type of service to + be provided. One such AVP MAY be present in an authentication and/or + authorization request or response. A NAS is not required to + implement all of these service types. It MUST treat unknown or + unsupported Service-Type AVPs received in a response as a failure and + end the session with a DIAMETER_INVALID_AVP_VALUE Result-Code. + + When used in a request, the Service-Type AVP SHOULD be considered a + hint to the server that the NAS believes the user would prefer the + kind of service indicated. The server is not required to honor the + hint. Furthermore, if the service specified by the server is + supported, but not compatible with the current mode of access, the + NAS MUST fail to start the session. The NAS MUST also generate the + appropriate error message(s). + + The complete list of defined values that the Service-Type AVP can + take can be found in [RFC2865] and the relevant IANA registry + [RADIUSAttrVals], but the following values require further + qualification here: + + Login (1) + + The user should be connected to a host. The message MAY + include additional AVPs as defined in Sections 4.4.11.4 or + 4.4.11.5. + + Framed (2) + + A Framed Protocol, such as PPP or SLIP, should be started for + the user. The message MAY include additional AVPs defined in + Sections 4.4.10 or 4.5 for tunneling services. + + Callback Login (3) + + The user should be disconnected and called back, then connected + to a host. The message MAY include additional AVPs defined in + this section. + + + + + + + + + + + +Zorn Standards Track [Page 33] + +RFC 7155 Diameter NASREQ April 2014 + + + Callback Framed (4) + + The user should be disconnected and called back, and then a + Framed Protocol, such as PPP or SLIP, should be started for the + user. The message MAY include additional AVPs defined in + Sections 4.4.10 or 4.5 for tunneling services. + +4.4.2. Callback-Number AVP + + The Callback-Number AVP (AVP Code 19) is of type UTF8String and + contains a dialing string to be used for callback, the format of + which is deployment specific. The Callback-Number AVP MAY be used in + an authentication and/or authorization request as a hint to the + server that a callback service is desired, but the server is not + required to honor the hint in the corresponding response. + + Any further codification of this field's allowed usage range is + outside the scope of this specification. + +4.4.3. Callback-Id AVP + + The Callback-Id AVP (AVP Code 20) is of type UTF8String and contains + the name of a place to be called, to be interpreted by the NAS. This + AVP MAY be present in an authentication and/or authorization + response. + + This AVP is not roaming-friendly as it assumes that the Callback-Id + is configured on the NAS. Using the Callback-Number AVP + (Section 4.4.2) is therefore RECOMMENDED. + +4.4.4. Idle-Timeout AVP + + The Idle-Timeout AVP (AVP Code 28) is of type Unsigned32 and sets the + maximum number of consecutive seconds of idle connection allowable to + the user before termination of the session or before a prompt is + issued. The default is none or system specific. + +4.4.5. Port-Limit AVP + + The Port-Limit AVP (AVP Code 62) is of type Unsigned32 and sets the + maximum number of ports the NAS provides to the user. It MAY be used + in an authentication and/or authorization request as a hint to the + server that multilink PPP [RFC1990] service is desired, but the + server is not required to honor the hint in the corresponding + response. + + + + + + +Zorn Standards Track [Page 34] + +RFC 7155 Diameter NASREQ April 2014 + + +4.4.6. NAS-Filter-Rule AVP + + The NAS-Filter-Rule AVP (AVP Code 400) is of type IPFilterRule and + provides filter rules that need to be configured on the NAS for the + user. One or more of these AVPs MAY be present in an authorization + response. + +4.4.7. Filter-Id AVP + + The Filter-Id AVP (AVP Code 11) is of type UTF8String and contains + the name of the filter list for this user. It is intended to be + human readable. Zero or more Filter-Id AVPs MAY be sent in an + authorization answer message. + + Identifying a filter list by name allows the filter to be used on + different NASes without regard to filter-list implementation details. + However, this AVP is not roaming-friendly, as filter naming differs + from one service provider to another. + + In environments where backward compatibility with RADIUS is not + required, it is RECOMMENDED that the NAS-Filter-Rule AVP + (Section 4.4.6) be used instead. + +4.4.8. Configuration-Token AVP + + The Configuration-Token AVP (AVP Code 78) is of type OctetString and + is sent by a Diameter server to a Diameter Proxy Agent in an AA- + Answer command to indicate a type of user profile to be used. It + should not be sent to a Diameter client (NAS). + + The format of the Data field of this AVP is site specific. + +4.4.9. QoS-Filter-Rule AVP + + The QoS-Filter-Rule AVP (AVP Code 407) is of type QoSFilterRule + (Section 4.1.1) and provides QoS filter rules that need to be + configured on the NAS for the user. One or more such AVPs MAY be + present in an authorization response. + + The use of this AVP is NOT RECOMMENDED; the AVPs defined by [RFC5777] + SHOULD be used instead. + + The following options are defined for the QoSFilterRule filters: + + + + + + + + +Zorn Standards Track [Page 35] + +RFC 7155 Diameter NASREQ April 2014 + + + DSCP <color> + + If action is set to tag (Section 4.1.1), this option MUST be + included in the rule. + + Color values are defined in [RFC2474]. Exact matching of DSCP + values is required (no masks or ranges). + + metering <rate> <color_under> <color_over> + + The metering option provides Assured Forwarding, as defined in + [RFC2597]. and MUST be present if the action is set to meter + (Section 4.1.1) The rate option is the throughput, in bits per + second, used by the access device to mark packets. Traffic + over the rate is marked with the color_over codepoint, and + traffic under the rate is marked with the color_under + codepoint. The color_under and color_over options contain the + drop preferences and MUST conform to the recommended codepoint + keywords described in [RFC2597] (e.g., AF13). + + The metering option also supports the strict limit on traffic + required by Expedited Forwarding, as defined in [RFC3246]. The + color_over option may contain the keyword "drop" to prevent + forwarding of traffic that exceeds the rate parameter. + +4.4.10. Framed Access Authorization AVPs + + This section lists the authorization AVPs necessary to support framed + access, such as PPP and SLIP. AVPs defined in this section MAY be + present in a message if the Service-Type AVP was set to "Framed" or + "Callback Framed". + +4.4.10.1. Framed-Protocol AVP + + The Framed-Protocol AVP (AVP Code 7) is of type Enumerated and + contains the framing to be used for framed access. This AVP MAY be + present in both requests and responses. The supported values are + listed in [RADIUSAttrVals]. + +4.4.10.2. Framed-Routing AVP + + The Framed-Routing AVP (AVP Code 10) is of type Enumerated and + contains the routing method for the user when the user is a router to + a network. This AVP SHOULD only be present in authorization + responses. The supported values are listed in [RADIUSAttrVals]. + + + + + + +Zorn Standards Track [Page 36] + +RFC 7155 Diameter NASREQ April 2014 + + +4.4.10.3. Framed-MTU AVP + + The Framed-MTU AVP (AVP Code 12) is of type Unsigned32 and contains + the Maximum Transmission Unit (MTU) to be configured for the user, + when it is not negotiated by some other means (such as PPP). This + AVP SHOULD only be present in authorization responses. The MTU value + MUST be in the range from 64 to 65535. + +4.4.10.4. Framed-Compression AVP + + The Framed-Compression AVP (AVP Code 13) is of type Enumerated and + contains the compression protocol to be used for the link. It MAY be + used in an authorization request as a hint to the server that a + specific compression type is desired, but the server is not required + to honor the hint in the corresponding response. + + More than one compression protocol AVP MAY be sent. The NAS is + responsible for applying the proper compression protocol to the + appropriate link traffic. + + The supported values are listed in [RADIUSAttrVals]. + +4.4.10.5. IP Access Authorization AVPs + + The AVPs defined in this section are used when the user requests, or + is being granted, access service to IP. + +4.4.10.5.1. Framed-IP-Address AVP + + The Framed-IP-Address AVP (AVP Code 8) [RFC2865] is of type + OctetString and contains an IPv4 address of the type specified in the + attribute value to be configured for the user. It MAY be used in an + authorization request as a hint to the server that a specific address + is desired, but the server is not required to honor the hint in the + corresponding response. + + Two values have special significance: 0xFFFFFFFF and 0xFFFFFFFE. The + value 0xFFFFFFFF indicates that the NAS should allow the user to + select an address (i.e., negotiated). The value 0xFFFFFFFE indicates + that the NAS should select an address for the user (e.g., assigned + from a pool of addresses kept by the NAS). + +4.4.10.5.2. Framed-IP-Netmask AVP + + The Framed-IP-Netmask AVP (AVP Code 9) is of type OctetString and + contains the four octets of the IPv4 netmask to be configured for the + user when the user is a router to a network. It MAY be used in an + authorization request as a hint to the server that a specific netmask + + + +Zorn Standards Track [Page 37] + +RFC 7155 Diameter NASREQ April 2014 + + + is desired, but the server is not required to honor the hint in the + corresponding response. This AVP MUST be present in a response if + the request included this AVP with a value of 0xFFFFFFFF. + +4.4.10.5.3. Framed-Route AVP + + The Framed-Route AVP (AVP Code 22) is of type UTF8String and contains + the 7-bit US-ASCII routing information to be configured for the user + on the NAS. Zero or more of these AVPs MAY be present in an + authorization response. + + The string MUST contain a destination prefix in dotted quad form + optionally followed by a slash and a decimal-length specifier stating + how many high-order bits of the prefix should be used. This is + followed by a space, a gateway address in dotted quad form, a space, + and one or more metrics separated by spaces; for example, + + "192.0.2.0/24 192.0.2.1 1" + + The length specifier may be omitted, in which case it should default + to 8 bits for class A prefixes, 16 bits for class B prefixes, and 24 + bits for class C prefixes; for example, + + "192.0.2.0 192.0.2.1 1" + + Whenever the gateway address is specified as "0.0.0.0", the IP + address of the user SHOULD be used as the gateway address. + +4.4.10.5.4. Framed-Pool AVP + + The Framed-Pool AVP (AVP Code 88) is of type OctetString and contains + the name of an assigned address pool that SHOULD be used to assign an + address for the user. If a NAS does not support multiple address + pools, the NAS SHOULD ignore this AVP. Address pools are usually + used for IP addresses but can be used for other protocols if the NAS + supports pools for those protocols. + + Although specified as type OctetString for compatibility with RADIUS + [RFC2869], the encoding of the Data field SHOULD also conform to the + rules for the UTF8String Data Format. + +4.4.10.5.5. Framed-Interface-Id AVP + + The Framed-Interface-Id AVP (AVP Code 96) is of type Unsigned64 and + contains the IPv6 interface identifier to be configured for the user. + It MAY be used in authorization requests as a hint to the server that + a specific interface identifier is desired, but the server is not + required to honor the hint in the corresponding response. + + + +Zorn Standards Track [Page 38] + +RFC 7155 Diameter NASREQ April 2014 + + +4.4.10.5.6. Framed-IPv6-Prefix AVP + + The Framed-IPv6-Prefix AVP (AVP Code 97) is of type OctetString and + contains the IPv6 prefix to be configured for the user. One or more + AVPs MAY be used in authorization requests as a hint to the server + that specific IPv6 prefixes are desired, but the server is not + required to honor the hint in the corresponding response. + +4.4.10.5.7. Framed-IPv6-Route AVP + + The Framed-IPv6-Route AVP (AVP Code 99) is of type UTF8String and + contains the US-ASCII routing information to be configured for the + user on the NAS. Zero or more of these AVPs MAY be present in an + authorization response. + + The string MUST contain an IPv6 address prefix followed by a slash + and a decimal-length specifier stating how many high-order bits of + the prefix should be used. This is followed by a space, a gateway + address in hexadecimal notation, a space, and one or more metrics + separated by spaces; for example, + + "2001:db8::/32 2001:db8:106:a00:20ff:fe99:a998 1" + + Whenever the gateway address is the IPv6 unspecified address, the IP + address of the user SHOULD be used as the gateway address, such as + in: + + "2001:db8::/32 :: 1" + +4.4.10.5.8. Framed-IPv6-Pool AVP + + The Framed-IPv6-Pool AVP (AVP Code 100) is of type OctetString and + contains the name of an assigned pool that SHOULD be used to assign + an IPv6 prefix for the user. If the access device does not support + multiple prefix pools, it MUST ignore this AVP. + + Although specified as type OctetString for compatibility with RADIUS + [RFC3162], the encoding of the Data field SHOULD also conform to the + rules for the UTF8String Data Format. + +4.4.10.6. IPX Access AVPs + + The AVPs defined in this section are used when the user requests, or + is being granted, access to an IPX network service [IPX]. + + + + + + + +Zorn Standards Track [Page 39] + +RFC 7155 Diameter NASREQ April 2014 + + +4.4.10.6.1. Framed-IPX-Network AVP + + The Framed-IPX-Network AVP (AVP Code 23) is of type Unsigned32 and + contains the IPX Network number to be configured for the user. It + MAY be used in an authorization request as a hint to the server that + a specific address is desired, but the server is not required to + honor the hint in the corresponding response. + + Two addresses have special significance: 0xFFFFFFFF and 0xFFFFFFFE. + The value 0xFFFFFFFF indicates that the NAS should allow the user to + select an address (i.e., Negotiated). The value 0xFFFFFFFE indicates + that the NAS should select an address for the user (e.g., assign it + from a pool of one or more IPX networks kept by the NAS). + +4.4.10.7. AppleTalk Network Access AVPs + + The AVPs defined in this section are used when the user requests, or + is being granted, access to an AppleTalk network [AppleTalk]. + +4.4.10.7.1. Framed-Appletalk-Link AVP + + The Framed-Appletalk-Link AVP (AVP Code 37) is of type Unsigned32 and + contains the AppleTalk network number that should be used for the + serial link to the user, which is another AppleTalk router. This AVP + MUST only be present in an authorization response and is never used + when the user is not another router. + + Despite the size of the field, values range from 0 to 65,535. The + special value of 0 indicates an unnumbered serial link. A value of 1 + to 65,535 means that the serial line between the NAS and the user + should be assigned that value as an AppleTalk network number. + +4.4.10.7.2. Framed-Appletalk-Network AVP + + The Framed-Appletalk-Network AVP (AVP Code 38) is of type Unsigned32 + and contains the AppleTalk network number that the NAS should probe + to allocate an AppleTalk node for the user. This AVP MUST only be + present in an authorization response and is never used when the user + is not another router. Multiple instances of this AVP indicate that + the NAS may probe, using any of the network numbers specified. + + Despite the size of the field, values range from 0 to 65,535. The + special value 0 indicates that the NAS should assign a network for + the user, using its default cable range. A value between 1 and + 65,535 (inclusive) indicates to the AppleTalk network that the NAS + should probe to find an address for the user. + + + + + +Zorn Standards Track [Page 40] + +RFC 7155 Diameter NASREQ April 2014 + + +4.4.10.7.3. Framed-Appletalk-Zone AVP + + The Framed-Appletalk-Zone AVP (AVP Code 39) is of type OctetString + and contains the AppleTalk Default Zone to be used for this user. + This AVP MUST only be present in an authorization response. Multiple + instances of this AVP in the same message are not allowed. + + The codification of this field's allowed range is outside the scope + of this specification. + +4.4.10.8. AppleTalk Remote Access AVPs + + The AVPs defined in this section are used when the user requests, or + is being granted, access to the AppleTalk network via the AppleTalk + Remote Access Protocol [ARAP]. They are only present if the Framed- + Protocol AVP (Section 4.4.10.1) is set to ARAP. Section 2.2 of RFC + 2869 describes the operational use of these attributes. + +4.4.10.8.1. ARAP-Features AVP + + The ARAP-Features AVP (AVP Code 71) is of type OctetString and MAY be + present in the AA-Accept message if the Framed-Protocol AVP is set to + the value of ARAP. See RFC 2869 for more information about the + format of this AVP. + +4.4.10.8.2. ARAP-Zone-Access AVP + + The ARAP-Zone-Access AVP (AVP Code 72) is of type Enumerated and MAY + be present in the AA-Accept message if the Framed-Protocol AVP is set + to the value of ARAP. + + The supported values are listed in [RADIUSAttrVals] and defined in + [RFC2869]. + +4.4.11. Non-Framed Access Authorization AVPs + + This section contains the authorization AVPs that are needed to + support terminal server functionality. AVPs defined in this section + MAY be present in a message if the Service-Type AVP was set to + "Login" or "Callback Login". + +4.4.11.1. Login-IP-Host AVP + + The Login-IP-Host AVP (AVP Code 14) [RFC2865] is of type OctetString + and contains the IPv4 address of a host with which to connect the + user when the Login-Service AVP is included. It MAY be used in an + + + + + +Zorn Standards Track [Page 41] + +RFC 7155 Diameter NASREQ April 2014 + + + AA-Request command as a hint to the Diameter server that a specific + host is desired, but the Diameter server is not required to honor the + hint in the AA-Answer. + + Two addresses have special significance: all ones and 0. The value + of all ones indicates that the NAS SHOULD allow the user to select an + address. The value 0 indicates that the NAS SHOULD select a host to + connect the user to. + +4.4.11.2. Login-IPv6-Host AVP + + The Login-IPv6-Host AVP (AVP Code 98) [RFC3162] is of type + OctetString and contains the IPv6 address of a host with which to + connect the user when the Login-Service AVP is included. It MAY be + used in an AA-Request command as a hint to the Diameter server that a + specific host is desired, but the Diameter server is not required to + honor the hint in the AA-Answer. + + Two addresses have special significance, + 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF and 0. The value + 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF indicates that the NAS SHOULD + allow the user to select an address. The value 0 indicates that the + NAS SHOULD select a host to connect the user to. + +4.4.11.3. Login-Service AVP + + The Login-Service AVP (AVP Code 15) is of type Enumerated and + contains the service that should be used to connect the user to the + login host. This AVP SHOULD only be present in authorization + responses. The supported values are listed in RFC 2869. + +4.4.11.4. TCP Services + + The AVP described in the following section MAY be present if the + Login-Service AVP is set to Telnet, Rlogin, TCP Clear, or TCP Clear + Quiet. + +4.4.11.4.1. Login-TCP-Port AVP + + The Login-TCP-Port AVP (AVP Code 16) is of type Unsigned32 and + contains the TCP port with which the user is to be connected when the + Login-Service AVP is also present. This AVP SHOULD only be present + in authorization responses. The value MUST NOT be greater than + 65,535. + + + + + + + +Zorn Standards Track [Page 42] + +RFC 7155 Diameter NASREQ April 2014 + + +4.4.11.5. LAT Services + + The AVPs described in this section MAY be present if the Login- + Service AVP is set to LAT [LAT]. + +4.4.11.5.1. Login-LAT-Service AVP + + The Login-LAT-Service AVP (AVP Code 34) is of type OctetString and + contains the system with which the user is to be connected by LAT. + It MAY be used in an authorization request as a hint to the server + that a specific service is desired, but the server is not required to + honor the hint in the corresponding response. This AVP MUST only be + present in the response if the Login-Service AVP states that LAT is + desired. + + Administrators use this service attribute when dealing with clustered + systems. In these environments, several different time-sharing hosts + share the same resources (disks, printers, etc.), and administrators + often configure each host to offer access (service) to each of the + shared resources. In this case, each host in the cluster advertises + its services through LAT broadcasts. + + Sophisticated users often know which service providers (machines) are + faster and tend to use a node name when initiating a LAT connection. + Some administrators want particular users to use certain machines as + a primitive form of load balancing (although LAT knows how to do load + balancing itself). + + The String field contains the identity of the LAT service to use. + The LAT Architecture allows this string to contain $ (dollar), - + (hyphen), . (period), _ (underscore), numerics, upper- and lower-case + alphabetics, and the ISO Latin-1 character set extension + [ISO.8859-1.1987]. All LAT string comparisons are case insensitive. + +4.4.11.5.2. Login-LAT-Node AVP + + The Login-LAT-Node AVP (AVP Code 35) is of type OctetString and + contains the Node with which the user is to be automatically + connected by LAT. It MAY be used in an authorization request as a + hint to the server that a specific LAT node is desired, but the + server is not required to honor the hint in the corresponding + response. This AVP MUST only be present in a response if the Login- + Service-Type AVP is set to LAT. + + + + + + + + +Zorn Standards Track [Page 43] + +RFC 7155 Diameter NASREQ April 2014 + + + The String field contains the identity of the LAT service to use. + The LAT Architecture allows this string to contain $ (dollar), - + (hyphen), . (period), _ (underscore), numerics, upper- and lower-case + alphabetics, and the ISO Latin-1 character set extension + [ISO.8859-1.1987]. All LAT string comparisons are case insensitive. + +4.4.11.5.3. Login-LAT-Group AVP + + The Login-LAT-Group AVP (AVP Code 36) is of type OctetString and + contains a string identifying the LAT group codes this user is + authorized to use. It MAY be used in an authorization request as a + hint to the server that a specific group is desired, but the server + is not required to honor the hint in the corresponding response. + This AVP MUST only be present in a response if the Login-Service-Type + AVP is set to LAT. + + LAT supports 256 different group codes, which LAT uses as a form of + access rights. LAT encodes the group codes as a 256-bit bitmap. + + Administrators can assign one or more of the group code bits at the + LAT service provider; it will only accept LAT connections that have + these group codes set in the bitmap. The administrators assign a + bitmap of authorized group codes to each user. LAT gets these from + the operating system and uses them in its requests to the service + providers. + + The codification of the range of allowed usage of this field is + outside the scope of this specification. + +4.4.11.5.4. Login-LAT-Port AVP + + The Login-LAT-Port AVP (AVP Code 63) is of type OctetString and + contains the port with which the user is to be connected by LAT. It + MAY be used in an authorization request as a hint to the server that + a specific port is desired, but the server is not required to honor + the hint in the corresponding response. This AVP MUST only be + present in a response if the Login-Service-Type AVP is set to LAT. + + The String field contains the identity of the LAT service to use. + The LAT Architecture allows this string to contain $ (dollar), - + (hyphen), . (period), _ (underscore), numerics, upper- and lower-case + alphabetics, and the ISO Latin-1 character set extension + [ISO.8859-1.1987]. + + All LAT string comparisons are case insensitive. + + + + + + +Zorn Standards Track [Page 44] + +RFC 7155 Diameter NASREQ April 2014 + + +4.5. NAS Tunneling AVPs + + Some NASes support compulsory tunnel services in which the incoming + connection data is conveyed by an encapsulation method to a gateway + elsewhere in the network. This is typically transparent to the + service user, and the tunnel characteristics may be described by the + remote Authentication, Authorization, and Accounting server, based on + the user's authorization information. Several tunnel characteristics + may be returned, and the NAS implementation may choose one. See + [RFC2868] and [RFC2867] for further information. + + The following table gives the possible flag values for the session- + level AVPs and specifies whether the AVP MAY be encrypted. + + +----------+ + | AVP Flag | + | Rules | + |----+-----| + |MUST| MUST| + Attribute Name Section Defined | | NOT | + -----------------------------------------|----+-----| + Tunneling 4.5.1 | M | V | + Tunnel-Type 4.5.2 | M | V | + Tunnel-Medium-Type 4.5.3 | M | V | + Tunnel-Client-Endpoint 4.5.4 | M | V | + Tunnel-Server-Endpoint 4.5.5 | M | V | + Tunnel-Password 4.5.6 | M | V | + Tunnel-Private-Group-Id 4.5.7 | M | V | + Tunnel-Assignment-Id 4.5.8 | M | V | + Tunnel-Preference 4.5.9 | M | V | + Tunnel-Client-Auth-Id 4.5.10 | M | V | + Tunnel-Server-Auth-Id 4.5.11 | M | V | + -----------------------------------------|----+-----| + +4.5.1. Tunneling AVP + + The Tunneling AVP (AVP Code 401) is of type Grouped and contains the + following AVPs, used to describe a compulsory tunnel service + [RFC2868] [RFC2867]. Its data field has the following ABNF grammar: + + + + + + + + + + + + +Zorn Standards Track [Page 45] + +RFC 7155 Diameter NASREQ April 2014 + + + 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 ] + +4.5.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 ACR 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 [RADIUSAttrVals]. + +4.5.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 [RFC3931]) 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 [RADIUSAttrVals]. + +4.5.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 + + + +Zorn Standards Track [Page 46] + +RFC 7155 Diameter NASREQ April 2014 + + + the hint in the corresponding response. This AVP SHOULD be included + in the corresponding ACR messages, in which case it indicates the + address from which the tunnel was initiated. This AVP, along with + the Tunnel-Server-Endpoint (Section 4.5.5) and Session-Id AVPs + ([RFC6733], Section 8.8), can be used to provide a globally unique + means to identify a tunnel for accounting and auditing purposes. + + If the value of the Tunnel-Medium-Type AVP (Section 4.5.3) 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 [RFC3516]. + 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. + + Note that this application handles Internationalized Domain Names + (IDNs) in the same way as the Diameter Base protocol (see Appendix D + of RFC 6733 for details). + +4.5.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 ACR messages, in + which case it indicates the address from which the tunnel was + initiated. This AVP, along with the Tunnel-Client-Endpoint + (Section 4.5.4) and Session-Id AVP ([RFC6733], Section 8.8), can 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. + + + +Zorn Standards Track [Page 47] + +RFC 7155 Diameter NASREQ April 2014 + + + 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 [RFC3516]. + 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. + + Note that this application handles IDNs in the same way as the + Diameter base protocol (see Appendix D of RFC 6733 for details). + +4.5.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 SHOULD NOT be used in untrusted proxy + environments without encrypting it by using end-to-end security + techniques. + +4.5.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 ACR messages that pertain to the tunneled session. + +4.5.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 [RFC2637] and L2TP [RFC3931], 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 (for example, a LAC) whether to assign the session to a + + + + + +Zorn Standards Track [Page 48] + +RFC 7155 Diameter NASREQ April 2014 + + + 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: + + o 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. + + o 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. + + o 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 + + + + + +Zorn Standards Track [Page 49] + +RFC 7155 Diameter NASREQ April 2014 + + + 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. + +4.5.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 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. + +4.5.10. Tunnel-Client-Auth-Id AVP + + The Tunnel-Client-Auth-Id AVP (AVP Code 90) is of type UTF8String and + specifies the 7-bit US-ASCII 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 ACR messages + pertaining to the tunneled session. + +4.5.11. Tunnel-Server-Auth-Id AVP + + The Tunnel-Server-Auth-Id AVP (AVP Code 91) is of type UTF8String and + specifies the 7-bit US-ASCII 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 + + + +Zorn Standards Track [Page 50] + +RFC 7155 Diameter NASREQ April 2014 + + + 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 ACR + messages pertaining to the tunneled session. + +4.6. NAS Accounting AVPs + + Applications implementing this specification use Diameter Accounting + (as defined in [RFC6733]) and the AVPs in the following section. + Service-specific AVP usage is defined in the tables in Section 5. + + 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 value of the + Accounting-Record-Type AVP [RFC6733] 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 latter 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 gives the possible flag values for the session- + level AVPs and specifies whether the AVP MAY be encrypted. + + + + + + + + + + + + + + + + + + + + + + +Zorn Standards Track [Page 51] + +RFC 7155 Diameter NASREQ April 2014 + + + +----------+ + | AVP Flag | + | Rules | + |----+-----| + Section |MUST| MUST| + Attribute Name Defined | | NOT| + -----------------------------------------|----+-----| + Accounting-Input-Octets 4.6.1 | M | V | + Accounting-Output-Octets 4.6.2 | M | V | + Accounting-Input-Packets 4.6.3 | M | V | + Accounting-Output-Packets 4.6.4 | M | V | + Acct-Session-Time 4.6.5 | M | V | + Acct-Authentic 4.6.6 | M | V | + Accounting-Auth-Method 4.6.7 | M | V | + Acct-Delay-Time 4.6.8 | M | V | + Acct-Link-Count 4.6.9 | M | V | + Acct-Tunnel-Connection 4.6.10 | M | V | + Acct-Tunnel-Packets-Lost 4.6.11 | M | V | + -----------------------------------------|----+-----| + +4.6.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 [RFC6733] of + INTERIM_RECORD or STOP_RECORD. + +4.6.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. + +4.6.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. + + + + + + + +Zorn Standards Track [Page 52] + +RFC 7155 Diameter NASREQ April 2014 + + + 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. + +4.6.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. + +4.6.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. + +4.6.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 [RADIUSAttrVals]. + +4.6.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 + AVP is semantically equivalent, and the supported values are + identical, to the Microsoft MS-Acct-Auth-Type vendor-specific RADIUS + attribute [RFC2548]). + +4.6.8. Acct-Delay-Time AVP + + 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. + + + + + + +Zorn Standards Track [Page 53] + +RFC 7155 Diameter NASREQ April 2014 + + + 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 + it 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 re-sent 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. + +4.6.9. Acct-Link-Count AVP + + 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-Request + AVPs 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-Request AVPs + received with Accounting-Record-Type = STOP_RECORD and with the same + Acct-Multi-Session-Id and unique Session-Id AVPs equals the largest + value of Acct-Link-Count seen in those Accounting-Request AVPs, all + STOP_RECORD Accounting-Request AVPs for that multilink service have + been received. + + The following example, showing eight Accounting-Request AVPs, + 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 + AVPs. + + + + + + + + + + + + + + + + + +Zorn Standards Track [Page 54] + +RFC 7155 Diameter NASREQ April 2014 + + + 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 + +4.6.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 (Section 4.5.4) and + Tunnel-Server-Endpoint (Section 4.5.5) AVPs, may be used to provide a + means to uniquely identify a tunnel session for auditing purposes. + + The format of the identifier in this AVP depends upon the value of + the Tunnel-Type AVP (Section 4.5.2). For example, to identify an + L2TP tunnel connection fully, the L2TP Tunnel Id and Call Id might be + encoded in this field. The exact encoding of this field is + implementation dependent. + +4.6.11. Acct-Tunnel-Packets-Lost AVP + + The Acct-Tunnel-Packets-Lost AVP (AVP Code 86) is of type Unsigned32 + and contains the number of packets lost on a given tunnel. + +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 + table. + + 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 + message. + + + + + +Zorn Standards Track [Page 55] + +RFC 7155 Diameter NASREQ April 2014 + + + 0-1 Zero or one instance of the AVP MAY be present in the + message. + + 1 Exactly one instance of the AVP MUST be present in the + message. + +5.1. AA-Request / AA-Answer AVP Table + + The table in this section is limited to the Command Codes defined in + this specification. + + +-----------+ + | Command | + |-----+-----+ + Attribute Name | AAR | AAA | + ------------------------------|-----+-----+ + Acct-Interim-Interval | 0 | 0-1 | + ARAP-Challenge-Response | 0 | 0-1 | + ARAP-Features | 0 | 0-1 | + ARAP-Password | 0-1 | 0 | + ARAP-Security | 0-1 | 0-1 | + ARAP-Security-Data | 0+ | 0+ | + ARAP-Zone-Access | 0 | 0-1 | + Auth-Application-Id | 1 | 1 | + Auth-Grace-Period | 0-1 | 0-1 | + Auth-Request-Type | 1 | 1 | + Auth-Session-State | 0-1 | 0-1 | + Authorization-Lifetime | 0-1 | 0-1 | + ------------------------------|-----+-----+ + + + + + + + + + + + + + + + + + + + + + + +Zorn Standards Track [Page 56] + +RFC 7155 Diameter NASREQ April 2014 + + + +-----------+ + | Command | + |-----+-----+ + Attribute Name | AAR | AAA | + ------------------------------|-----+-----+ + Callback-Id | 0 | 0-1 | + Callback-Number | 0-1 | 0-1 | + Called-Station-Id | 0-1 | 0 | + Calling-Station-Id | 0-1 | 0 | + CHAP-Auth | 0-1 | 0 | + CHAP-Challenge | 0-1 | 0 | + Class | 0 | 0+ | + Configuration-Token | 0 | 0+ | + Connect-Info | 0+ | 0 | + Destination-Host | 0-1 | 0 | + Destination-Realm | 1 | 0 | + Error-Message | 0 | 0-1 | + Error-Reporting-Host | 0 | 0-1 | + Failed-AVP | 0+ | 0+ | + Filter-Id | 0 | 0+ | + Framed-Appletalk-Link | 0 | 0-1 | + Framed-Appletalk-Network | 0 | 0+ | + Framed-Appletalk-Zone | 0 | 0-1 | + Framed-Compression | 0+ | 0+ | + Framed-Interface-Id | 0-1 | 0-1 | + Framed-IP-Address | 0-1 | 0-1 | + Framed-IP-Netmask | 0-1 | 0-1 | + Framed-IPv6-Prefix | 0+ | 0+ | + Framed-IPv6-Pool | 0 | 0-1 | + Framed-IPv6-Route | 0 | 0+ | + Framed-IPX-Network | 0 | 0-1 | + Framed-MTU | 0-1 | 0-1 | + Framed-Pool | 0 | 0-1 | + Framed-Protocol | 0-1 | 0-1 | + Framed-Route | 0 | 0+ | + Framed-Routing | 0 | 0-1 | + Idle-Timeout | 0 | 0-1 | + Login-IP-Host | 0+ | 0+ | + Login-IPv6-Host | 0+ | 0+ | + Login-LAT-Group | 0-1 | 0-1 | + Login-LAT-Node | 0-1 | 0-1 | + Login-LAT-Port | 0-1 | 0-1 | + Login-LAT-Service | 0-1 | 0-1 | + Login-Service | 0 | 0-1 | + Login-TCP-Port | 0 | 0-1 | + Multi-Round-Time-Out | 0 | 0-1 | + ------------------------------|-----+-----+ + + + + +Zorn Standards Track [Page 57] + +RFC 7155 Diameter NASREQ April 2014 + + + +-----------+ + | Command | + |-----+-----+ + Attribute Name | AAR | AAA | + ------------------------------|-----+-----+ + NAS-Filter-Rule | 0 | 0+ | + NAS-Identifier | 0-1 | 0 | + NAS-IP-Address | 0-1 | 0 | + NAS-IPv6-Address | 0-1 | 0 | + NAS-Port | 0-1 | 0 | + NAS-Port-Id | 0-1 | 0 | + NAS-Port-Type | 0-1 | 0 | + 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 | + Password-Retry | 0 | 0-1 | + Port-Limit | 0-1 | 0-1 | + Prompt | 0 | 0-1 | + Proxy-Info | 0+ | 0+ | + QoS-Filter-Rule | 0 | 0+ | + Re-Auth-Request-Type | 0 | 0-1 | + Redirect-Host | 0 | 0+ | + Redirect-Host-Usage | 0 | 0-1 | + Redirect-Max-Cache-Time | 0 | 0-1 | + Reply-Message | 0 | 0+ | + Result-Code | 0 | 1 | + Route-Record | 0+ | 0 | + Service-Type | 0-1 | 0-1 | + Session-Id | 1 | 1 | + Session-Timeout | 0 | 0-1 | + State | 0-1 | 0-1 | + Tunneling | 0+ | 0+ | + User-Name | 0-1 | 0-1 | + User-Password | 0-1 | 0 | + ------------------------------|-----+-----+ + +5.2. Accounting AVP Tables + + The tables in this section are used to show which AVPs defined in + this document are to be present and used in NAS application + Accounting messages. These AVPs are defined in this document, as + well as in [RFC6733] and [RFC2866]. + + + + + + + +Zorn Standards Track [Page 58] + +RFC 7155 Diameter NASREQ April 2014 + + +5.2.1. Framed Access Accounting AVP Table + + The table in this section is used when the Service-Type AVP + (Section 4.4.1) specifies Framed Access. + + +-----------+ + | Command | + |-----+-----+ + Attribute Name | ACR | ACA | + ---------------------------------------|-----+-----+ + Accounting-Auth-Method | 0-1 | 0 | + Accounting-Input-Octets | 1 | 0 | + Accounting-Input-Packets | 1 | 0 | + Accounting-Output-Octets | 1 | 0 | + Accounting-Output-Packets | 1 | 0 | + Accounting-Record-Number | 0-1 | 0-1 | + Accounting-Record-Type | 1 | 1 | + Accounting-Realtime-Required | 0-1 | 0-1 | + Accounting-Sub-Session-Id | 0-1 | 0-1 | + Acct-Application-Id | 0-1 | 0-1 | + Acct-Session-Id | 1 | 0-1 | + Acct-Multi-Session-Id | 0-1 | 0-1 | + Acct-Authentic | 1 | 0 | + Acct-Delay-Time | 0-1 | 0 | + Acct-Interim-Interval | 0-1 | 0-1 | + Acct-Link-Count | 0-1 | 0 | + Acct-Session-Time | 1 | 0 | + Acct-Tunnel-Connection | 0-1 | 0 | + Acct-Tunnel-Packets-Lost | 0-1 | 0 | + Authorization-Lifetime | 0-1 | 0 | + Callback-Id | 0-1 | 0 | + Callback-Number | 0-1 | 0 | + Called-Station-Id | 0-1 | 0 | + Calling-Station-Id | 0-1 | 0 | + Class | 0+ | 0+ | + Connection-Info | 0+ | 0 | + Destination-Host | 0-1 | 0 | + Destination-Realm | 1 | 0 | + Event-Timestamp | 0-1 | 0-1 | + Error-Message | 0 | 0-1 | + Error-Reporting-Host | 0 | 0-1 | + Failed-AVP | 0 | 0+ | + ---------------------------------------|-----+-----+ + + + + + + + + +Zorn Standards Track [Page 59] + +RFC 7155 Diameter NASREQ April 2014 + + + +-----------+ + | Command | + |-----+-----+ + Attribute Name | ACR | ACA | + ---------------------------------------|-----+-----+ + Framed-Appletalk-Link | 0-1 | 0 | + Framed-Appletalk-Network | 0-1 | 0 | + Framed-Appletalk-Zone | 0-1 | 0 | + Framed-Compression | 0-1 | 0 | + Framed-IP-Address | 0-1 | 0 | + Framed-IP-Netmask | 0-1 | 0 | + Framed-IPv6-Prefix | 0+ | 0 | + Framed-IPv6-Pool | 0-1 | 0 | + Framed-IPX-Network | 0-1 | 0 | + Framed-MTU | 0-1 | 0 | + Framed-Pool | 0-1 | 0 | + Framed-Protocol | 0-1 | 0 | + Framed-Route | 0-1 | 0 | + Framed-Routing | 0-1 | 0 | + NAS-Filter-Rule | 0+ | 0 | + 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 | + Service-Type | 0-1 | 0-1 | + Session-Id | 1 | 1 | + Termination-Cause | 0-1 | 0-1 | + Tunnel-Assignment-Id | 0-1 | 0 | + Tunnel-Client-Endpoint | 0-1 | 0 | + Tunnel-Medium-Type | 0-1 | 0 | + Tunnel-Private-Group-Id | 0-1 | 0 | + Tunnel-Server-Endpoint | 0-1 | 0 | + Tunnel-Type | 0-1 | 0 | + User-Name | 0-1 | 0-1 | + ---------------------------------------|-----+-----+ + + + + + +Zorn Standards Track [Page 60] + +RFC 7155 Diameter NASREQ April 2014 + + +5.2.2. Non-Framed Access Accounting AVP Table + + The table in this section is used when the Service-Type AVP + (Section 4.4.1) specifies Non-Framed Access. + + +-----------+ + | Command | + |-----+-----+ + Attribute Name | ACR | ACA | + ---------------------------------------|-----+-----+ + Accounting-Auth-Method | 0-1 | 0 | + Accounting-Input-Octets | 1 | 0 | + Accounting-Output-Octets | 1 | 0 | + Accounting-Record-Type | 1 | 1 | + Accounting-Record-Number | 0-1 | 0-1 | + Accounting-Realtime-Required | 0-1 | 0-1 | + Accounting-Sub-Session-Id | 0-1 | 0-1 | + Acct-Application-Id | 0-1 | 0-1 | + Acct-Session-Id | 1 | 0-1 | + Acct-Multi-Session-Id | 0-1 | 0-1 | + Acct-Authentic | 1 | 0 | + Acct-Delay-Time | 0-1 | 0 | + Acct-Interim-Interval | 0-1 | 0-1 | + Acct-Link-Count | 0-1 | 0 | + Acct-Session-Time | 1 | 0 | + Authorization-Lifetime | 0-1 | 0 | + Callback-Id | 0-1 | 0 | + Callback-Number | 0-1 | 0 | + Called-Station-Id | 0-1 | 0 | + Calling-Station-Id | 0-1 | 0 | + Class | 0+ | 0+ | + Connection-Info | 0+ | 0 | + Destination-Host | 0-1 | 0 | + Destination-Realm | 1 | 0 | + Event-Timestamp | 0-1 | 0-1 | + Error-Message | 0 | 0-1 | + Error-Reporting-Host | 0 | 0-1 | + Failed-AVP | 0 | 0+ | + Login-IP-Host | 0+ | 0 | + Login-IPv6-Host | 0+ | 0 | + Login-LAT-Service | 0-1 | 0 | + Login-LAT-Node | 0-1 | 0 | + Login-LAT-Group | 0-1 | 0 | + Login-LAT-Port | 0-1 | 0 | + Login-Service | 0-1 | 0 | + Login-TCP-Port | 0-1 | 0 | + ---------------------------------------|-----+-----+ + + + + +Zorn Standards Track [Page 61] + +RFC 7155 Diameter NASREQ April 2014 + + + +-----------+ + | 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. + + + + +Zorn Standards Track [Page 62] + +RFC 7155 Diameter NASREQ April 2014 + + + 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 + this RFC: + + 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 + strings. + + 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 + [RADIUSAttrVals]. + + For the current values allocated, and the policies governing + allocation in those namespaces, please see the above-referenced + registries. + +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 + CHAP. + + + + + + +Zorn Standards Track [Page 63] + +RFC 7155 Diameter NASREQ April 2014 + + + 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 + risk. + + 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 + vulnerability. + +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 + security-sensitive. + + 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. + + + + + + + + +Zorn Standards Track [Page 64] + +RFC 7155 Diameter NASREQ April 2014 + + +9. References + +9.1. Normative References + + [ANITypes] NANPA Number Resource Info, "ANI Assignments", + <http://www.nanpa.com/number_resource_info/ + ani_ii_assignments.html>. + + [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication + Protocol (CHAP)", RFC 1994, August 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, + "Remote Authentication Dial In User Service (RADIUS)", RFC + 2865, June 2000. + + [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC + 3162, August 2001. + + [RFC3516] Nerenberg, L., "IMAP4 Binary Content Extension", RFC 3516, + April 2003. + + [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and + Accounting (AAA) Transport Profile", RFC 3539, June 2003. + + [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", STD 68, RFC 5234, January 2008. + + [RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M., + and A. Lior, "Traffic Classification and Quality of + Service (QoS) Attributes for Diameter", RFC 5777, February + 2010. + + [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, + "Diameter Base Protocol", RFC 6733, October 2012. + +9.2. Informative References + + [ARAP] Apple Computer, "Apple Remote Access Protocol (ARAP) + Version 2.0 External Reference Specification", R0612LL/B , + September 1994. + + [AVP-Codes] + IANA, "AVP Codes", + <http://www.iana.org/assignments/aaa-parameters/>. + + + + +Zorn Standards Track [Page 65] + +RFC 7155 Diameter NASREQ April 2014 + + + [AVP-Vals] IANA, "AVP Specific Values", + <http://www.iana.org/assignments/aaa-parameters/>. + + [App-Ids] IANA, "Application IDs", + <http://www.iana.org/assignments/aaa-parameters/>. + + [AppleTalk] + Sidhu, G., Andrews, R., and A. Oppenheimer, "Inside + AppleTalk", Second Edition Apple Computer, 1990. + + [BASE] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. + Arkko, "Diameter Base Protocol", RFC 3588, September 2003. + + [Command-Codes] + IANA, "Command Codes", + <http://www.iana.org/assignments/aaa-parameters/>. + + [IANA] IANA, "Internet Assigned Numbers Authority", + <http://www.iana.org/>. + + [IPX] Novell, Inc., "NetWare System Technical Interface + Overview", #883-000780-001, June 1989. + + [ISO.8859-1.1987] + International Organization for Standardization, + "Information technology - 8-bit single byte coded graphic + - character sets - Part 1: Latin alphabet No. 1, JTC1/ + SC2", ISO Standard 8859-1, 1987. + + [LAT] Digital Equipment Corp., "Local Area Transport (LAT) + Specification V5.0", AA-NL26A-TE, June 1989. + + [RADIUSAttrVals] + IANA, "Radius Attribute Values", + <http://www.iana.org/assignments/radius-types/>. + + [RFC1334] Lloyd, B. and W. Simpson, "PPP Authentication Protocols", + RFC 1334, October 1992. + + [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, + RFC 1661, July 1994. + + [RFC1990] Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T. + Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, + August 1996. + + + + + + +Zorn Standards Track [Page 66] + +RFC 7155 Diameter NASREQ April 2014 + + + [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 + 1998. + + [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 + 2000. + + [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 + 2001. + + + + + + + +Zorn Standards Track [Page 67] + +RFC 7155 Diameter NASREQ April 2014 + + + [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, + December 2002. + + [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, + August 2005. + + [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible + Authentication Protocol (EAP) Application", RFC 4072, + August 2005. + + [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. + + + + + + + + + + + + + + + + + + + + + + +Zorn Standards Track [Page 68] + +RFC 7155 Diameter NASREQ April 2014 + + +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 + employ. + + + + + + + + + + + + + + +Zorn Standards Track [Page 69] + +RFC 7155 Diameter NASREQ April 2014 + + +Author's Address + + Glen Zorn (editor) + Network Zen + 227/358 Thanon Sanphawut + Bang Na, Bangkok 10260 + Thailand + + Phone: +66 (0)8-1000-4155 + EMail: glenzorn@gmail.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zorn Standards Track [Page 70] + |