idnits 2.17.1 draft-ietf-aaa-diameter-nasreq-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references ([AAACRIT]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 27 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: 7. AVP Occurrence Tables The following tables present the AVPs defined in this document, and specify in which Diameter messages they MAY, or MAY NOT be present. Note that AVPs that can only be present within a Grouped AVP are not represented in this table. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 2002) is 7833 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'DiamTrans' is mentioned on line 195, but not defined == Missing Reference: 'DiamSEC' is mentioned on line 1585, but not defined == Missing Reference: 'RADIPV6' is mentioned on line 2722, but not defined == Unused Reference: 'AAATrans' is defined on line 2583, but no explicit reference was found in the text == Unused Reference: 'EAP' is defined on line 2590, but no explicit reference was found in the text == Unused Reference: 'NAI' is defined on line 2625, but no explicit reference was found in the text == Unused Reference: 'ROAMCRIT' is defined on line 2643, but no explicit reference was found in the text == Unused Reference: 'EXTRADPRAC' is defined on line 2646, but no explicit reference was found in the text == Unused Reference: 'NASMODEL' is defined on line 2649, but no explicit reference was found in the text == Unused Reference: 'NASCRIT' is defined on line 2653, but no explicit reference was found in the text == Unused Reference: 'CDMA2000' is defined on line 2678, but no explicit reference was found in the text == Unused Reference: 'TCPCompress' is defined on line 2682, but no explicit reference was found in the text == Unused Reference: 'L2F' is defined on line 2692, but no explicit reference was found in the text == Unused Reference: 'ATMP' is defined on line 2699, but no explicit reference was found in the text == Unused Reference: 'MSMPPE' is defined on line 2702, but no explicit reference was found in the text == Unused Reference: 'UTF-8' is defined on line 2705, but no explicit reference was found in the text == Unused Reference: 'STD51' is defined on line 2708, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-aaa-diameter-15 == Outdated reference: A later version (-12) exists of draft-ietf-aaa-transport-08 -- Possible downref: Non-RFC (?) normative reference: ref. 'RADTYPE' ** Obsolete normative reference: RFC 2284 (ref. 'EAP') (Obsoleted by RFC 3748) ** Obsolete normative reference: RFC 2373 (ref. 'IPV6ADDR') (Obsoleted by RFC 3513) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISOLATIN' -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA' -- Possible downref: Non-RFC (?) normative reference: ref. 'ANITYPES' -- Obsolete informational reference (is this intentional?): RFC 2486 (ref. 'NAI') (Obsoleted by RFC 4282) == Outdated reference: A later version (-20) exists of draft-chiba-radius-dynamic-authorization-05 == Outdated reference: A later version (-10) exists of draft-ietf-aaa-eap-01 == Outdated reference: A later version (-20) exists of draft-ietf-aaa-diameter-mobileip-13 -- No information found for draft-congdon-8021x-RADIUS - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 1717 (ref. 'PPPMP') (Obsoleted by RFC 1990) -- Obsolete informational reference (is this intentional?): RFC 2279 (ref. 'UTF-8') (Obsoleted by RFC 3629) -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. 'IANAConsid') (Obsoleted by RFC 5226) Summary: 5 errors (**), 0 flaws (~~), 28 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 AAA Working Group Pat R. Calhoun 2 Internet-Draft Black Storm Networks 3 Category: Standards Track Glen Zorn 4 Cisco Systems, Inc. 5 David Spence 6 Interlink Networks, Inc. 7 David Mitton 8 Circular Logic 10 November 2002 12 Diameter NASREQ Application 13 draft-ietf-aaa-diameter-nasreq-10.txt 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This document is a product of the Authentication, Authorization and 37 Accounting (AAA) Working Group of the Internet Engineering Task Force 38 (IETF). Comments are welcome should be submitted to the mailing list 39 aaa-wg@merit.edu. 41 Copyright (C) The Internet Society 2002. All Rights Reserved. 43 Abstract 45 This document describes Diameter applications that are used for AAA 46 in the Network Access Server (NAS) environment. This application, 47 combined with the Diameter base protocol, Transport Profile, EAP and 48 CMS Security specifications, satisfies NAS-related requirements 49 defined in RFC 2989 [AAACRIT]. 51 Given that it is expected that initial deployments of the Diameter 52 protocol will include legacy systems. This application was carefully 53 designed to ease the burden of protocol conversion between RADIUS and 54 Diameter. This is achieved by re-using the RADIUS attribute space, 55 and eliminating the need to perform many attribute translations. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . . 6 61 1.2. Advertising Application Support . . . . . . . . . . . . . . . 6 62 2. NASREQ Calls, Ports, and Sessions . . . . . . . . . . . . . . . 6 63 2.1. Diameter Session Establishment . . . . . . . . . . . . . . . . 7 64 2.2. Diameter Session Re-Authentication or Re-Authorization . . . . 7 65 2.3. Diameter Session Termination . . . . . . . . . . . . . . . . . 8 66 3. NASREQ Messages . . . . . . . . . . . . . . . . . . . . . . . . 8 67 3.1. AA-Request (AAR) Command . . . . . . . . . . . . . . . . . . . 8 68 3.2. AA-Answer (AAA) Command . . . . . . . . . . . . . . . . . . . 11 69 4. NASREQ Application AVPs . . . . . . . . . . . . . . . . . . . . 13 70 4.1. Call and Session Information . . . . . . . . . . . . . . . . . 13 71 4.1.1. NAS-Port AVP . . . . . . . . . . . . . . . . . . . . . . . . 14 72 4.1.2. NAS-Port-Id AVP . . . . . . . . . . . . . . . . . . . . . . 14 73 4.1.3. NAS-Port-Type AVP . . . . . . . . . . . . . . . . . . . . . 15 74 4.1.4. Called-Station-Id AVP . . . . . . . . . . . . . . . . . . . 15 75 4.1.5. Calling-Station-Id AVP . . . . . . . . . . . . . . . . . . . 15 76 4.1.6. Connect-Info AVP . . . . . . . . . . . . . . . . . . . . . . 16 77 4.1.7. Originating-Line-Info AVP . . . . . . . . . . . . . . . . . 16 78 4.1.8. Reply-Message AVP . . . . . . . . . . . . . . . . . . . . . 17 79 4.1.9. Termination-Action AVP . . . . . . . . . . . . . . . . . . . 17 80 4.2. Authentication AVPs . . . . . . . . . . . . . . . . . . . . . 18 81 4.2.1. User-Password AVP . . . . . . . . . . . . . . . . . . . . . 19 82 4.2.2. Password-Retry AVP . . . . . . . . . . . . . . . . . . . . . 20 83 4.2.3. Prompt AVP . . . . . . . . . . . . . . . . . . . . . . . . . 20 84 4.2.4. CHAP-Auth AVP . . . . . . . . . . . . . . . . . . . . . . . 20 85 4.2.5. CHAP-Ident AVP . . . . . . . . . . . . . . . . . . . . . . . 20 86 4.2.6. CHAP-Algorithm AVP . . . . . . . . . . . . . . . . . . . . . 21 87 4.2.7. CHAP-Challenge AVP . . . . . . . . . . . . . . . . . . . . . 21 88 4.2.8. CHAP-Response AVP . . . . . . . . . . . . . . . . . . . . . 21 89 4.2.9. ARAP-Password AVP . . . . . . . . . . . . . . . . . . . . . 21 90 4.2.10. ARAP-Challenge-Response AVP . . . . . . . . . . . . . . . . 21 91 4.2.11. ARAP-Security AVP . . . . . . . . . . . . . . . . . . . . . 22 92 4.2.12. ARAP-Security-Data AVP . . . . . . . . . . . . . . . . . . 22 93 4.3. Authorization AVPs . . . . . . . . . . . . . . . . . . . . . . 22 94 4.3.1. Service-Type AVP . . . . . . . . . . . . . . . . . . . . . . 23 95 4.3.2. Callback-Number AVP . . . . . . . . . . . . . . . . . . . . 24 96 4.3.3. Callback-Id AVP . . . . . . . . . . . . . . . . . . . . . . 24 97 4.3.4. Idle-Timeout AVP . . . . . . . . . . . . . . . . . . . . . . 25 98 4.3.5. Port-Limit AVP . . . . . . . . . . . . . . . . . . . . . . . 25 99 4.3.6. NAS-Filter-Rule AVP . . . . . . . . . . . . . . . . . . . . 25 100 4.3.7. Filter-Id AVP . . . . . . . . . . . . . . . . . . . . . . . 25 101 4.3.8. Configuration-Token AVP . . . . . . . . . . . . . . . . . . 26 102 4.3.9. Framed Access Authorization AVPs . . . . . . . . . . . . . . 26 103 4.3.9.1. Framed-Protocol AVP . . . . . . . . . . . . . . . . . . . 26 104 4.3.9.2. Framed-Routing AVP . . . . . . . . . . . . . . . . . . . . 26 105 4.3.9.3. Framed-MTU AVP . . . . . . . . . . . . . . . . . . . . . . 26 106 4.3.9.4. Framed-Compression AVP . . . . . . . . . . . . . . . . . . 27 107 4.3.10. IP Access . . . . . . . . . . . . . . . . . . . . . . . . . 27 108 4.3.10.1. Framed-IP-Address AVP . . . . . . . . . . . . . . . . . . 27 109 4.3.10.2. Framed-IP-Netmask AVP . . . . . . . . . . . . . . . . . . 27 110 4.3.10.3. Framed-Route AVP . . . . . . . . . . . . . . . . . . . . 28 111 4.3.10.4. Framed-Pool AVP . . . . . . . . . . . . . . . . . . . . . 28 112 4.3.10.5. Framed-Interface-Id AVP . . . . . . . . . . . . . . . . . 28 113 4.3.10.6. Framed-IPv6-Prefix AVP . . . . . . . . . . . . . . . . . 29 114 4.3.10.7. Framed-IPv6-Route AVP . . . . . . . . . . . . . . . . . . 29 115 4.3.10.8. Framed-IPv6-Pool AVP . . . . . . . . . . . . . . . . . . 29 116 4.3.11. IPX Access . . . . . . . . . . . . . . . . . . . . . . . . 29 117 4.3.11.1. Framed-IPX-Network AVP . . . . . . . . . . . . . . . . . 30 118 4.3.12. Appletalk Access . . . . . . . . . . . . . . . . . . . . . 30 119 4.3.12.1. Framed-AppleTalk-Link AVP . . . . . . . . . . . . . . . . 30 120 4.3.12.2. Framed-AppleTalk-Network AVP . . . . . . . . . . . . . . 30 121 4.3.12.3. Framed-AppleTalk-Zone AVP . . . . . . . . . . . . . . . . 31 122 4.3.13. ARAP Access . . . . . . . . . . . . . . . . . . . . . . . . 31 123 4.3.13.1. ARAP-Features AVP . . . . . . . . . . . . . . . . . . . . 31 124 4.3.13.2. ARAP-Zone-Access AVP . . . . . . . . . . . . . . . . . . 31 125 4.3.14. Non-Framed Access Authorization AVPs . . . . . . . . . . . 31 126 4.3.14.1. Login-IP-Host AVP . . . . . . . . . . . . . . . . . . . . 32 127 4.3.14.2. Login-IPv6-Host AVP . . . . . . . . . . . . . . . . . . . 32 128 4.3.14.3. Login-Service AVP . . . . . . . . . . . . . . . . . . . . 32 129 4.3.15. TCP Services . . . . . . . . . . . . . . . . . . . . . . . 32 130 4.3.15.1. Login-TCP-Port AVP . . . . . . . . . . . . . . . . . . . 33 131 4.3.16. LAT Services . . . . . . . . . . . . . . . . . . . . . . . 33 132 4.3.16.1. Login-LAT-Service AVP . . . . . . . . . . . . . . . . . . 33 133 4.3.16.2. Login-LAT-Node AVP . . . . . . . . . . . . . . . . . . . 34 134 4.3.16.3. Login-LAT-Group AVP . . . . . . . . . . . . . . . . . . . 34 135 4.3.16.4. Login-LAT-Port AVP . . . . . . . . . . . . . . . . . . . 34 136 4.4. Tunneling Group AVPs . . . . . . . . . . . . . . . . . . . . . 35 137 4.4.1. Tunnel-Type AVP . . . . . . . . . . . . . . . . . . . . . . 36 138 4.4.2. Tunnel-Medium-Type AVP . . . . . . . . . . . . . . . . . . . 36 139 4.4.3. Tunnel-Client-Endpoint AVP . . . . . . . . . . . . . . . . . 36 140 4.4.4. Tunnel-Server-Endpoint AVP . . . . . . . . . . . . . . . . . 37 141 4.4.5. Tunnel-Password AVP . . . . . . . . . . . . . . . . . . . . 38 142 4.4.6. Tunnel-Private-Group-Id AVP . . . . . . . . . . . . . . . . 38 143 4.4.7. Tunnel-Assignment-Id AVP . . . . . . . . . . . . . . . . . . 38 144 4.4.8. Tunnel-Preference AVP . . . . . . . . . . . . . . . . . . . 40 145 4.4.9. Tunnel-Client-Auth-Id AVP . . . . . . . . . . . . . . . . . 40 146 4.4.10. Tunnel-Server-Auth-Id AVP . . . . . . . . . . . . . . . . . 40 147 5. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 148 5.1. Accounting-Input-Octets AVP . . . . . . . . . . . . . . . . . 42 149 5.2. Accounting-Output-Octets AVP . . . . . . . . . . . . . . . . . 42 150 5.3. Accounting-Input-Packets AVP . . . . . . . . . . . . . . . . . 42 151 5.4. Accounting-Output-Packets AVP . . . . . . . . . . . . . . . . 42 152 5.5. Acct-Session-Time AVP . . . . . . . . . . . . . . . . . . . . 43 153 5.6. Acct-Authentic AVP . . . . . . . . . . . . . . . . . . . . . . 43 154 5.7. Acct-Delay-Time . . . . . . . . . . . . . . . . . . . . . . . 43 155 5.8. Acct-Link-Count . . . . . . . . . . . . . . . . . . . . . . . 43 156 5.9. Acct-Tunnel-Connection AVP . . . . . . . . . . . . . . . . . . 44 157 5.10. Acct-Tunnel-Packets-Lost AVP . . . . . . . . . . . . . . . . 44 158 6. RADIUS/Diameter Protocol Interactions . . . . . . . . . . . . . 45 159 6.1. RADIUS Request Forwarded as Diameter Request . . . . . . . . . 45 160 6.1.1. Diameter Request Forwarded as RADIUS Request . . . . . . . . 47 161 6.2. RADIUS Attributes Used Only for Compatibility . . . . . . . . 48 162 6.2.1. NAS-IP-Address AVP . . . . . . . . . . . . . . . . . . . . . 49 163 6.2.2. NAS-IPv6-Address AVP . . . . . . . . . . . . . . . . . . . . 49 164 6.2.3. NAS-Identifier AVP . . . . . . . . . . . . . . . . . . . . . 49 165 6.2.4. State AVP . . . . . . . . . . . . . . . . . . . . . . . . . 49 166 6.2.5. Termination-Cause AVP Code Values . . . . . . . . . . . . . 50 167 6.3. RADIUS Attributes Not Allowed in Diameter Messages . . . . . . 52 168 6.4. Diameter AVPs that can be Translated to RADIUS Attributes 169 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 170 6.5. RADIUS Vendor Specific Attributes . . . . . . . . . . . . . . 52 171 6.5.1. Transmitting a Diameter Vendor AVP as a RADIUS VSA . . . . . 52 172 6.5.2. Forwarding a RADIUS VSA to a Diameter Vendor AVP . . . . . . 53 173 7. AVP Occurrence Tables . . . . . . . . . . . . . . . . . . . . . 53 174 7.1. AA-Request/Answer AVP Table . . . . . . . . . . . . . . . . . 54 175 7.2. Accounting AVP Tables . . . . . . . . . . . . . . . . . . . . 58 176 7.2.1. Accounting Framed Access AVP Table . . . . . . . . . . . . . 58 177 7.2.2. Accounting Non-Framed Access AVP Table . . . . . . . . . . . 60 178 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 62 179 8.1. Command Codes . . . . . . . . . . . . . . . . . . . . . . . . 62 180 8.2. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . . . 62 181 8.3. Application Identifier . . . . . . . . . . . . . . . . . . . . 62 182 8.4. CHAP-Algorithm AVP Values . . . . . . . . . . . . . . . . . . 62 183 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 62 184 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 63 185 10.1. Normative References . . . . . . . . . . . . . . . . . . . . 63 186 10.2. Informative References . . . . . . . . . . . . . . . . . . . 64 187 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . 66 188 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . . 66 189 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . . 67 190 1. Introduction 192 This document describes Diameter applications that are used for AAA 193 in the Network Access Server (NAS) environment. The Diameter NAS 194 application, when combined with the Diameter base protocol [BASE], 195 Transport Profile [DiamTrans] EAP [DiamEAP], and CMS Security 196 [DiamCMS] specifications, satisfies NAS-related requirements defined 197 in RFC2989 [AAACRIT]. 199 Given that it is expected that initial deployments of the Diameter 200 protocol will include legacy systems, this application was carefully 201 designed to ease the burden of protocol conversion between RADIUS 202 [RADIUS] and Diameter. This is achieved by re-using the RADIUS 203 attribute space, thus eliminating the need to perform many attribute 204 translations. 206 This document first describes the operation of a NASREQ application. 207 Then it defines the Diameter message Command-Codes. The following 208 sections enumerate the AVPs used in these messages grouped by common 209 usage. These are Session Identification, Authentication, 210 Authorization, and Accounting. The Authorization AVPs are further 211 broken down by service type. 213 1.1. Requirements Language 215 In this document, the key words "MAY", "MUST", "MUST NOT", 216 "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be 217 interpreted as described in [KEYWORDS]. 219 1.2. Advertising Application Support 221 Diameter nodes conforming to this specification MAY advertise support 222 by including the value of one (1) in the Auth-Application-Id or the 223 Acct-Application-Id AVP of the Capabilities-Exchange-Request and 224 Capabilities-Exchange-Answer commands [BASE]. 226 2. NASREQ Calls, Ports, and Sessions 228 The arrival of a new call or connection at a port of a Network Access 229 Server (NAS) (or any NASREQ speaking device) starts a Diameter NASREQ 230 message exchange. Information about the call, the identity of the 231 user, and his authentication information are packaged into a Diameter 232 AA-Request (AAR) message and sent to a server. 234 The server processes the information and responds with a Diameter AA- 235 Answer (AAA) message which contains authorization information for the 236 NAS, or a failure code (Result-Code AVP). If the value of Result- 237 Code is DIAMETER_MULTI_ROUND_AUTH, an additional authentication 238 exchange is indicated, and several AAR and AAA messages may be 239 exchanged until the transaction completes. 241 Unlike the RADIUS protocol [RADIUS], the Diameter protocol does not 242 require authentication information to be contained in a request from 243 the client. Therefore, it is possible to send a request for 244 authorization only. The type of service depends upon the Auth- 245 Request-Type AVP. This difference MAY cause operational issues in 246 environments that need RADIUS interoperability, and it MAY be 247 necessary that protocol conversion gateways add authentication 248 information when transmitting to a RADIUS server. 250 2.1. Diameter Session Establishment 252 When the authentication or authorization exchange completes 253 successfully, the NASREQ application SHOULD start a session context, 254 and MAY send an Accounting START_RECORD message [BASE]. The failure 255 to start a session SHOULD cause an Accounting EVENT_RECORD message. 257 2.2. Diameter Session Re-Authentication or Re-Authorization 259 The Diameter protocol allows for users to be periodically re- 260 authenticated and/or re-authorized. In such instances, the Session-Id 261 AVP in the AAR message MUST be the same as the one present in the 262 original authentication/authorization message. A Diameter server 263 informs the NAS of the maximum time allowed before re-authentication 264 or re-authorization via the Authorization-Lifetime AVP [BASE]. Note, 265 however, that the Authorization-Lifetime AVP SHOULD NOT be used if 266 the AAR message contained a NAS-IP-Address or NAS-Identifier AVP 267 since this would mean that the NAS is using RADIUS which does not 268 support server-initiated re-authentication or re-authorization. 270 A NAS MUST re-authenticate and/or authorize after the period provided 271 by the server. Furthermore, it is possible for Diameter servers to 272 issue an unsolicited re-authentication and/or re-authorization by 273 issuing an Re-Auth-Request message to the NAS. Upon receipt of such a 274 message, the NAS is instructed to issue a request to re-authenticate 275 and/or re-authorize the client. 277 2.3. Diameter Session Termination 279 When a NAS receives an indication that a user's session is being 280 disconnected (e.g. LCP Terminate is received), the NAS MUST issue a 281 Session-Termination-Request (STR) [BASE] to its Diameter Server. This 282 will ensure that any resources maintained on the servers is freed 283 appropriately. 285 Further, a NAS that receives a Abort-Session-Request (ASR) [BASE] 286 MUST issue an STR if the session requested is active, and disconnect 287 the PPP (or tunneling) session. 289 Termination of the session context, SHOULD cause the sending of an 290 Accounting STOP_RECORD message [BASE]. 292 More information on Diameter Session Termination is in [BASE] section 293 8.4. 295 3. NASREQ Messages 297 This section defines new Diameter message Command-Code [BASE] values 298 that MUST be supported by all Diameter implementations that conform 299 to this specification. The Command Codes are: 301 Command-Name Abbrev. Code Reference 302 -------------------------------------------------------- 303 AA-Request AAR 265 3.1 304 AA-Answer AAA 265 3.2 306 3.1. AA-Request (AAR) Command 308 The AA-Request message (AAR), indicated by the Command-Code field set 309 to 265 and the 'R' bit set in the Command Flags field, is used in 310 order to request authentication and/or authorization for a given NAS 311 user. The type of request is identified through the Auth-Request-Type 312 AVP, and the default mode is both authentication and authorization. 314 If Authentication is requested the User-Name attribute SHOULD be 315 present, as well as any additional authentication AVPs that would 316 carry the password information. A request for authorization only 317 SHOULD include the information from which the authorization will be 318 performed, such as the User-Name, Called-Station-Id, or Calling- 319 Station-Id AVPs. All requests SHOULD contain AVPs uniquely identifing 320 the source of the call, such as Origin-Host, and NAS-Port. Certain 321 networks MAY use different AVPs for authorization purposes. A request 322 for authorization will include some AVPs defined in section 4.3. 324 It is possible for a single session to be authorized first, then 325 followed by an authentication request. 327 This AA-Request message MAY be the result of a multi-round 328 authentication exchange, which occurs when the AA-Answer message is 329 received with the Result-Code AVP set to DIAMETER_MULTI_ROUND_AUTH. A 330 subsequent AAR message SHOULD be sent, with the User-Password AVP 331 that includes the user's response to the prompt, and MUST include any 332 State AVPs that were present in the AAA message. 334 Message Format 336 ::= < Diameter Header: 265, REQ, PXY > 337 < Session-Id > 338 { Auth-Application-Id } 339 { Origin-Host } 340 { Origin-Realm } 341 { Destination-Realm } 342 { Auth-Request-Type } 343 [ NAS-Port ] 344 [ NAS-Port-Id ] 345 [ Origin-State-Id ] 346 [ Destination-Host ] 347 [ NAS-IP-Address ] 348 [ NAS-IPv6-Address ] 349 [ NAS-Identifier ] 350 [ NAS-Port-Type ] 351 [ Port-Limit ] 352 [ User-Name ] 353 [ User-Password ] 354 [ Service-Type ] 355 [ Idle-Timeout ] 356 [ State ] 357 [ Authorization-Lifetime ] 358 [ Auth-Grace-Period ] 359 [ Auth-Session-State ] 360 [ Session-Timeout ] 361 [ Callback-Number ] 362 [ Called-Station-Id ] 363 [ Calling-Station-Id ] 364 * [ Class ] 365 [ Originating-Line-Info ] 366 [ Connect-Info ] 367 [ CHAP-Auth ] 368 [ CHAP-Challenge ] 369 * [ Framed-Compression ] 370 [ Framed-Interface-Id ] 371 * [ Framed-IPv6-Prefix ] 372 [ Framed-IP-Address ] 373 [ Framed-IP-Netmask ] 374 [ Framed-MTU ] 375 [ Framed-Protocol ] 376 [ ARAP-Password ] 377 [ ARAP-Security ] 378 * [ ARAP-Security-Data ] 379 * [ Login-IP-Host ] 380 * [ Login-IPv6-Host ] 381 [ Login-LAT-Group ] 383 [ Login-LAT-Node ] 384 [ Login-LAT-Port ] 385 [ Login-LAT-Service ] 386 * [ Tunneling ] 387 * [ Proxy-Info ] 388 * [ Route-Record ] 389 * [ AVP ] 391 3.2. AA-Answer (AAA) Command 393 The AA-Answer (AAA) message, is indicated by the Command-Code field 394 set to 265 and the 'R' bit cleared in the Command Flags field, is 395 sent in response to the AA-Request message. If authorization was 396 requested, a successful response will include the authorization AVPs 397 appropriate for the service being provided, as defined in section 398 4.3. 400 For authentication exchanges that require more than a single round 401 trip, the server MUST set the Result-Code AVP to 402 DIAMETER_MULTI_ROUND_AUTH. An AAA message with this result code MAY 403 include one or more Reply-Message and MAY include zero or one State 404 AVPs. 406 If the Reply-Message AVP was present, the access device SHOULD 407 display the text message to the user, and MUST prompt the user for a 408 response. If the access device is unable to prompt the user for a 409 new response, which could be achieved via PAP, it MUST treat this 410 answer as an error, and deny access. 412 Message Format 414 ::= < Diameter Header: 265, PXY > 415 < Session-Id > 416 { Auth-Application-Id } 417 { Auth-Request-Type } 418 { Result-Code } 419 { Origin-Host } 420 { Origin-Realm } 421 [ User-Name ] 422 [ Service-Type ] 423 * [ Class ] 424 * [ Configuration-Token ] 425 [ Acct-Interim-Interval ] 426 [ Error-Message ] 428 [ Error-Reporting-Host ] 429 [ Idle-Timeout ] 430 [ Authorization-Lifetime ] 431 [ Auth-Grace-Period ] 432 [ Auth-Session-State ] 433 [ Re-Auth-Request-Type ] 434 [ Session-Timeout ] 435 [ State ] 436 * [ Reply-Message ] 437 [ Termination-Action ] 438 [ Origin-State-Id ] 439 * [ Filter-Id ] 440 [ Password-Retry ] 441 [ Port-Limit ] 442 [ Prompt ] 443 [ ARAP-Challenge-Response ] 444 [ ARAP-Features ] 445 [ ARAP-Security ] 446 * [ ARAP-Security-Data ] 447 [ ARAP-Zone-Access ] 448 [ Callback-Id ] 449 [ Callback-Number ] 450 [ Framed-Appletalk-Link ] 451 * [ Framed-Appletalk-Network ] 452 [ Framed-Appletalk-Zone ] 453 * [ Framed-Compression ] 454 [ Framed-Interface-Id ] 455 * [ Framed-IPv6-Prefix ] 456 [ Framed-IPv6-Pool ] 457 * [ Framed-IPv6-Route ] 458 [ Framed-IP-Address ] 459 [ Framed-IP-Netmask ] 460 * [ Framed-Route ] 461 [ Framed-Pool ] 462 [ Framed-IPX-Network ] 463 [ Framed-MTU ] 464 [ Framed-Protocol ] 465 [ Framed-Routing ] 466 * [ Login-IP-Host ] 467 * [ Login-IPv6-Host ] 468 [ Login-LAT-Group ] 469 [ Login-LAT-Node ] 470 [ Login-LAT-Port ] 471 [ Login-LAT-Service ] 472 [ Login-Service ] 473 [ Login-TCP-Port ] 474 * [ NAS-Filter-Rule ] 475 * [ Tunneling ] 476 * [ Redirect-Host ] 477 [ Redirect-Host-Usage ] 478 [ Redirect-Max-Cache-Time ] 479 * [ Proxy-Info ] 480 * [ AVP ] 482 4. NASREQ Application AVPs 484 Diameter reserves the AVP Codes 0-255 for RADIUS functions that are 485 implemented in Diameter. 487 AVPs new to Diameter have code values 256 and greater. A Diameter 488 message that includes one of these AVPs MAY cause interoperability 489 issues should the request traverse a AAA node that only supports the 490 RADIUS protocol. However, the Diameter protocol should not be 491 hampered from future developments due to the existing installed base. 493 There are some RADIUS attributes that are not allowed or supported 494 directly in Diameter. See section 6 below for more information. 496 4.1. Call and Session Information 498 This section contains the NASREQ unique AVPs that are needed to 499 identify call and session context information, and allows the server 500 to set constraints on a session. 502 These AVPs are used in addition to the Base AVPs of: 503 Session-Id 504 Auth-Application-Id 505 Origin-Host 506 Origin-Realm 507 Auth-Request-Type 509 Common session status AVPs are listed here too. 511 The following table describes the Session level AVPs, their AVP Code 512 values, types, possible flag values and whether the AVP MAY be 513 encrypted. 515 +---------------------+ 516 | AVP Flag rules | 517 |----+-----+----+-----|----+ 518 AVP Section | | |SHLD| MUST|MAY | 519 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 520 -----------------------------------------|----+-----+----+-----|----| 521 NAS-Port 5 4.1.1 Unsigned32 | M | P | | V | Y | 522 NAS-Port-Id 87 4.1.2 UTF8String | M | P | | V | Y | 523 NAS-Port-Type 61 4.1.3 Enumerated | M | P | | V | Y | 524 Called-Station-Id 30 4.1.4 UTF8String | M | P | | V | Y | 525 Calling-Station- 31 4.1.5 UTF8String | M | P | | V | Y | 526 Id | | | | | | 527 Connect-Info 77 4.1.6 UTF8String | M | P | | V | Y | 528 Originating-Line- 94 4.1.7 OctetString| | M,P | | V | Y | 529 Info | | | | | | 530 Reply-Message 18 4.1.8 UTF8String | M | P | | V | Y | 531 Termination- 29 4.1.9 Enumerated | M | P | | V | Y | 532 Action | | | | | | 533 -----------------------------------------|----+-----+----+-----|----| 535 4.1.1. NAS-Port AVP 537 The NAS-Port AVP (AVP Code 5) is of type Unsigned32 and contains the 538 physical or virtual port number of the NAS which is authenticating 539 the user. Note that this is using "port" in its sense of a service 540 connection on the NAS, not in the sense of an IP protocol identifier. 542 Either NAS-Port or NAS-Port-Id (AVP Code 87) SHOULD be present in AA- 543 Request commands if the NAS differentiates among its ports. 545 4.1.2. NAS-Port-Id AVP 547 The NAS-Port-Id AVP (AVP Code 87) is of type UTF8String and consists 548 of 549 ASCII text that identifies the port of the NAS which is 550 authenticating the user. Note that this is using "port" in its sense 551 of a service connection on the NAS, not in the sense of an IP 552 protocol identifier. 554 Either NAS-Port or NAS-Port-Id SHOULD be present in AA-Request 555 commands if the NAS differentiates among its ports. NAS-Port-Id is 556 intended for use by NASes which cannot conveniently number their 557 ports. 559 4.1.3. NAS-Port-Type AVP 561 The NAS-Port-Type AVP (AVP Code 61) is of type Enumerated and 562 contains the type of the port on which the NAS is authenticating the 563 user. This AVP SHOULD be present if the NAS uses the same NAS-Port 564 number ranges for different services types concurrently. 566 The supported values are defined in [RADTYPE]. 568 4.1.4. Called-Station-Id AVP 570 The Called-Station-Id AVP (AVP Code 30) is of type UTF8String, and 571 allows the NAS to send in the request, the ASCII string of the phone 572 number that the user called, using Dialed Number Identification 573 (DNIS) or a similar technology. Note that this may be different from 574 the phone number the call comes in on. It SHOULD only be present in 575 authentication and/or authorization requests. 577 If the Auth-Request-Type AVP is set to authorization-only and the 578 User-Name AVP is absent, the Diameter Server MAY perform 579 authorization based on this field. This can be used by a NAS to 580 request whether a call should be answered based on the DNIS. 582 The codification of the range of allowed usage of this field is 583 outside the scope of this specification. 585 4.1.5. Calling-Station-Id AVP 587 The Calling-Station-Id AVP (AVP Code 31) is of type UTF8String, and 588 allows the NAS to send in the request the the ASCII string of the 589 phone number that the call came from, using Automatic Number 590 Identification (ANI) or a similar technology. It SHOULD only be 591 present in authentication and/or authorization requests. 593 If the Auth-Request-Type AVP is set to authorization-only and the 594 User-Name AVP is absent, the Diameter Server MAY perform 595 authorization based on this field. This can be used by a NAS to 596 request whether a call should be answered based on the ANI. 598 The codification of the range of allowed usage of this field is 599 outside the scope of this specification. 601 4.1.6. Connect-Info AVP 603 The Connect-Info AVP (AVP Code 77) is of type UTF8String and is sent 604 in the AA-Request message, and indicates the nature of the user's 605 connection. The connection speed SHOULD be included at the beginning 606 of the first Connect-Info AVP in the message. If the transmit and 607 receive connection speeds differ, they may both be included in the 608 first AVP with the transmit speed first (the speed the NAS modem 609 transmits at), a slash (/), the receive speed, then optionally other 610 information. 612 For example, "28800 V42BIS/LAPM" or "52000/31200 V90" 614 4.1.7. Originating-Line-Info AVP 616 The Originating-Line-Info AVP (AVP Code 94 is of type OctetString and 617 is sent by the NAS system to convey information about the origin of 618 the call from an SS7 system. 620 The originating line information (OLI) information element indicates 621 the nature and/or characteristics of the line from which a call 622 originated (e.g. payphone, hotel, cellular). Telephone companies are 623 starting to offer OLI to their customers as an option over Primary 624 Rate Interface (PRI). Internet Service Providers (ISPs) can use OLI 625 in addition to Called-Station-Id and Calling-Station-Id attributes to 626 differentiate customer calls and define different services 628 The Value field contains two octets (00-99). ANSI T1.113 and BELLCORE 629 394 can be used for additional information about those values and 630 their use. For more information on current assignment values see 631 [ANITYPES]. 633 Value Description 634 ------------------------------------------------------------ 635 00 Plain Old Telephone Service (POTS) 636 01 Multiparty line (more than 2) 637 02 ANI Failure 638 03 ANI Observed 639 04 ONI Observed 640 05 ANI Failure Observed 641 06 Station Level Rating 642 07 Special Operator Handling Required 643 08 InterLATA Restricted 644 10 Test Call 645 20 Automatic Identified Outward Dialing (AIOD) 646 23 Coin or Non-Coin 647 24 Toll Free Service (Non-Pay origination) 648 25 Toll Free Service (Pay origination) 649 27 Toll Free Service (Coin Control origination) 650 29 Prison/Inmate Service 651 30-32 Intercept 652 30 Intercept (blank) 653 31 Intercept (trouble) 654 32 Intercept (regular) 655 34 Telco Operator Handled Call 656 40-49 Unrestricted Use 657 52 Outward Wide Area Telecommunications Service (OUTWATS) 658 60 Telecommunications Relay Service (TRS)(Unrestricted) 659 61 Cellular/Wireless PCS (Type 1) 660 62 Cellular/Wireless PCS (Type 2) 661 63 Cellular/Wireless PCS (Roaming) 662 66 TRS (Hotel) 663 67 TRS (Restricted) 664 70 Pay Station, No coin control 665 93 Access for private virtual network service 667 4.1.8. Reply-Message AVP 669 The Reply-Message AVP (AVP Code 18) is of type UTF8String, and 670 contains text which MAY be displayed to the user. When used in an 671 AA-Answer message with a successful Result-Code AVP it indicates a 672 success message. When found in the same message with a Result-Code 673 other than Diameter-SUCCESS it contains a failure message. 675 The Reply-Message AVP MAY indicate a dialog message to prompt the 676 user before another AA-Request attempt. When used in an AA-Answer, it 677 MAY indicate a dialog message to prompt the user for a response. 679 Multiple Reply-Message's MAY be included and if any are displayed, 680 they MUST be displayed in the same order as they appear in the 681 message. 683 4.1.9. Termination-Action AVP 685 The Termination-Action AVP is of type Enumerated and indicates what 686 action the NAS should take when the specified service is completed. 687 This AVP SHOULD only be present in authorization responses. The 688 following values are supported as listed in [RADTYPE]: 690 DEFAULT 0 691 Upon termination of the authorized service the NAS MUST 692 terminate the current session. 694 AA-REQUEST 1 695 Upon termination of the authorized service the NAS MAY send a 696 new AA-Request (AAR) command. When the authorized service 697 terminates, the NAS SHOULD NOT terminate the session or 698 generate a Session-Termination-Request (STR) command. Instead, 699 it SHOULD generate a new AAR command which contains the same 700 value of the Session-Id AVP it sent in the previous AAR 701 command. It SHOULD also include the State AVP from the 702 previous AA-Answer (AAA) command if it contained one. 704 An exception to this rule applies, however, if the authorized 705 service terminates due to the expiry of the Session-Timeout 706 AVP. In this case, the NAS MUST terminate the expired session 707 and MAY generate a new AAR command with a new Session-Id. 709 Note: The Termination-Action AVP is typically used for the login 710 service (Service-Type = 1 or "Login") or by 802.1X supplicants 711 [802.1X] (e.g., NAS-Port-Type = 19 or "Wireless - IEEE 802.11"). 713 When used for the login service, the service typically terminates 714 when the login host clears the connection. The NAS may prompt the 715 user for a new connection and issue a new AA-Request. 717 When used by 802.1X supplicants, the service typically terminates due 718 to the expiry of the Session-Timeout AVP. The access device may then 719 reauthenticate the user with a new AA-Request. The RECOMMENDED way 720 to do this in Diameter is to use the Authorization-Lifetime AVP 721 rather than the Termination-Action AVP. However, the Termination- 722 Action AVP MAY be used when copied from a RADIUS Access-Accept to a 723 Diameter AA-Answer by a Translation Agent. 725 4.2. Authentication AVPs 727 This section defines the AVPs that are necessary to carry the 728 authentication information in the Diameter protocol. The 729 functionality defined here provides a RADIUS-like AAA service, over a 730 more reliable and secure transport, as defined in the base protocol 731 [BASE]. 733 The following table describes the AVPs, their AVP Code values, types, 734 possible flag values and whether the AVP MAY be encrypted. 736 +---------------------+ 737 | AVP Flag rules | 738 |----+-----+----+-----|----+ 739 AVP Section | | |SHLD| MUST|MAY | 740 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 741 -----------------------------------------|----+-----+----+-----|----| 742 User-Password 2 4.2.1 OctetString| M | P | | V | Y | 743 Password-Retry 75 4.2.2 Unsigned32 | M | P | | V | Y | 744 Prompt 76 4.2.3 Enumerated | M | P | | V | Y | 745 CHAP-Auth 409 4.2.4 Grouped | M | P | | V | Y | 746 CHAP-Ident 410 4.2.5 OctetString| M | P | | V | Y | 747 CHAP-Algorithm 412 4.2.6 Enumerated | M | P | | V | Y | 748 CHAP-Challenge 60 4.2.7 OctetString| M | P | | V | Y | 749 CHAP-Response 411 4.2.8 OctetString| M | P | | V | Y | 750 ARAP-Password 70 4.2.9 OctetString| M | P | | V | Y | 751 ARAP-Challenge- 84 4.2.10 OctetString| M | P | | V | Y | 752 Response | | | | | | 753 ARAP-Security 73 4.2.11 Unsigned32 | M | P | | V | Y | 754 ARAP-Security- 74 4.2.12 OctetString| M | P | | V | Y | 755 Data | | | | | | 756 -----------------------------------------|----+-----+----+-----|----| 758 4.2.1. User-Password AVP 760 The User-Password AVP (AVP Code 2) is of type OctetString and 761 contains the password of the user to be authenticated, or the user's 762 input in a multi-round authentication exchange. 764 The User-Password AVP contains a user password or one-time password 765 and therefore represents sensitive information. As required in 766 [BASE], Diameter messages are encrypted using IPsec or TLS. Unless 767 this AVP is used for one-time passwords, the User- Password AVP 768 SHOULD NOT be used in untrusted proxy environments without encrypting 769 it using end-to-end security techniques, such as CMS Security 770 [DiamSEC]. 772 The clear-text password (prior to encryption) MUST NOT be longer than 773 128 bytes in length. 775 4.2.2. Password-Retry AVP 777 The Password-Retry AVP (AVP Code 75) is of type Unsigned32 and MAY be 778 included in the AA-Answer if the Result-Code indicates an 779 authentication failure. The value of this AVP indicates how many 780 authentication attempts a user may be permitted before being 781 disconnected. This AVP is primarily intended for use when the Framed- 782 Protocol AVP (see Section 4.3.9.1) is set to ARAP. 784 4.2.3. Prompt AVP 786 The Prompt AVP (AVP Code 76) is of type Enumerated, and MAY be 787 present in the AA-Answer message. When present, it is used by the NAS 788 to determine whether the user's response, when entered, should be 789 echoed. 791 The supported values are listed under "RADIUS Types" in [RADTYPE]. 793 4.2.4. CHAP-Auth AVP 795 The CHAP-Auth AVP (AVP Code 409) is of type Grouped and contains the 796 information necessary to authenticate a user using the PPP Challenge- 797 Handshake Authentication Protocol (CHAP) [PPPCHAP]. If the CHAP-Auth 798 AVP is found in a message, the CHAP-Challenge AVP MUST be present as 799 well. The AVP containing the CHAP response depends upon the value of 800 the CHAP-Algorithm AVP. Its Data field has the following ABNF 801 grammar: 803 CHAP-Auth ::= < AVP Header: 409 > 804 { CHAP-Algorithm } 805 { CHAP-Ident } 806 [ CHAP-Response ] 807 * [ AVP ] 809 4.2.5. CHAP-Ident AVP 811 The CHAP-Ident AVP (AVP Code 410) is of type OctetString and contains 812 the one octet CHAP Identifier used in the computation of the CHAP 813 response [PPPCHAP]. 815 4.2.6. CHAP-Algorithm AVP 817 The CHAP-Algorithm AVP (AVP Code 412) is of type Enumerated and 818 contains the algorithm identifier used in the computation of the CHAP 819 response [PPPCHAP]. The following values are currently supported: 821 CHAP with MD5 5 822 The CHAP response is computed using the procedure described in 823 [PPPCHAP]. The CHAP-Response AVP MUST be present in the CHAP- 824 Auth AVP. 826 4.2.7. CHAP-Challenge AVP 828 The CHAP-Challenge AVP (AVP Code 60) is of type OctetString and 829 contains the CHAP Challenge sent by the NAS to a PPP Challenge- 830 Handshake Authentication Protocol (CHAP) [PPPCHAP] user. 832 4.2.8. CHAP-Response AVP 834 The CHAP-Response AVP (AVP Code 411) is of type OctetString and 835 contains the 16 octet authentication data provided by the user in 836 response to the CHAP challenge [PPPCHAP]. 838 4.2.9. ARAP-Password AVP 840 The ARAP-Password AVP (AVP Code 70) is of type OctetString and is 841 only present when the Framed-Protocol AVP (see Section 4.3.9.1) is 842 included in the message and is set to ARAP. This AVP MUST NOT be 843 present if either the User-Password or the CHAP-Auth AVP is present. 844 See [RADIUSEXT] for more information on the contents of this AVP. 846 4.2.10. ARAP-Challenge-Response AVP 848 The ARAP-Challenge-Response AVP (AVP Code 84) is of type OctetString 849 and is only present when the Framed-Protocol AVP (see Section 850 4.3.9.1) is included in the message and is set to ARAP. This AVP 851 contains an 8 octet response to the dial-in client's challenge. The 852 RADIUS server calculates this value by taking the dial-in client's 853 challenge from the high order 8 octets of the ARAP-Password AVP and 854 performing DES encryption on this value with the authenticating 855 user's password as the key. If the user's password is less than 8 856 octets in length, the password is padded at the end with NULL octets 857 to a length of 8 before using it as a key. 859 4.2.11. ARAP-Security AVP 861 The ARAP-Security AVP (AVP Code 73) is of type Unsigned32, and MAY be 862 present in the AA-Answer message if the Framed-Protocol AVP (see 863 Section 4.3.9.1) is set to the value of ARAP, and the Result-Code AVP 864 is set to DIAMETER_MULTI_ROUND_AUTH. See [RADIUSEXT] for more 865 information on the format of this AVP. 867 4.2.12. ARAP-Security-Data AVP 869 The ARAP-Security AVP (AVP Code 74) is of type OctetString, and MAY 870 be present in the AA-Request or AA-Answer message if the Framed- 871 Protocol AVP is set to the value of ARAP, and the Result-Code AVP is 872 set to DIAMETER_MULTI_ROUND_AUTH. This AVP contains the security 873 module challenge or response associated with the ARAP Security Module 874 specified in ARAP-Security. 876 4.3. Authorization AVPs 878 in 3 This section contains the authorization AVPs that are supported in 879 the NASREQ Application. The Service-Type AVP SHOULD be present in all 880 messages, and based on the value of the Service-Type AVP, additional 881 AVPs defined in this section and section 5.0 MAY be present. 883 Due to space constraints, the short form IPFiltrRule is used to 884 represent IPFilterRule. 886 +---------------------+ 887 | AVP Flag rules | 888 |----+-----+----+-----|----+ 889 AVP Section | | |SHLD| MUST|MAY | 890 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 891 -----------------------------------------|----+-----+----+-----|----| 892 Service-Type 6 4.3.1 Enumerated | M | P | | V | Y | 893 Callback-Number 19 4.3.2 UTF8String | M | P | | V | Y | 894 Callback-Id 20 4.3.3 UTF8String | M | P | | V | Y | 895 Idle-Timeout 28 4.3.4 Unsigned32 | M | P | | V | Y | 896 Port-Limit 62 4.3.5 Unsigned32 | M | P | | V | Y | 897 NAS-Filter-Rule 400 4.3.6 IPFiltrRule| M | P | | V | Y | 898 Filter-Id 11 4.3.7 UTF8String | M | P | | V | Y | 899 Configuration- 78 4.3.8 OctetString| M | | | P,V | | 900 Token | | | | | | 902 Framed-Protocol 7 4.3.9.1 Enumerated | M | P | | V | Y | 903 Framed-Routing 10 4.3.9.2 Enumerated | M | P | | V | Y | 904 Framed-MTU 12 4.3.9.3 Unsigned32 | M | P | | V | Y | 905 Framed- 13 4.3.9.4 Enumerated | M | P | | V | Y | 906 Compression | | | | | | 907 Framed-IP-Address 8 4.3.10.1 IPAddress | M | P | | V | Y | 908 Framed-IP-Netmask 9 4.3.10.2 IPAddress | M | P | | V | Y | 909 Framed-Route 22 4.3.10.3 UTF8String | M | P | | V | Y | 910 Framed-Pool 88 4.3.10.4 OctetString| M | P | | V | Y | 911 Framed- 96 4.3.10.5 Unsigned64 | M | P | | V | Y | 912 Interface-Id | | | | | | 913 Framed-IPv6- 97 4.3.10.6 IPAddress | M | P | | V | Y | 914 Prefix | | | | | | 915 Framed-IPv6- 99 4.3.10.7 UTF8String | M | P | | V | Y | 916 Route | | | | | | 917 Framed-IPv6-Pool 100 4.3.10.8 OctetString| M | P | | V | Y | 918 Framed-IPX- 23 4.3.11.1 UTF8String | M | P | | V | Y | 919 Network | | | | | | 920 Framed-Appletalk- 37 4.3.12.1 Unsigned32 | M | P | | V | Y | 921 Link | | | | | | 922 Framed-Appletalk- 38 4.3.12.2 Unsigned32 | M | P | | V | Y | 923 Network | | | | | | 924 Framed-Appletalk- 39 4.3.12.3 OctetString| M | P | | V | Y | 925 Zone | | | | | | 926 ARAP-Features 71 4.3.13.1 OctetString| M | P | | V | Y | 927 ARAP-Zone-Access 72 4.3.13.2 Enumerated | M | P | | V | Y | 928 Login-IP-Host 14 4.3.14.1 IPAddress | M | P | | V | Y | 929 Login-IPv6-Host 98 4.3.14.2 IPAddress | M | P | | V | Y | 930 Login-Service 15 4.3.14.3 Enumerated | M | P | | V | Y | 931 Login-TCP-Port 16 4.3.15.1 Unsigned32 | M | P | | V | Y | 932 Login-LAT-Service 34 4.3.16.1 OctetString| M | P | | V | Y | 933 Login-LAT-Node 35 4.3.16.2 OctetString| M | P | | V | Y | 934 Login-LAT-Group 36 4.3.16.3 OctetString| M | P | | V | Y | 935 Login-LAT-Port 63 4.3.16.4 OctetString| M | P | | V | Y | 936 -----------------------------------------|----+-----+----+-----|----| 938 4.3.1. Service-Type AVP 940 The Service-Type AVP (AVP Code 6) is of type Enumerated and contains 941 the type of service the user has requested, or the type of service to 942 be provided. One such AVP MAY be present in an authentication and/or 943 authorization request or response. A NAS is not required to implement 944 all of these service types, and MUST treat unknown or unsupported 945 Service-Types as though a response with a Result-Code other than 946 Diameter-SUCCESS had been received instead. 948 When used in a request, the Service-Type AVP SHOULD be considered to 949 be a hint to the server that the NAS has reason to believe the user 950 would prefer the kind of service indicated, but the server is not 951 required to honor the hint. The following values have been defined 952 for the Service-Type AVP: 954 The complete list of defined values can be found in [RADIUS] and 955 [RADTYPE]. The following values are extracted from [RADIUS] and are 956 listed here since they are further qualified: 958 Login 1 959 The user should be connected to a host. The message MAY include 960 additional AVPs defined in sections 4.3.14, 4.1.15, and 4.3.16. 962 Framed 2 963 A Framed Protocol should be started for the User, such as PPP 964 or SLIP. The message MAY include additional AVPs defined in 965 section 4.3.9, or 4.4 for tunneling services. 967 Callback Login 3 968 The user should be disconnected and called back, then connected 969 to a host. The message MAY include additional AVPs defined in 970 this section. 972 Callback Framed 4 973 The user should be disconnected and called back, then a Framed 974 Protocol should be started for the User, such as PPP or SLIP. 975 The message MAY include additional AVPs defined in section 976 4.3.9, or 4.4 for tunneling services. 978 4.3.2. Callback-Number AVP 980 The Callback-Number AVP (AVP Code 19) is of type UTF8String, and 981 contains a dialing string to be used for callback. It MAY be used in 982 an authentication and/or authorization request as a hint to the 983 server that a Callback service is desired, but the server is not 984 required to honor the hint in the corresponding response. 986 The codification of the range of allowed usage of this field is 987 outside the scope of this specification. 989 4.3.3. Callback-Id AVP 991 The Callback-Id AVP (AVP Code 20) is of type UTF8String, and contains 992 the name of a place to be called, to be interpreted by the NAS. This 993 AVP MAY be present in an authentication and/or authorization 994 response. 996 This AVP is not roaming-friendly since it assumes that the Callback- 997 Id is configured on the NAS. It is therefore preferable to use the 998 Callback-Number AVP instead. 1000 4.3.4. Idle-Timeout AVP 1002 The Idle-Timeout AVP (AVP Code 28) is of type Unsigned32 and sets the 1003 maximum number of consecutive seconds of idle connection allowed to 1004 the user before termination of the session or prompt. It MAY be used 1005 in an authentication and/or authorization request (or challenge) as a 1006 hint to the server that an idle timeout is desired, but the server is 1007 not required to honor the hint in the corresponding response. 1009 4.3.5. Port-Limit AVP 1011 The Port-Limit AVP (AVP Code 62) is of type Unsigned32 and sets the 1012 maximum number of ports to be provided to the user by the NAS. It 1013 MAY be used in an authentication and/or authorization request as a 1014 hint to the server that multilink PPP [PPPMP] service is desired, but 1015 the server is not required to honor the hint in the corresponding 1016 response. 1018 4.3.6. NAS-Filter-Rule AVP 1020 The NAS-Filter-Rule AVP (AVP Code 400) is of type IPFilterRule, and 1021 provides filter rules that need to be configured on the NAS for the 1022 user. One or more such AVPs MAY be present in an authorization 1023 response. 1025 4.3.7. Filter-Id AVP 1027 The Filter-Id AVP (AVP Code 11) is of type UTF8String, and contains 1028 the name of the filter list for this user. Zero or more Filter-Id 1029 AVPs MAY be sent in an authorization answer. 1031 Identifying a filter list by name allows the filter to be used on 1032 different NASes without regard to filter-list implementation details. 1033 However, this AVP is not roaming friendly since filter naming differs 1034 from one service provider to another. 1036 In non-RADIUS environments, it is RECOMMENDED that the NAS-Filter- 1037 Rule AVP be used instead. 1039 4.3.8. Configuration-Token AVP 1041 The Configuration-Token AVP (AVP Code 78) is of type OctetString and 1042 is sent by a Diameter Server to a Diameter Proxy Agent or Translation 1043 Agent in an AA-Answer command to indicate a type of user profile to 1044 be used. It should not be sent to a Diameter Client (NAS). 1046 The format of the Data field of this AVP is site specific. 1048 4.3.9. Framed Access Authorization AVPs 1050 This section contains the authorization AVPs that are necessary to 1051 support framed access, such as PPP, SLIP, etc. AVPs defined in this 1052 section MAY be present in a message if the Service-Type AVP was set 1053 to "Framed" or "Callback Framed". 1055 4.3.9.1. Framed-Protocol AVP 1057 The Framed-Protocol AVP (AVP Code 7) is of type Enumerated and 1058 contains the framing to be used for framed access. This AVP MAY be 1059 present in both requests and responses. The supported values are 1060 listed in [RADTYPE]. 1062 4.3.9.2. Framed-Routing AVP 1064 The Framed-Routing AVP (AVP Code 10) is of type Enumerated and 1065 contains the routing method for the user, when the user is a router 1066 to a network. This AVP SHOULD only be present in authorization 1067 responses. The supported values are listed in [RADTYPE]. 1069 4.3.9.3. Framed-MTU AVP 1071 The Framed-MTU AVP (AVP Code 12) is of type Unsigned32 and contains 1072 the Maximum Transmission Unit to be configured for the user, when it 1073 is not negotiated by some other means (such as PPP). This AVP SHOULD 1074 only be present in authorization responses. The MTU value MUST be 1075 between the range of 64 and 65535. 1077 4.3.9.4. Framed-Compression AVP 1079 The Framed-Compression AVP (AVP Code 13) is of type Enumerated and 1080 contains the compression protocol to be used for the link. It MAY be 1081 used in an authorization request as a hint to the server that a 1082 specific compression type is desired, but the server is not required 1083 to honor the hint in the corresponding response. 1085 More than one compression protocol AVP MAY be sent. It is the 1086 responsibility of the NAS to apply the proper compression protocol to 1087 appropriate link traffic. 1089 The supported values are listed in [RADTYPE]. 1091 4.3.10. IP Access 1093 The AVPs defined in this section are used when the user requests, or 1094 is being granted, access to IP. They are only present if the Framed- 1095 Protocol AVP (see Section 4.3.9.1) is set to PPP, SLIP, Gandalf 1096 proprietarySingleLink/MultiLink protocol, or X.75 Synchronous. 1098 4.3.10.1. Framed-IP-Address AVP 1100 The Framed-IP-Address AVP (AVP Code 8) is of type IPAddress and 1101 contains the address to be configured for the user. It MAY be used in 1102 an authorization request as a hint to the server that a specific 1103 address is desired, but the server is not required to honor the hint 1104 in the corresponding response. 1106 Two addresses have special significance; 0xFFFFFFFF and 0xFFFFFFFE. 1107 The value 0xFFFFFFFF indicates that the NAS should allow the user to 1108 select an address (e.g. Negotiated). The value 0xFFFFFFFE indicates 1109 that the NAS should select an address for the user (e.g. Assigned 1110 from a pool of addresses kept by the NAS). 1112 4.3.10.2. Framed-IP-Netmask AVP 1114 The Framed-IP-Netmask AVP (AVP Code 9) is of type IPAddress and 1115 contains the IP netmask to be configured for the user when the user 1116 is a router to a network. It MAY be used in an authorization request 1117 as a hint to the server that a specific netmask is desired, but the 1118 server is not required to honor the hint in the corresponding 1119 response. This AVP MUST be present in a response if the request 1120 included this AVP with a value of 0xFFFFFFFF. 1122 4.3.10.3. Framed-Route AVP 1124 The Framed-Route AVP (AVP Code 22) is of type UTF8String, and 1125 contains the ASCII routing information to be configured for the user 1126 on the NAS. Zero or more such AVPs MAY be present in an authorization 1127 response. 1129 The string MUST contain a destination prefix in dotted quad form 1130 optionally followed by a slash and a decimal length specifier stating 1131 how many high order bits of the prefix should be used. That is 1132 followed by a space, a gateway address in dotted quad form, a space, 1133 and one or more metrics separated by spaces. For example, 1134 "192.168.1.0/24 192.168.1.1 1". 1136 The length specifier may be omitted in which case it should default 1137 to 8 bits for class A prefixes, 16 bits for class B prefixes, and 24 1138 bits for class C prefixes. For example, "192.168.1.0 192.168.1.1 1". 1140 Whenever the gateway address is specified as "0.0.0.0" the IP address 1141 of the user SHOULD be used as the gateway address. 1143 4.3.10.4. Framed-Pool AVP 1145 The Framed-Pool AVP (AVP Code 88) is of type OctetString and contains 1146 the name of an assigned address pool that SHOULD be used to assign an 1147 address for the user. If a NAS does not support multiple address 1148 pools, the NAS SHOULD ignore this AVP. Address pools are usually 1149 used for IP addresses, but can be used for other protocols if the NAS 1150 supports pools for those protocols. 1152 Although specified as type OctetString for compatibility with RADIUS 1153 [RADIUSEXT], the encoding of the Data field SHOULD also conform to 1154 the rules for the UTF8String Data Format. 1156 4.3.10.5. Framed-Interface-Id AVP 1158 The Framed-Interface-Id AVP (AVP Code 96) is of type Unsigned64 and 1159 contains the IPv6 interface identifier to be configured for the user. 1160 It MAY be used in authorization requests as a hint to the server that 1161 a specific interface id is desired, but the server is not required to 1162 honor the hint in the corresponding response. 1164 4.3.10.6. Framed-IPv6-Prefix AVP 1166 The Framed-IPv6-Prefix AVP (AVP Code 97) is of type IPAddress and 1167 contains the IPv6 prefix to be configured for the user. One or more 1168 AVPs MAY be used in authorization requests as a hint to the server 1169 that a specific IPv6 prefixes are desired, but the server is not 1170 required to honor the hint in the corresponding response. 1172 4.3.10.7. Framed-IPv6-Route AVP 1174 The Framed-IPv6-Route AVP (AVP Code 99) is of type UTF8String, and 1175 contains the ASCII routing information to be configured for the user 1176 on the NAS. Zero or more such AVPs MAY be present in an authorization 1177 response. 1179 The string MUST contain an IPv6 address prefix followed by a slash 1180 and a decimal length specifier stating how many high order bits of 1181 the prefix should be used. That is followed by a space, a gateway 1182 address in hexadecimal notation, a space, and one or more metrics 1183 separated by spaces. For example: 1184 "2000:0:0:106::/64 2000::106:a00:20ff:fe99:a998 1". 1186 Whenever the gateway address is the IPv6 unspecified address the IP 1187 address of the user SHOULD be used as the gateway address, such as: 1188 "2000:0:0:106::/64 :: 1". 1190 4.3.10.8. Framed-IPv6-Pool AVP 1192 The Framed-IPv6-Pool AVP (AVP Code 100) is of type OctetString, and 1193 contains the name of an assigned pool that SHOULD be used to assign 1194 an IPv6 prefix for the user. If the access device does not support 1195 multiple prefix pools, it MUST ignore this AVP. 1197 Although specified as type OctetString for compatibility with RADIUS 1198 [RADIUSIPV6], the encoding of the Data field SHOULD also conform to 1199 the rules for the UTF8String Data Format. 1201 4.3.11. IPX Access 1203 The AVPs defined in this section are used when the user requests, or 1204 is being granted, access to IPX. They are only present if the Framed- 1205 Protocol AVP (see Section 4.3.9.1) is set to PPP, Xylogics 1206 proprietary IPX/SLIP, Gandalf proprietarySingleLink/MultiLink 1207 protocol, or X.75 Synchronous. 1209 4.3.11.1. Framed-IPX-Network AVP 1211 The Framed-IPX-Network AVP (AVP Code 23) is of type UTF8String, and 1212 contains the IPX Network number to be configured for the user. It MAY 1213 be used in an authorization request as a hint to the server that a 1214 specific address is desired, but the server is not required to honor 1215 the hint in the corresponding response. 1217 Two addresses have special significance; 0xFFFFFFFF and 0xFFFFFFFE. 1218 The value 0xFFFFFFFF indicates that the NAS should allow the user to 1219 select an address (e.g. Negotiated). The value 0xFFFFFFFE indicates 1220 that the NAS should select an address for the user (e.g. assigned 1221 from a pool of one or more IPX networks kept by the NAS). 1223 4.3.12. Appletalk Access 1225 The AVPs defined in this section are used when the user requests, or 1226 is being granted, access to Appletalk. They are only present if the 1227 Framed-Protocol AVP (see Section 4.3.9.1) is set to PPP, Gandalf 1228 proprietary SingleLink/MultiLink protocol, or X.75 Synchronous. 1230 4.3.12.1. Framed-AppleTalk-Link AVP 1232 The Framed-AppleTalk-Link AVP (AVP Code 37) is of type Unsigned32 and 1233 contains the AppleTalk network number which should be used for the 1234 serial link to the user, which is another AppleTalk router. This AVP 1235 MUST only be present in an authorization response and is never used 1236 when the user is not another router. 1238 Despite the size of the field, values range from zero to 65535. The 1239 special value of zero indicates that this is an unnumbered serial 1240 link. A value of one to 65535 means that the serial line between the 1241 NAS and the user should be assigned that value as an AppleTalk 1242 network number. 1244 4.3.12.2. Framed-AppleTalk-Network AVP 1246 The Framed-AppleTalk-Network AVP (AVP Code 38) is of type Unsigned32 1247 and contains the AppleTalk Network number which the NAS should probe 1248 to allocate an AppleTalk node for the user. This AVP MUST only be 1249 present in an authorization response and is never used when the user 1250 is not another router. Multiple instances of this AVP indicate that 1251 the NAS may probe using any of the network numbers specified. 1253 Despite the size of the field, values range from zero to 65535. The 1254 special value zero indicates that the NAS should assign a network for 1255 the user, using its default cable range. A value between one and 1256 65535 (inclusive) indicates the AppleTalk Network the NAS should 1257 probe to find an address for the user. 1259 4.3.12.3. Framed-AppleTalk-Zone AVP 1261 The Framed-AppleTalk-Zone AVP (AVP Code 39) is of type OctetString 1262 and contains the AppleTalk Default Zone to be used for this user. 1263 This AVP MUST only be present in an authorization response. Multiple 1264 instances of this AVP in the same message are not allowed. 1266 The codification of the range of allowed usage of this field is 1267 outside the scope of this specification. 1269 4.3.13. ARAP Access 1271 The AVPs defined in this section are used when the user requests, or 1272 is being granted, access to ARAP. They are only present if the 1273 Framed-Protocol AVP (see Section 4.3.9.1) is set to AppleTalk Remote 1274 Access Protocol (ARAP). 1276 4.3.13.1. ARAP-Features AVP 1278 The ARAP-Features AVP (AVP Code 71) is of type OctetString, and MAY 1279 be present in the AA-Accept message if the Framed-Protocol AVP is set 1280 to the value of ARAP. See [RADIUSEXT] for more information of the 1281 format of this AVP. 1283 4.3.13.2. ARAP-Zone-Access AVP 1285 The ARAP-Zone-Access AVP (AVP Code 72) is of type Enumerated, and MAY 1286 be present in the AA-Accept message if the Framed-Protocol AVP is set 1287 to the value of ARAP. 1289 The supported values are listed in [RADTYPE], and are defined in 1290 [RADIUSEXT]. 1292 4.3.14. Non-Framed Access Authorization AVPs 1294 This section contains the authorization AVPs that are needed to 1295 support terminal server functionality. AVPs defined in this section 1296 MAY be present in a message if the Service-Type AVP was set to 1297 "Login" or "Callback Login". 1299 4.3.14.1. Login-IP-Host AVP 1301 The Login-IP-Host AVP (AVP Code 14) [RADIUS] is of type IPAddress and 1302 contains the IPv4 address of a host with which to connect the user 1303 when the Login-Service AVP is included. It MAY be used in an AA- 1304 Request command as a hint to the Diameter Server that a specific host 1305 is desired, but the Diameter Server is not required to honor the hint 1306 in the AA-Answer. 1308 Two addresses have special significance: 0xFFFFFFFF and 0. The value 1309 0xFFFFFFFF indicates that the NAS SHOULD allow the user to select an 1310 address. The value 0 indicates that the NAS SHOULD select a host to 1311 connect the user to. 1313 4.3.14.2. Login-IPv6-Host AVP 1315 The Login-IPv6-Host AVP (AVP Code 98) [RADIUSIPV6] is of type 1316 IPAddress and contains the IPv6 address of a host with which to 1317 connect the user when the Login-Service AVP is included. It MAY be 1318 used in an AA-Request command as a hint to the Diameter Server that a 1319 specific host is desired, but the Diameter Server is not required to 1320 honor the hint in the AA-Answer. 1322 Two addresses have special significance: 1323 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF and 0. The value 1324 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF indicates that the NAS SHOULD 1325 allow the user to select an address. The value 0 indicates that the 1326 NAS SHOULD select a host to connect the user to. 1328 4.3.14.3. Login-Service AVP 1330 The Login-Service AVP (AVP Code 15) is of type Enumerated and 1331 contains the service which should be used to connect the user to the 1332 login host. This AVP SHOULD only be present in authorization 1333 responses. 1335 The supported values are listed in [RADTYPE]. 1337 4.3.15. TCP Services 1339 The AVPs described in this section MAY be present if the Login- 1340 Service AVP is set to Telnet, Rlogin, TCP Clear or TCP Clear Quiet. 1342 4.3.15.1. Login-TCP-Port AVP 1344 The Login-TCP-Port AVP (AVP Code 16) is of type Unsigned32 and 1345 contains the TCP port with which the user is to be connected, when 1346 the Login-Service AVP is also present. This AVP SHOULD only be 1347 present in authorization responses. The value MUST NOT be greater 1348 than 65535. 1350 4.3.16. LAT Services 1352 The AVP described in this section MAY be present if the Login-Service 1353 AVP is set to LAT. 1355 4.3.16.1. Login-LAT-Service AVP 1357 The Login-LAT-Service AVP (AVP Code 34) is of type OctetString and 1358 contains the system with which the user is to be connected by LAT. It 1359 MAY be used in an authorization request as a hint to the server that 1360 a specific service is desired, but the server is not required to 1361 honor the hint in the corresponding response. This AVP MUST only be 1362 present in the response if the Login-Service AVP states that LAT is 1363 desired. 1365 Administrators use the service attribute when dealing with clustered 1366 systems, such as a VAX or Alpha cluster. In such an environment 1367 several different time sharing hosts share the same resources (disks, 1368 printers, etc.), and administrators often configure each to offer 1369 access (service) to each of the shared resources. In this case, each 1370 host in the cluster advertises its services through LAT broadcasts. 1372 Sophisticated users often know which service providers (machines) are 1373 faster and tend to use a node name when initiating a LAT connection. 1374 Alternately, some administrators want particular users to use certain 1375 machines as a primitive form of load balancing (although LAT knows 1376 how to do load balancing itself). 1378 The String field contains the identity of the LAT service to use. 1379 The LAT Architecture allows this string to contain $ (dollar), - 1380 (hyphen), . (period), _ (underscore), numerics, upper and lower case 1381 alphabetics, and the ISO Latin-1 character set extension [ISOLATIN]. 1382 All LAT string comparisons are case insensitive. 1384 4.3.16.2. Login-LAT-Node AVP 1386 The Login-LAT-Node AVP (AVP Code 35) is of type OctetString and 1387 contains the Node with which the user is to be automatically 1388 connected by LAT. It MAY be used in an authorization request as a 1389 hint to the server that a specific LAT node is desired, but the 1390 server is not required to honor the hint in the corresponding 1391 response. This AVP MUST only be present in a response if the Service- 1392 Type AVP is set to LAT. 1394 The String field contains the identity of the LAT service to use. 1395 The LAT Architecture allows this string to contain $ (dollar), - 1396 (hyphen), . (period), _ (underscore), numerics, upper and lower case 1397 alphabetics, and the ISO Latin-1 character set extension [ISOLATIN]. 1398 All LAT string comparisons are case insensitive. 1400 4.3.16.3. Login-LAT-Group AVP 1402 The Login-LAT-Group AVP (AVP Code 36) is of type OctetString and 1403 contains a string identifying the LAT group codes which this user is 1404 authorized to use. It MAY be used in an authorization request as a 1405 hint to the server that a specific group is desired, but the server 1406 is not required to honor the hint in the corresponding response. This 1407 AVP MUST only be present in a response if the Service-Type AVP is set 1408 to LAT. 1410 LAT supports 256 different group codes, which LAT uses as a form of 1411 access rights. LAT encodes the group codes as a 256 bit bitmap. 1413 Administrators can assign one or more of the group code bits at the 1414 LAT service provider; it will only accept LAT connections that have 1415 these group codes set in the bit map. The administrators assign a 1416 bitmap of authorized group codes to each user; LAT gets these from 1417 the operating system, and uses these in its requests to the service 1418 providers. 1420 The codification of the range of allowed usage of this field is 1421 outside the scope of this specification. 1423 4.3.16.4. Login-LAT-Port AVP 1425 The Login-LAT-Port AVP (AVP Code 63) is of type OctetString and 1426 contains the Port with which the user is to be connected by LAT. It 1427 MAY be used in an authorization request as a hint to the server that 1428 a specific port is desired, but the server is not required to honor 1429 the hint in the corresponding response. This AVP MUST only be present 1430 in a response if the Service-Type AVP is set to LAT. 1432 The String field contains the identity of the LAT service to use. 1433 The LAT Architecture allows this string to contain $ (dollar), - 1434 (hyphen), . (period), _ (underscore), numerics, upper and lower case 1435 alphabetics, and the ISO Latin-1 character set extension [ISOLATIN]. 1436 All LAT string comparisons are case insensitive. 1438 4.4. Tunneling Group AVPs 1440 The Tunneling AVP (AVP Code 403) is of type Grouped and contains AVPs 1441 used to describe a tunnel. Its Data field has the following ABNF 1442 grammar: 1444 Tunneling ::= < AVP Header: 403 > 1445 { Tunnel-Type } 1446 { Tunnel-Medium-Type } 1447 { Tunnel-Client-Endpoint } 1448 { Tunnel-Server-Endpoint } 1449 [ Tunnel-Preference ] 1450 [ Tunnel-Client-Auth-Id ] 1451 [ Tunnel-Server-Auth-Id ] 1452 [ Tunnel-Assignment-Id ] 1453 [ Tunnel-Password ] 1454 [ Tunnel-Private-Group-Id ] 1456 +---------------------+ 1457 | AVP Flag rules | 1458 |----+-----+----+-----|----+ 1459 AVP Section | | |SHLD| MUST|MAY | 1460 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 1461 -----------------------------------------|----+-----+----+-----|----| 1462 Tunneling 403 4.4 Grouped | M | P | | V | N | 1463 Tunnel-Type 64 4.4.1 Enumerated | M | P | | V | Y | 1464 Tunnel-Medium- 65 4.4.2 Enumerated | M | P | | V | Y | 1465 Type | | | | | | 1466 Tunnel-Client- 66 4.4.3 UTF8String | M | P | | V | Y | 1467 Endpoint | | | | | | 1468 Tunnel-Server- 67 4.4.4 UTF8String | M | P | | V | Y | 1469 Endpoint | | | | | | 1470 Tunnel-Password 69 4.4.5 OctetString| M | P | | V | Y | 1471 Tunnel-Private- 81 4.4.6 UTF8String | M | P | | V | Y | 1472 Group-Id | | | | | | 1473 Tunnel- 82 4.4.7 OctetString| M | P | | V | Y | 1474 Assignment-Id | | | | | | 1475 Tunnel-Preference 83 4.4.8 Unsigned32 | M | P | | V | Y | 1476 Tunnel-Client- 90 4.4.9 Unsigned32 | M | P | | V | Y | 1477 Auth-Id | | | | | | 1478 Tunnel-Server- 91 4.4.10 OctetString| M | P | | V | Y | 1479 Auth-Id | | | | | | 1480 -----------------------------------------|----+-----+----+-----|----| 1482 4.4.1. Tunnel-Type AVP 1484 The Tunnel-Type AVP (AVP Code 64) is of type Enumerated and contains 1485 the tunneling protocol(s) to be used (in the case of a tunnel 1486 initiator) or the tunneling protocol in use (in the case of a tunnel 1487 terminator). It MAY be used in an authorization request as a hint to 1488 the server that a specific tunnel type is desired, but the server is 1489 not required to honor the hint in the corresponding response. 1491 The Tunnel-Type AVP SHOULD also be included in Accounting-Request 1492 messages. 1494 A tunnel initiator is not required to implement any of these tunnel 1495 types; if a tunnel initiator receives a response that contains only 1496 unknown or unsupported Tunnel-Types, the tunnel initiator MUST behave 1497 as though a response was received with the Result-Code indicating a 1498 failure. 1500 The supported values are listed in [RADTYPE]. 1502 4.4.2. Tunnel-Medium-Type AVP 1504 The Tunnel-Medium-Type AVP (AVP Code 65) is of type Enumerated and 1505 contains the transport medium to use when creating a tunnel for those 1506 protocols (such as L2TP) that can operate over multiple transports. 1507 It MAY be used in an authorization request as a hint to the server 1508 that a specific medium is desired, but the server is not required to 1509 honor the hint in the corresponding response. 1511 The Value field contains one of the values listed under "Address 1512 Family Numbers" in [IANA]. The value of most importance is (1) for 1513 IPv4 and (2) for IPv6. 1515 4.4.3. Tunnel-Client-Endpoint AVP 1517 The Tunnel-Client-Endpoint AVP (AVP Code 66) is of type UTF8String, 1518 and contains the address of the initiator end of the tunnel. It MAY 1519 be used in an authorization request as a hint to the server that a 1520 specific endpoint is desired, but the server is not required to honor 1521 the hint in the corresponding response. 1523 This AVP SHOULD be included in the corresponding Accounting-Request 1524 messages, in which case it indicates the address from which the 1525 tunnel was initiated. This AVP, along with the Tunnel-Server-Endpoint 1526 and Session-Id AVP [BASE], MAY be used to provide a globally unique 1527 means to identify a tunnel for accounting and auditing purposes. 1529 If Tunnel-Medium-Type is IPv4 (1), then this string is either the 1530 fully qualified domain name (FQDN) of the tunnel client machine, or 1531 it is a "dotted-decimal" IP address. Conformant implementations MUST 1532 support the dotted-decimal format and SHOULD support the FQDN format 1533 for IP addresses. 1535 If Tunnel-Medium-Type is IPv6 (2), then this string is either the 1536 FQDN of the tunnel client machine, or it is a text representation of 1537 the address in either the preferred or alternate form [IPV6ADDR]. 1538 Conformant implementations MUST support the preferred form and SHOULD 1539 support both the alternate text form and the FQDN format for IPv6 1540 addresses. 1542 If Tunnel-Medium-Type is neither IPv4 nor IPv6, this string is a tag 1543 referring to configuration data local to the Diameter client that 1544 describes the interface and medium-specific address to use. 1546 4.4.4. Tunnel-Server-Endpoint AVP 1548 The Tunnel-Server-Endpoint AVP (AVP Code 67) is of UTF8String, and 1549 contains the address of the server end of the tunnel. It MAY be used 1550 in an authorization request as a hint to the server that a specific 1551 endpoint is desired, but the server is not required to honor the hint 1552 in the corresponding response. 1554 This AVP SHOULD be included in the corresponding Accounting-Request 1555 messages, in which case it indicates the address from which the 1556 tunnel was initiated. This AVP, along with the Tunnel-Client-Endpoint 1557 and Session-Id AVP [BASE], MAY be used to provide a globally unique 1558 means to identify a tunnel for accounting and auditing purposes. 1560 If Tunnel-Medium-Type is IPv4 (1), then this string is either the 1561 fully qualified domain name (FQDN) of the tunnel client machine, or 1562 it is a "dotted-decimal" IP address. Conformant implementations MUST 1563 support the dotted-decimal format and SHOULD support the FQDN format 1564 for IP addresses. 1566 If Tunnel-Medium-Type is IPv6 (2), then this string is either the 1567 FQDN of the tunnel client machine, or it is a text representation of 1568 the address in either the preferred or alternate form [IPV6ADDR]. 1569 Conformant implementations MUST support the preferred form and SHOULD 1570 support both the alternate text form and the FQDN format for IPv6 1571 addresses. 1573 If Tunnel-Medium-Type is not IPv4 or IPv6, this string is a tag 1574 referring to configuration data local to the Diameter client that 1575 describes the interface and medium-specific address to use. 1577 4.4.5. Tunnel-Password AVP 1579 The Tunnel-Password AVP (AVP Code 69) is of type OctetString and may 1580 contain a password to be used to authenticate to a remote server. 1581 The Tunnel-Password AVP contains sensitive information. As required 1582 in [BASE], Diameter messages are encrypted using IPsec or TLS. The 1583 Tunnel-Password AVP SHOULD NOT be used in untrusted proxy 1584 environments without encrypting it using end-to-end security 1585 techniques, such as CMS Security [DiamSEC]. 1587 4.4.6. Tunnel-Private-Group-Id AVP 1589 The Tunnel-Private-Group-Id AVP (AVP Code 81) is of type UTF8String, 1590 and contains the group Id for a particular tunneled session. The 1591 Tunnel-Private-Group-Id AVP MAY be included in an authorization 1592 request if the tunnel initiator can pre-determine the group resulting 1593 from a particular connection and SHOULD be included in the 1594 authorization response if this tunnel session is to be treated as 1595 belonging to a particular private group. Private groups may be used 1596 to associate a tunneled session with a particular group of users. 1597 For example, it MAY be used to facilitate routing of unregistered IP 1598 addresses through a particular interface. This AVP SHOULD be 1599 included in the Accounting-Request messages which pertain to the 1600 tunneled session. 1602 4.4.7. Tunnel-Assignment-Id AVP 1604 The Tunnel-Assignment-Id AVP (AVP Code 82) is of type OctetString and 1605 is used to indicate to the tunnel initiator the particular tunnel to 1606 which a session is to be assigned. Some tunneling protocols, such as 1607 PPTP [PPTP] and L2TP [L2TP], allow for sessions between the same two 1608 tunnel endpoints to be multiplexed over the same tunnel and also for 1609 a given session to utilize its own dedicated tunnel. This attribute 1610 provides a mechanism for Diameter to be used to inform the tunnel 1611 initiator (e.g. PAC, LAC) whether to assign the session to a 1612 multiplexed tunnel or to a separate tunnel. Furthermore, it allows 1613 for sessions sharing multiplexed tunnels to be assigned to different 1614 multiplexed tunnels. 1616 A particular tunneling implementation may assign differing 1617 characteristics to particular tunnels. For example, different 1618 tunnels may be assigned different QOS parameters. Such tunnels may 1619 be used to carry either individual or multiple sessions. The Tunnel- 1620 Assignment-Id attribute thus allows the Diameter server to indicate 1621 that a particular session is to be assigned to a tunnel that provides 1622 an appropriate level of service. It is expected that any QOS-related 1623 Diameter tunneling attributes defined in the future that accompany 1624 this attribute will be associated by the tunnel initiator with the Id 1625 given by this attribute. In the meantime, any semantic given to a 1626 particular Id string is a matter left to local configuration in the 1627 tunnel initiator. 1629 The Tunnel-Assignment-Id AVP is of significance only to Diameter and 1630 the tunnel initiator. The Id it specifies is intended to be of only 1631 local use to Diameter and the tunnel initiator. The Id assigned by 1632 the tunnel initiator is not conveyed to the tunnel peer. 1634 This attribute MAY be included in authorization responses. The tunnel 1635 initiator receiving this attribute MAY choose to ignore it and assign 1636 the session to an arbitrary multiplexed or non-multiplexed tunnel 1637 between the desired endpoints. This AVP SHOULD also be included in 1638 the Accounting-Request messages which pertain to the tunneled 1639 session. 1641 If a tunnel initiator supports the Tunnel-Assignment-Id AVP, then it 1642 should assign a session to a tunnel in the following manner: 1644 - If this AVP is present and a tunnel exists between the specified 1645 endpoints with the specified Id, then the session should be 1646 assigned to that tunnel. 1648 - If this AVP is present and no tunnel exists between the 1649 specified endpoints with the specified Id, then a new tunnel 1650 should be established for the session and the specified Id 1651 should be associated with the new tunnel. 1653 - If this AVP is not present, then the session is assigned to an 1654 unnamed tunnel. If an unnamed tunnel does not yet exist between 1655 the specified endpoints then it is established and used for this 1656 and subsequent sessions established without the Tunnel- 1657 Assignment-Id attribute. A tunnel initiator MUST NOT assign a 1658 session for which a Tunnel-Assignment-Id AVP was not specified 1659 to a named tunnel (i.e. one that was initiated by a session 1660 specifying this AVP). 1662 Note that the same Id may be used to name different tunnels if such 1663 tunnels are between different endpoints. 1665 4.4.8. Tunnel-Preference AVP 1667 The Tunnel-Preference AVP (AVP Code 83) is of type Unsigned32 and is 1668 used to identify the relative preference assigned to each tunnel when 1669 more than one set of tunneling AVPs is returned within separate 1670 Grouped-AVP AVPs. It MAY be used in an authorization request as a 1671 hint to the server that a specific preference is desired, but the 1672 server is not required to honor the hint in the corresponding 1673 response. 1675 For example, suppose that AVPs describing two tunnels are returned by 1676 the server, one with a Tunnel-Type of PPTP and the other with a 1677 Tunnel-Type of L2TP. If the tunnel initiator supports only one of 1678 the Tunnel-Types returned, it will initiate a tunnel of that type. 1679 If, however, it supports both tunnel protocols, it SHOULD use the 1680 value of the Tunnel-Preference AVP to decide which tunnel should be 1681 started. The tunnel having the numerically lowest value in the Value 1682 field of this AVP SHOULD be given the highest preference. The values 1683 assigned to two or more instances of the Tunnel-Preference AVP within 1684 a given authorization response MAY be identical. In this case, the 1685 tunnel initiator SHOULD use locally configured metrics to decide 1686 which set of AVPs to use. 1688 4.4.9. Tunnel-Client-Auth-Id AVP 1690 The Tunnel-Client-Auth-Id AVP (AVP Code 90) is of type Unsigned32 and 1691 specifies the name used by the tunnel initiator during the 1692 authentication phase of tunnel establishment. It MAY be used in an 1693 authorization request as a hint to the server that a specific 1694 preference is desired, but the server is not required to honor the 1695 hint in the corresponding response. This AVP MUST be present in the 1696 authorization response if an authentication name other than the 1697 default is desired. This AVP SHOULD be included in the Accounting- 1698 Request messages which pertain to the tunneled session. 1700 4.4.10. Tunnel-Server-Auth-Id AVP 1702 The Tunnel-Server-Auth-Id AVP (AVP Code 91) is of type OctetString 1703 and specifies the name used by the tunnel terminator during the 1704 authentication phase of tunnel establishment. It MAY be used in an 1705 authorization request as a hint to the server that a specific 1706 preference is desired, but the server is not required to honor the 1707 hint in the corresponding response. This AVP MUST be present in the 1708 authorization response if an authentication name other than the 1709 default is desired. This AVP SHOULD be included in the the 1710 Accounting-Request messages which pertain to the tunneled session. 1712 5. Accounting 1714 Applications implementing this specification use Diameter Accounting 1715 as defined in the Base [BASE] with the addition of the AVPs in the 1716 following section. 1718 Accounting Request messages (ACR) SHOULD be sent after any 1719 Authentication or Authorization transaction or the end of a Session. 1720 The Accounting-Record-Type value indicates the type of event. All 1721 other AVPs identify the session and provide additional information 1722 relevant to the event. 1724 The following table describes the AVPs, their AVP Code values, types, 1725 possible flag values and whether the AVP MAY be encrypted. 1727 +---------------------+ 1728 | AVP Flag rules | 1729 |----+-----+----+-----|----+ 1730 AVP Section | | |SHLD| MUST|MAY | 1731 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 1732 -----------------------------------------|----+-----+----+-----|----| 1733 Accounting- 363 5.1 Unsigned64 | M | P | | V | Y | 1734 Input-Octets | | | | | | 1735 Accounting- 364 5.2 Unsigned64 | M | P | | V | Y | 1736 Output-Octets | | | | | | 1737 Accounting- 365 5.3 Unsigned64 | M | P | | V | Y | 1738 Input-Packets | | | | | | 1739 Accounting- 366 5.4 Unsigned64 | M | P | | V | Y | 1740 Output-Packets | | | | | | 1741 Acct-Session-Time 46 5.5 Unsigned32 | M | P | | V | Y | 1742 Acct-Authentic 45 5.6 Unsigned32 | M | P | | V | Y | 1743 Acct-Delay-Time 41 5.7 Unsigned32 | M | P | | V | Y | 1744 Acct-Link-Count 51 5.8 Unsigned32 | M | P | | V | Y | 1745 Acct-Tunnel- 68 5.9 OctetString| M | P | | V | Y | 1746 Connection | | | | | | 1747 Acct-Tunnel- 86 5.10 Unsigned32 | M | P | | V | Y | 1748 Packets-Lost | | | | | | 1749 -----------------------------------------|----+-----+----+-----|----| 1751 5.1. Accounting-Input-Octets AVP 1753 The Accounting-Input-Octets AVP (AVP Code 363) is of type Unsigned64, 1754 and contains the number of octets received from the user. 1756 For NASREQ usage, this AVP indicates how many octets have been 1757 received from the port in the course of this session and can only be 1758 present in ACR messages with an Accounting-Record-Type of 1759 INTERIM_RECORD or STOP_RECORD. 1761 5.2. Accounting-Output-Octets AVP 1763 The Accounting-Output-Octets AVP (AVP Code 364) is of type 1764 Unsigned64, and contains the number of octets sent to the user. 1766 For NASREQ usage, this AVP indicates how many octets have been sent 1767 to the port in the course of this session and can only be present in 1768 ACR messages with an Accounting-Record-Type of INTERIM_RECORD or 1769 STOP_RECORD. 1771 5.3. Accounting-Input-Packets AVP 1773 The Accounting-Input-Packets (AVP Code 365) is of type Unsigned64, 1774 and contains the number of packets received from the user. 1776 For NASREQ usage, this AVP indicates how many packets have been 1777 received from the port over the course of a session being provided to 1778 a Framed User and can only be present in ACR messages with an 1779 Accounting-Record-Type of INTERIM_RECORD or STOP_RECORD. 1781 5.4. Accounting-Output-Packets AVP 1783 The Accounting-Output-Packets (AVP Code 366) is of type Unsigned64, 1784 and contains the number of IP packets sent to the user. 1786 For NASREQ usage, this AVP indicates how many packets have been sent 1787 to the port over the course of a session being provided to a Framed 1788 User and can only be present in ACR messages with an Accounting- 1789 Record-Type of INTERIM_RECORD or STOP_RECORD. 1791 5.5. Acct-Session-Time AVP 1793 The Acct-Session-Time AVP (AVP Code 46) is of type Unsigned32, and 1794 indicates the length of the current session in seconds. It can only 1795 be present in ACR messages with an Accounting-Record-Type of 1796 INTERIM_RECORD or STOP_RECORD. 1798 5.6. Acct-Authentic AVP 1800 The Acct-Authentic AVP (AVP Code 45) is of type Unsigned32, 1802 and specifies how the user was authenticated. The supported values 1803 are listed in [RADTYPE]. 1805 5.7. Acct-Delay-Time 1807 The Acct-Delay-Time AVP (AVP Code 41) is of type Unsigned32 and 1808 indicates the number of seconds during which the Diameter client has 1809 been trying to send the Accounting-Request (ACR) which contains it. 1810 The accounting server may subtract this value from the time the ACR 1811 arrives at the server to calculate the approximate time of the event 1812 that caused the ACR to be generated. 1814 This AVP is not used for retransmissions at the transport level (TCP 1815 or SCTP). Rather, it may be used when an ACR command cannot be 1816 transmitted because there is no appropriate peer to transmit it to or 1817 was rejected because it could not be delivered to its destination. 1818 In these cases, the command MAY be buffered and transmitted some time 1819 later when an appropriate peer-connection is available or after 1820 sufficient time has passed that the destination-host may be reachable 1821 and operational. If the ACR is resent in this way the Acct-Delay- 1822 Time AVP SHOULD be included. The value of this AVP indicates the 1823 number of seconds that elapsed between the time of the first attempt 1824 at transmission and the current attempt at transmission. 1826 5.8. Acct-Link-Count 1828 The Acct-Link-Count AVP (AVP Code 51) is of type Unsigned32 and 1829 indicates the number of links which are known to have been in a given 1830 multilink session at the time the accounting record is generated. 1831 This AVP MAY be included in Accounting-Requests for any session which 1832 may be part of a multilink service. 1834 The Acct-Link-Count AVP may be used to make it easier for an 1835 accounting server to know when it has all the records for a given 1836 multilink service. When the number of Accounting-Requests received 1837 with Accounting-Record-Type = STOP_RECORD and the same Acct-Multi- 1838 Session-Id and unique Session-Id's equals the largest value of Acct- 1839 Link-Count seen in those Accounting-Requests, all STOP_RECORD 1840 Accounting-Requests for that multilink service have been received. 1842 The following example showing eight Accounting-Requests illustrates 1843 how the Acct-Link-Count AVP is used. In the table below, only the 1844 relevant AVPs are shown although additional AVPs containing 1845 accounting information will also be present in the Accounting- 1846 Requests. 1848 Acct-Multi- Accounting- Acct- 1849 Session-Id Session-Id Record-Type Link-Count 1850 -------------------------------------------------------- 1851 "...10" "...10" START_RECORD 1 1852 "...10" "...11" START_RECORD 2 1853 "...10" "...11" STOP_RECORD 2 1854 "...10" "...12" START_RECORD 3 1855 "...10" "...13" START_RECORD 4 1856 "...10" "...12" STOP_RECORD 4 1857 "...10" "...13" STOP_RECORD 4 1858 "...10" "...10" STOP_RECORD 4 1860 5.9. Acct-Tunnel-Connection AVP 1862 The Acct-Tunnel-Connection AVP (AVP Code 68) is of type OctetString, 1863 and contains the identifier assigned to the tunnel session. This AVP, 1864 along with the Tunnel-Client-Endpoint and Tunnel-Server-Endpoint 1865 AVPs, may be used to provide a means to uniquely identify a tunnel 1866 session for auditing purposes. 1868 The format of the identifier in this AVP depends upon the value of 1869 the Tunnel-Type AVP. For example, to fully identify an L2TP tunnel 1870 connection, the L2TP Tunnel Id and Call Id might be encoded in this 1871 field. The exact encoding of this field is implementation dependent. 1873 5.10. Acct-Tunnel-Packets-Lost AVP 1874 The Acct-Tunnel-Packets-Lost AVP (AVP Code 86) is of type Unsigned32 1875 and contains the number of packets lost on a given link. 1877 6. RADIUS/Diameter Protocol Interactions 1879 This section describes some basic guidelines that may be used by 1880 servers that act as Translation Agents. Complete description of the 1881 differences between RADIUS and Diameter is beyond the scope of this 1882 document and section. Note that this document does not restrict 1883 implementations from creating other methods, as long as the bridging 1884 function doesn't break the RADIUS nor the Diameter protocol. 1886 +---------------------+ 1887 | AVP Flag rules | 1888 |----+-----+----+-----|----+ 1889 AVP Section | | |SHLD| MUST|MAY | 1890 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 1891 -----------------------------------------|----+-----+----+-----|----| 1892 NAS-Identifier 32 6.2.3 UTF8String | M | P | | V | Y | 1893 NAS-IP-Address 4 6.2.1 IPAddress | M | P | | V | Y | 1894 NAS-IPv6-Address 95 6.2.2 IPAddress | M | P | | V | Y | 1895 State 24 6.2.4 OctetString| M | P | | V | Y | 1896 Termination- 295 6.2.5 Enumerated | M | P | | V | Y | 1897 Cause | | | | | | 1898 -----------------------------------------|----+-----+----+-----|----| 1900 There are primarily two different situations that must be handled; one 1901 where a RADIUS request is received that must be forwarded as a Diameter 1902 request, and the inverse. RADIUS does not support a peer-to-peer 1903 architecture and server initiated operations are generally not supported. 1904 See [RADDYNAUTH] for an alternative. 1906 Note that this section uses the two terms; AVP and attribute in a consise 1907 manner. The former is used to signify a Diameter AVP, while the 1908 latter is used to signify a RADIUS attribute. 1910 6.1. RADIUS Request Forwarded as Diameter Request 1912 This section describes the actions that should be followed when a 1913 Translation Agent receives a RADIUS message that is to be translated 1914 to a Diameter message. 1916 It is important to note that RADIUS servers are assumed to be 1917 stateless, and this section maintains that assumption. It is also 1918 quite possible for the RADIUS messages that comprise the session 1919 (i.e. authentication and accounting messages) will be handled by 1920 different Translation Agents in the proxy network. Therefore, a 1921 RADIUS/Diameter Translation Agent SHOULD NOT assume to track session 1922 state information. 1924 When a Translation Agent receives a RADIUS message, the following 1925 steps should be taken: 1927 - If a Message-Authenticator attribute is present, it should be 1928 checked and discarded. The gateway system SHOULD generate and 1929 include a Message-Authenticator in return responses to this 1930 system. 1931 - The Diameter Origin-Host and Origin-Realm AVPs MUST be created 1932 and added using the information from the NAS-Identifier 1933 attribute, and/or the FQDN corresponding to the NAS-IP-Address 1934 attribute. The AAA protocol specified in the identity would be 1935 set to "RADIUS". 1936 - The Proxy-Info group SHOULD be added with the local server's 1937 identity being specified in the Proxy-Host AVP. This should 1938 ensure that the response is returned to this system. 1939 - The Destination-Realm AVP is created from the information found 1940 in the RADIUS User-Name attribute. 1941 - The Translation Agent must maintain transaction state 1942 information relevant to the RADIUS request, such as the 1943 Identifier field in the RADIUS header, any existing RADIUS 1944 Proxy-State attribute as well as the source IP address and port 1945 number of the UDP packet. These may be maintained locally in a 1946 state table, or may be saved in a Proxy-Info AVP. 1947 - If the RADIUS request contained a State attribute, and the 1948 prefix of the data is "Diameter/", the data following the prefix 1949 contains the Diameter Session-Id. If no such attributes are 1950 present, and the RADIUS command is an Access-Request, a new 1951 Session-Id is created. The Session-Id is included in the 1952 Session-Id AVP. 1953 - If the RADIUS CHAP-Password attribute is present, the Ident and 1954 Data portion of the attribute are used to create the CHAP-Auth 1955 grouped AVP. 1956 - If the RADIUS message contains Tunnel information [RADTunnels], 1957 the attributes or tagged groups should each be converted to a 1958 Diameter Tunneling Grouped AVP set. 1959 - If the RADIUS message received is an Accounting-Request, the 1960 Acct-Status-Type attribute value must be converted to a 1961 Accounting-Record-Type AVP value. If the Acct-Status-Type 1962 attribute value is STOP, the local server MUST issue a Session- 1963 Termination-Request message once the Diameter Accounting-Answer 1964 message has been received. 1965 If the Accounting message contains a Acct-Termination-Cause 1966 attribute, it should be translated to the equivalent 1967 Termination-Cause AVP value. (see below) 1968 - If the RADIUS message contains the Accounting-Input-Octets, 1969 Accounting-Input-Packets, Accounting-Output-Octets or 1970 Accounting-Output-Packets, these attributes must be converted to 1971 the Diameter equivalent ones. Further, if the Acct-Input- 1972 Gigawords or Acct-Output-Gigawords attributes are present, these 1973 must be used to properly compute the Diameter accounting AVPs. 1974 The corresponding Diameter response is always guaranteed to be 1975 received by the same Translation Agent that translated the original 1976 request, due to the contents of the Origin-Host AVP in the Diameter 1977 request. The following steps are applied to the response message 1978 during the Diameter to RADIUS translation: 1980 - If the Diameter Command-Code is set to AA-Answer and the Result- 1981 Code AVP is set to DIAMETER_MULTI_ROUND_AUTH, the gateway must 1982 send a RADIUS Access-Challenge with the Diameter Session-Id and 1983 the Origin-Host AVPs encapsulated in the RADIUS State attribute, 1984 with the prefix "Diameter/". This is necessary in order to 1985 ensure that the Translation Agent that will receive the 1986 subsequent RADIUS Access-Request will have access to the Session 1987 Identifier, and be able to set the Destination-Host to the 1988 correct value. If the Multi-Round-Time-Out AVP is present, the 1989 value of the AVP MUST be inserted in the RADIUS Session-Timeout 1990 AVP. 1991 - If the Command-Code is set to AA-Answer, the Diameter Session-Id 1992 AVP is saved in a new RADIUS Class attribute, whose format 1993 consists of the string "Diameter/" followed by the Diameter 1994 Session Identifier. This will ensure that the subsequent 1995 Accounting messages, which could be received by any Translation 1996 Agent, would have access to the original Diameter Session 1997 Identifier. 1998 - If a Proxy-State attribute was present in the RADIUS request, 1999 the same attribute is added in the response. This information 2000 may be found in the Proxy-Info AVP, or in a local state table. 2001 - If state information regarding the RADIUS request was saved in a 2002 Proxy-Info AVP or local state table, the RADIUS Identifier and 2003 UDP IP Address and port number are extracted and used in issuing 2004 the RADIUS reply. 2006 6.1.1. Diameter Request Forwarded as RADIUS Request 2008 When a server receives a Diameter request that is to be forwarded to 2009 a RADIUS entity, the following steps are an example of the steps that 2010 may be followed: 2012 - The Origin-Host AVP's value is inserted in the NAS-Identifier 2013 attribute. 2014 - The following information MUST be present in the corresponding 2015 Diameter response, and therefore MUST be saved either in a local 2016 state table, or it MAY be encoded in a RADIUS Proxy-State 2017 attribute: 2018 1. Origin-Host AVP 2019 2. Session-Id AVP 2020 3. Proxy-Info AVP 2021 4. Route-Record AVPs (in the proper order) 2022 5. Any other AVP that MUST be present in the response, and 2023 has no corresponding RADIUS attribute. 2024 - If the CHAP-Auth AVP is present, the grouped AVPs are used 2025 to create the RADIUS CHAP-Password attribute data. 2026 - If the Accounting-Input-Octets, Accounting-Input-Packets, 2027 Accounting-Output-Octets or Accounting-Output-Packets AVPs 2028 are present, these must be translated to the corresponding 2029 RADIUS attributes. Further, the value of the Diameter 2030 AVPs do not fit within a 32-bit RADIUS attribute, the 2031 RADIUS Acct-Input-Gigawords and Acct-Output-Gigawords must 2032 be used. 2034 When the corresponding response is received by the Translation Agent, 2035 which is guaranteed in the RADIUS protocol, the following steps may 2036 be followed: 2038 - If the RADIUS code is set to Access-Challenge, a Diameter AA- 2039 Answer message is created with the Result-Code set to 2040 DIAMETER_MULTI_ROUND_AUTH. If the Session-Timeout AVP is present 2041 in the RADIUS message, its value is inserted in the Multi-Round- 2042 Time-Out AVP. 2043 - If a Proxy-Info AVP is present, extract the encoded information, 2044 otherwise retrieve the information from the local state table. 2045 - The request's Origin-Host information is added to the 2046 Destination-Host AVP. 2047 - The Acct-Session-Id information is added to the Session-Id AVP. 2048 - The Route-Record AVPs MUST be added to the Diameter message, in 2049 the same order they were present in the request. 2050 - If a Proxy-Info AVP was present in the request, the same AVP 2051 MUST be added to the response. 2052 - If the RADIUS State attributes are present, these attributes 2053 must be present in the Diameter response. 2054 - Any other AVPs that were saved, and MUST be present in the 2055 response, are added to the message. 2057 6.2. RADIUS Attributes Used Only for Compatibility 2059 The AVPs defined in this section SHOULD only used for backwards 2060 compatibility when a Diameter/RADIUS translation function is invoked, 2061 and are not typically originated by Diameter systems. 2063 6.2.1. NAS-IP-Address AVP 2065 The NAS-IP-Address AVP (AVP Code 4) [RADIUS] is of type IPAddress, 2066 and contains the IPv4 Address of the NAS providing service to the 2067 user. This AVP SHOULD only be added by a RADIUS/Diameter Translation 2068 Agent. When this AVP is present, the Origin-Host AVP identifies the 2069 RADIUS/Diameter Translation Agent rather than the NAS providing 2070 service to the user. 2072 6.2.2. NAS-IPv6-Address AVP 2074 The NAS-IPv6-Address AVP (AVP Code 95) [RADIUSIPV6] is of type 2075 IPAddress, and contains the IPv6 Address of the NAS providing service 2076 to the user. This AVP SHOULD only be added by a RADIUS/Diameter 2077 Translation Agent. When this AVP is present, the Origin-Host AVP 2078 identifies the RADIUS/Diameter Translation Agent rather than the NAS 2079 providing service to the user. 2081 6.2.3. NAS-Identifier AVP 2083 The NAS-Identifier AVP (AVP Code 32) [RADIUS] is of type UTF8String 2084 and contains the identity of the NAS providing service to the user. 2085 This AVP SHOULD only be added by a RADIUS/Diameter Translation Agent. 2086 When this AVP is present, the Origin-Host AVP identifies the 2087 RADIUS/Diameter Translation Agent rather than the NAS providing 2088 service to the user. 2090 6.2.4. State AVP 2092 The State AVP (AVP Code 24) [RADIUS] is of type OctetString and has 2093 two uses in the Diameter NASREQ application. 2095 The State AVP MAY be sent by a Diameter Server to a NAS in an AA- 2096 Response command that contains a Result-Code of 2097 DIAMETER_MULTI_ROUND_AUTH. If so, the NAS MUST return it unmodified 2098 in the subsquent AA-Request command. 2100 The State AVP MAY also be sent by a Diameter Server to a NAS in an 2101 AA-Response command that also includes a Termination-Action AVP with 2102 the value of AA-REQUEST. If the NAS performs the Termination-Action 2103 by sending a new AA-Request command upon termination of the current 2104 service, it MUST return the State AVP unmodified in the new request 2105 command. 2107 In either usage the NAS MUST NOT interpret the AVP locally. Usage of 2108 the State AVP is implementation dependent. 2110 6.2.5. Termination-Cause AVP Code Values 2112 This section defines a mapping between Termination-Cause AVP code 2113 values and RADIUS Acct-Terminate-Cause attribute code values from RFC 2114 2866 [RADIUSACCT] and in www.iana.org, thereby allowing a 2115 RADIUS/Diameter Translation Agent to convert between the attribute 2116 and AVP values. This section thus extends the definitions in the 2117 "Termination-Cause AVP" section of the base Diameter specification. 2119 The table in this section defines the mapping between Termination- 2120 Cause AVP and RADIUS Acct-Terminate-Cause causes. 2121 +-----------------------+ 2122 | Code | 2123 +-----------+-----------+ 2124 Attribute Name | RADIUS | Diameter | 2125 ------------------------------|-----------+-----------+ 2126 User Request | 1 | 11 | 2127 Lost Carrier | 2 | 12 | 2128 Lost Service | 3 | 13 | 2129 Idle Timeout | 4 | 14 | 2130 Session Timeout | 5 | 15 | 2131 Admin Reset | 6 | 16 | 2132 Admin Reboot | 7 | 17 | 2133 Port Error | 8 | 18 | 2134 NAS Error | 9 | 19 | 2135 NAS Request | 10 | 20 | 2136 NAS Reboot | 11 | 21 | 2137 Port Unneeded | 12 | 22 | 2138 Port Preempted | 13 | 23 | 2139 Port Suspended | 14 | 24 | 2140 Service Unavailable | 15 | 25 | 2141 Callback | 16 | 26 | 2142 User Error | 17 | 27 | 2143 Host Request | 18 | 28 | 2144 Supplicant Restart | 19 | 29 | [Congdon] 2145 Reauthentication Failure | 20 | 30 | [Congdon] 2146 Port Reinit | 21 | 31 | [Congdon] 2147 Port Disabled | 22 | 32 | [Congdon] 2148 ------------------------------|-----------+-----------+ 2150 From RFC 2866, the termination causes are as follows: 2152 User Request User requested termination of service, for 2153 example with LCP Terminate or by logging out. 2155 Lost Carrier DCD was dropped on the port. 2157 Lost Service Service can no longer be provided; for 2158 example, user's connection to a host was 2159 interrupted. 2161 Idle Timeout Idle timer expired. 2163 Session Timeout Maximum session length timer expired. 2165 Admin Reset Administrator reset the port or session. 2167 Admin Reboot Administrator is ending service on the NAS, 2168 for example prior to rebooting the NAS. 2170 Port Error NAS detected an error on the port which 2171 required ending the session. 2173 NAS Error NAS detected some error (other than on the 2174 port) which required ending the session. 2176 NAS Request NAS ended session for a non-error reason not 2177 otherwise listed here. 2179 NAS Reboot The NAS ended the session in order to reboot 2180 non-administratively ("crash"). 2182 Port Unneeded NAS ended session because resource usage fell 2183 below low-water mark (for example, if a 2184 bandwidth-on-demand algorithm decided that 2185 the port was no longer needed). 2187 Port Preempted NAS ended session in order to allocate the 2188 port to a higher priority use. 2190 Port Suspended NAS ended session to suspend a virtual 2191 session. 2193 Service Unavailable NAS was unable to provide requested service. 2195 Callback NAS is terminating current session in order 2196 to perform callback for a new session. 2198 User Error Input from user is in error, causing 2199 termination of session. 2201 Host Request Login Host terminated session normally. 2203 6.3. RADIUS Attributes Not Allowed in Diameter Messages 2205 The following RADIUS attributes MUST NOT be transfered to a Diameter 2206 message Many of these are discussed in section 6.1. 2208 Attribute Description Defined Nearest Diameter AVP 2209 ----------------------------------------------------------------- 2210 3 CHAP-Password RFC 2865 CHAP-Auth Group 2211 26 Vendor-Specific RFC 2865 Vendor Specific AVP 2212 40 Acct-Status-Type RFC 2866 Accounting-Record-Type 2213 42 Acct-Input-Octets RFC 2866 Accounting-Input-Octets 2214 43 Acct-Output-Octets RFC 2866 Accounting-Output-Octets 2215 47 Acct-Input-Packets RFC 2866 Accounting-Input-Packets 2216 48 Acct-Output-Packets RFC 2866 Accounting-Output-Packets 2217 49 Acct-Terminate-Cause RFC 2866 Termination-Cause 2218 52 Acct-Input-Gigawords RFC 2869 Accounting-Input-Octets 2219 53 Acct-Output-Gigawords RFC 2869 Accounting-Output-Octets 2220 80 Message-Authenticator RFC 2869 none - check and discard 2222 6.4. Diameter AVPs that can be Translated to RADIUS Attributes 2224 In general, Diameter AVPs that are not RADIUS compatible have code 2225 values greater than 255. The table in the section above shows the 2226 AVPs that can be converted into RADIUS attributes. 2228 Another problem may occur with Diameter AVP values that may be more 2229 than 253 octets in length (eg: Reply-Message). Some RADIUS 2230 attributes allow concatenation of multiple instances to overcome this 2231 limitation. If this is not possible, an attribute error should be 2232 returned. 2234 6.5. RADIUS Vendor Specific Attributes 2236 RADIUS supports the inclusion of Vendor Specific Attributes (VSAs) 2237 through the use of attribute 26. The recommended format [RADIUS] of 2238 the attribute data field includes a 4 octet vendor code followed by a 2239 one octet vendor type field and a one octet length field. The last 2240 two fields MAY be repeated. 2242 6.5.1. Transmitting a Diameter Vendor AVP as a RADIUS VSA 2244 The RADIUS VSA attribute should consist of the following fields; 2246 RADIUS Type = 26, Vendor Specific Attribute 2247 RADIUS Length = total length of attribute (header + data) 2248 RADIUS Vendor code = Diameter Vendor code 2249 RADIUS Vendor type code = low order byte of Diameter AVP code 2250 RADIUS Vendor data length = length of Diameter data (not including padding) 2252 If the Diameter AVP code is greater than 255, then the RADIUS 2253 speaking code may use a Vendor specific field coding, if it knows one 2254 for that vendor. Otherwise, the AVP will be ignored. Unless it is 2255 flagged as Mandatory, in which case an "DIAMETER_AVP_UNSUPPORTED" 2256 error will be returned, and the message will not be sent. 2258 6.5.2. Forwarding a RADIUS VSA to a Diameter Vendor AVP 2260 The Diameter AVP will consist of the following fields; 2262 Diameter Flags: V=1, M=0, P=0 2263 Diameter Vendor code = RADIUS VSA Vendor code 2264 Diameter AVP code = RADIUS VSA Vendor type code (expanded with zeros) 2265 Diameter AVP length = length of AVP (header + data + padding) 2266 Diameter Data = RADIUS VSA vendor data 2268 If the RADIUS receiving code knows of vendor specific fields 2269 interpretations for the specific vendor, it may employ them to parse 2270 an extended AVP code or data length, Otherwise the recommended 2271 standard fields will be used. 2273 Nested Multiple vendor data fields MUST be expanded into multiple 2274 Diameter AVPs. 2276 7. AVP Occurrence Tables 2277 The following tables present the AVPs defined in this document, and 2278 specify in which Diameter messages they MAY, or MAY NOT be present. 2279 Note that AVPs that can only be present within a Grouped AVP are not 2280 represented in this table. 2282 The table uses the following symbols: 2283 0 The AVP MUST NOT be present in the message. 2284 0+ Zero or more instances of the AVP MAY be present in the 2285 message. 2286 0-1 Zero or one instance of the AVP MAY be present in the 2287 message. 2288 1 One instance of the AVP MUST be present in the message. 2290 7.1. AA-Request/Answer AVP Table 2292 The table in this section is limited to the Command Codes defined in 2293 this specification. 2295 +-----------+ 2296 | Command | 2297 |-----+-----+ 2298 Attribute Name | AAR | AAA | 2299 ------------------------------|-----+-----+ 2300 Acct-Interim-Interval | 0 | 0-1 | 2301 ARAP-Challenge-Response | 0 | 0-1 | 2302 ARAP-Features | 0 | 0-1 | 2303 ARAP-Password | 0-1 | 0 | 2304 ARAP-Security | 0-1 | 0-1 | 2305 ARAP-Security-Data | 0+ | 0+ | 2306 ARAP-Zone-Access | 0 | 0-1 | 2307 Auth-Application-Id | 1 | 1 | 2308 Auth-Grace-Period | 0-1 | 0-1 | 2309 Auth-Request-Type | 1 | 1 | 2310 Auth-Session-State | 0-1 | 0-1 | 2311 Authorization-Lifetime | 0-1 | 0-1 | 2312 Callback-Id | 0 | 0-1 | 2313 Callback-Number | 0-1 | 0-1 | 2314 Called-Station-Id | 0-1 | 0 | 2315 Calling-Station-Id | 0-1 | 0 | 2316 CHAP-Auth | 0-1 | 0 | 2317 CHAP-Challenge | 0-1 | 0 | 2318 Class | 0+ | 0+ | 2319 Configuration-Token | 0 | 0+ | 2320 Connect-Info | 0-1 | 0 | 2321 Destination-Host | 0-1 | 0 | 2322 Destination-Realm | 1 | 0 | 2323 Error-Message | 0 | 0-1 | 2324 Error-Reporting-Host | 0 | 0-1 | 2325 Failed-AVP | 0+ | 0+ | 2326 Filter-Id | 0 | 0+ | 2327 Framed-Appletalk-Link | 0 | 0-1 | 2328 Framed-Appletalk-Network | 0 | 0+ | 2329 Framed-Appletalk-Zone | 0 | 0-1 | 2330 Framed-Compression | 0+ | 0+ | 2331 Framed-Interface-Id | 0-1 | 0-1 | 2332 Framed-IP-Address | 0-1 | 0-1 | 2333 Framed-IP-Netmask | 0-1 | 0-1 | 2334 Framed-IPv6-Prefix | 0+ | 0+ | 2335 Framed-IPv6-Pool | 0 | 0-1 | 2336 Framed-IPv6-Route | 0 | 0+ | 2337 Framed-IPX-Network | 0 | 0-1 | 2338 Framed-MTU | 0-1 | 0-1 | 2339 Framed-Pool | 0 | 0-1 | 2340 Framed-Protocol | 0-1 | 0-1 | 2341 Framed-Route | 0 | 0+ | 2342 Framed-Routing | 0 | 0-1 | 2343 ------------------------------|-----+-----+ 2344 +-----------+ 2345 | Command | 2346 |-----+-----+ 2347 Attribute Name | AAR | AAA | 2348 ------------------------------|-----+-----+ 2349 Idle-Timeout | 0-1 | 0-1 | 2350 Login-IP-Host | 0+ | 0+ | 2351 Login-IPv6-Host | 0+ | 0+ | 2352 Login-LAT-Group | 0-1 | 0-1 | 2353 Login-LAT-Node | 0-1 | 0-1 | 2354 Login-LAT-Port | 0-1 | 0-1 | 2355 Login-LAT-Service | 0-1 | 0-1 | 2356 Login-Service | 0 | 0-1 | 2357 Login-TCP-Port | 0 | 0-1 | 2358 Multi-Round-Time-Out | 0 | 0-1 | 2359 NAS-Filter-Rule | 0 | 0+ | 2360 NAS-Identifier | 0-1 | 0 | 2361 NAS-IP-Address | 0-1 | 0 | 2362 NAS-IPv6-Address | 0-1 | 0 | 2363 NAS-Port | 0-1 | 0 | 2364 NAS-Port-Id | 0-1 | 0 | 2365 NAS-Port-Type | 0-1 | 0 | 2366 Originating-Line-Info | 0-1 | 0 | 2367 Origin-Host | 1 | 1 | 2368 Origin-Realm | 1 | 1 | 2369 Origin-State-Id | 0-1 | 0-1 | 2370 Password-Retry | 0 | 0-1 | 2371 Port-Limit | 0-1 | 0-1 | 2372 Prompt | 0 | 0-1 | 2373 Proxy-Info | 0+ | 0+ | 2374 Re-Auth-Request-Type | 0 | 0-1 | 2375 Redirect-Host | 0 | 0+ | 2376 Redirect-Host-Usage | 0 | 0-1 | 2377 Redirect-Max-Cache-Time | 0 | 0-1 | 2378 Reply-Message | 0 | 0+ | 2379 Result-Code | 0 | 1 | 2380 Route-Record | 0+ | 0 | 2381 Service-Type | 0-1 | 0-1 | 2382 Session-Id | 1 | 1 | 2383 Session-Timeout | 0-1 | 0-1 | 2384 State | 0-1 | 0-1 | 2385 Termination-Action | 0 | 0-1 | 2386 Termination-Cause | 0 | 0-1 | 2387 Tunneling | 0+ | 0+ | 2388 User-Name | 0-1 | 0-1 | 2389 User-Password | 0-1 | 0 | 2390 ------------------------------|-----+-----+ 2392 7.2. Accounting AVP Tables 2394 The tables in this section are used to represent which AVPs defined 2395 in this document are to be present in the Accounting messages, 2396 defined in [RADIUS]. 2398 7.2.1. Accounting Framed Access AVP Table 2400 The table in this section is used when the Service-Type specifies 2401 Framed Access. 2403 +-----------+ 2404 | Command | 2405 | Code | 2406 |-----+-----+ 2407 Attribute Name | ACR | ACA | 2408 ---------------------------------------|-----+-----+ 2409 Accounting-Application-Id | 0-1 | 0-1 | 2410 Accounting-Input-Octets | 1 | 0 | 2411 Accounting-Input-Packets | 1 | 0 | 2412 Accounting-Output-Octets | 1 | 0 | 2413 Accounting-Output-Packets | 1 | 0 | 2414 Accounting-Record-Type | 1 | 1 | 2415 Accounting-Record-Number | 0-1 | 0-1 | 2416 Accounting-Realtime-Required | 0-1 | 0 | 2417 Accounting-Sub-Session-Id | 0-1 | 0-1 | 2418 Acct-Application-Id | 0-1 | 0-1 | 2419 Acct-Session-Id | 0-1 | 0-1 | 2420 Acct-Multi-Session-Id | 0-1 | 0-1 | 2421 Acct-Authentic | 1 | 0 | 2422 Acct-Delay-Time | 0-1 | 0 | 2423 Acct-Interim-Interval | 0-1 | 0 | 2424 Acct-Link-Count | 0-1 | 0 | 2425 Acct-Session-Time | 1 | 0 | 2426 Acct-Tunnel-Connection | 0-1 | 0 | 2427 Acct-Tunnel-Packets-Lost | 0-1 | 0 | 2428 Event-Timestamp | 0-1 | 0-1 | 2429 Error-Reporting-Host | 0 | 0-1 | 2430 Framed-AppleTalk-Link | 0-1 | 0 | 2431 Framed-AppleTalk-Network | 0-1 | 0 | 2432 Framed-AppleTalk-Zone | 0-1 | 0 | 2433 Framed-Compression | 0-1 | 0 | 2434 Framed-IP-Address | 0-1 | 0 | 2435 Framed-IP-Netmask | 0-1 | 0 | 2436 Framed-IPv6-Pool | 0-1 | 0 | 2437 Framed-IPX-Network | 0-1 | 0 | 2438 Framed-MTU | 0-1 | 0 | 2439 Framed-Pool | 0-1 | 0 | 2440 Framed-Protocol | 0-1 | 0 | 2441 Framed-Route | 0-1 | 0 | 2442 Framed-Routing | 0-1 | 0 | 2443 NAS-Filter-Rule | 0-1 | 0 | 2444 NAS-Identifier | 0-1 | 0-1 | 2445 NAS-IP-Address | 0-1 | 0-1 | 2446 NAS-IPv6-Address | 0-1 | 0-1 | 2447 NAS-Port | 0-1 | 0-1 | 2448 NAS-Port-Id | 0-1 | 0-1 | 2449 NAS-Port-Type | 0-1 | 0-1 | 2450 Origin-Host | 1 | 1 | 2451 Origin-Realm | 1 | 1 | 2452 Origin-State-Id | 0-1 | 0-1 | 2453 Proxy-Info | 0+ | 0+ | 2454 Route-Record | 0+ | 0+ | 2455 Service-Type | 0-1 | 0-1 | 2456 State | 0 | 0 | 2457 Termination-Cause | 0-1 | 0-1 | 2458 Tunnel-Assignment-Id | 0-1 | 0 | 2459 Tunnel-Client-Endpoint | 0-1 | 0 | 2460 Tunnel-Medium-Type | 0-1 | 0 | 2461 Tunnel-Private-Group-Id | 0-1 | 0 | 2462 Tunnel-Server-Endpoint | 0-1 | 0 | 2463 Tunnel-Type | 0-1 | 0 | 2464 User-Name | 0-1 | 0-1 | 2465 Vendor-Specific-Application-Id | 0-1 | 0-1 | 2466 ---------------------------------------|-----+-----+ 2468 7.2.2. Accounting Non-Framed Access AVP Table 2470 The table in this section is used when the Service-Type specifies 2471 Non-Framed Access. 2473 +-----------+ 2474 | Command | 2475 | Code | 2476 |-----+-----+ 2477 Attribute Name | ACR | ACA | 2478 ---------------------------------------|-----+-----+ 2479 Accounting-Application-Id | 0-1 | 0-1 | 2480 Accounting-Input-Octets | 1 | 0 | 2481 Accounting-Input-Packets | 0 | 0 | 2482 Accounting-Output-Octets | 1 | 0 | 2483 Accounting-Output-Packets | 0 | 0 | 2484 Accounting-Record-Type | 1 | 1 | 2485 Accounting-Record-Number | 0-1 | 0-1 | 2486 Accounting-Realtime-Required | 0-1 | 0 | 2487 Accounting-Sub-Session-Id | 0-1 | 0-1 | 2488 Acct-Application-Id | 0-1 | 0-1 | 2489 Acct-Session-Id | 0-1 | 0-1 | 2490 Acct-Multi-Session-Id | 0-1 | 0-1 | 2491 Acct-Authentic | 1 | 0 | 2492 Acct-Delay-Time | 0-1 | 0 | 2493 Acct-Interim-Interval | 0-1 | 0 | 2494 Acct-Link-Count | 0-1 | 0 | 2495 Acct-Session-Time | 1 | 0 | 2496 Event-Timestamp | 0-1 | 0-1 | 2497 Error-Reporting-Host | 0 | 0-1 | 2498 Login-IP-Host | 0+ | 0 | 2499 Login-IPv6-Host | 0+ | 0 | 2500 Login-LAT-Service | 0-1 | 0 | 2501 Login-LAT-Node | 0-1 | 0 | 2502 Login-LAT-Group | 0-1 | 0 | 2503 Login-LAT-Port | 0-1 | 0 | 2504 Login-Service | 0-1 | 0 | 2505 Login-TCP-Port | 0-1 | 0 | 2506 NAS-Filter-Rule | 0 | 0 | 2507 NAS-Identifier | 0-1 | 0-1 | 2508 NAS-IP-Address | 0-1 | 0-1 | 2509 NAS-IPv6-Address | 0-1 | 0-1 | 2510 NAS-Port | 0-1 | 0-1 | 2511 NAS-Port-Id | 0-1 | 0-1 | 2512 NAS-Port-Type | 0-1 | 0-1 | 2513 Origin-Host | 1 | 1 | 2514 Origin-Realm | 1 | 1 | 2515 Origin-State-Id | 0-1 | 0-1 | 2516 Proxy-Info | 0+ | 0+ | 2517 Route-Record | 0+ | 0+ | 2518 Service-Type | 0-1 | 0-1 | 2519 State | 0 | 0 | 2520 Termination-Cause | 0-1 | 0-1 | 2521 User-Name | 0-1 | 0-1 | 2522 Vendor-Specific-Application-Id | 0-1 | 0-1 | 2523 ---------------------------------------|-----+-----+ 2525 8. IANA Considerations 2527 This section contains the namespaces that have either been created in 2528 this specification, or the values assigned to existing namespaces 2529 managed by IANA. 2531 8.1. Command Codes 2533 This specification assigns the values 265 and 268 from the Command 2534 Code namespace defined in [BASE]. See sections 3.1 and 3.2 for the 2535 assignment of the namespace in this specification. 2537 8.2. AVP Codes 2539 This specification assigns the values 363-366 and 400-414 from the 2540 AVP Code namespace defined in [BASE]. See sections 4, and 5 for the 2541 assignment of the namespace in this specification. Note that the 2542 values 363-366 are jointly, but consistently, assigned in [DiamMIP]. 2544 This specification also makes use of AVPs in the 0-255 range, which 2545 are defined in [RADTYPE]. 2547 8.3. Application Identifier 2549 This specification assigns the value one (1) to the Application 2550 Identifier namespace defined in [IANAConsid]. See section 1.2 for 2551 more information. 2553 8.4. CHAP-Algorithm AVP Values 2555 As defined in Section 4.2.6, the CHAP-Algorithm AVP (AVP Code 412) 2556 uses the values of the "PPP AUTHENTICATION ALGORITHMS" namespace 2557 defined in [PPPCHAP]. 2559 9. Security Considerations 2561 This document does not contain any security protocol, but does 2562 discuss how PPP authentication protocols can be carried within the 2563 Diameter protocol. The PPP authentication protocols that are 2564 described are PAP and CHAP. 2566 The use of PAP SHOULD be discouraged, since it exposes user's 2567 passwords to possibly non-trusted entities. PAP is also frequently 2568 used for use with One-Time Passwords (OTP), which does not expose any 2569 security risks. 2571 This document also describes how CHAP can be carried within the 2572 Diameter protocol, which is required for backward RADIUS 2573 compatibility. The CHAP protocol, as used in a RADIUS environment, 2574 facilitates authentication replay attacks. 2576 10. References 2578 10.1. Normative References 2580 [BASE] P. Calhoun, et.al, "Diameter Base Protocol", draft-ietf- 2581 aaa-diameter-15.txt, IETF work in progress, October 2002. 2583 [AAATrans] B. Aboba, J. Wood. "Authentication, Authorization and 2584 Accounting (AAA) Transport Profile", draft-ietf-aaa- 2585 transport-08, IETF work in progress, April 2002 2587 [RADTYPE] IANA, "RADIUS Types", URL: 2588 2590 [EAP] L. J. Blunk, J. R. Vollbrecht, "PPP Extensible 2591 Authentication Protocol (EAP)." RFC 2284, March 1998. 2593 [IPV6ADDR] Hinden, R., Deering, S., "IP Version 6 Addressing 2594 Architecture", RFC 2373, July 1998 2596 [PPPCHAP] W. Simpson, "PPP Challenge Handshake Authentication 2597 Protocol (CHAP)", RFC 1994, August 1996. 2599 [ISOLATIN] ISO 8859. International Standard -- Information Processing 2600 -- 8-bit Single-Byte Coded Graphic Character Sets -- Part 2601 1: Latin Alphabet No. 1, ISO 8859-1:1987. URL: 2602 2604 [IANA] IANA Assigned Numbers Database, URL: 2605 2607 [ANITYPES] NANPA Number Resource Info, ANI Assignments, URL: 2608 2611 [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate 2612 Requirement Levels", BCP 14, RFC 2119, March 1997. 2614 10.2. Informative References 2616 [RADIUS] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote 2617 Authentication Dial In User Service (RADIUS)", RFC 2865, 2618 June 2000. 2620 [RADIUSACCT] C. Rigney, "RADIUS Accounting", RFC 2866, June 2000. 2622 [RADIUSEXT] C. Rigney, W. Willats, P. Calhoun, "RADIUS Extensions", 2623 RFC 2869, June 2000. 2625 [NAI] B. Aboba, M. Beadles, "The Network Access Identifier." RFC 2626 2486. January 1999. 2628 [RADTunnels] G. Zorn, D. Leifer, A. Rubens, J. Shriver, M. Holdrege, I. 2629 Goyret, "RADIUS Attributes for Tunnel Protocol Support", 2630 RFC 2868, June 2000. 2632 [RADTUNLACCT] G. Zorn, B. Aboba, D. Mitton, "RADIUS Accounting 2633 Modifications for Tunnel Protocol Support", RFC 2867, June 2634 2000. 2636 [RADIUSIPV6] B. Aboba, G. Zorn, D. Mitton, "RADIUS and IPv6", RFC 3162, 2637 August 2001. 2639 [RADDYNAUTH] M. Chiba, M Dommety, M. Eklund, D. Mitton, B. Aboba, 2640 draft-chiba-radius-dynamic-authorization-05.txt", Work in 2641 Progress, Jan 2002 2643 [ROAMCRIT] B. Aboba, G. Zorn, "Criteria for Evaluating Roaming 2644 Protocols", RFC 2477, January 1999. 2646 [EXTRADPRAC] D. Mitton, "Network Access Servers Requirements: Extended 2647 RADIUS Practices", RFC 2882, July 2000. 2649 [NASMODEL] D. Mitton, M. Beadles, "Network Access Server Requirements 2650 Next Generation (NASREQNG) NAS Model", RFC 2881, July 2651 2000. 2653 [NASCRIT] M. Beadles, D. Mitton, "Criteria for Evaluating Network 2654 Access Server Protocols", RFC 3169, September 2001. 2656 [AAACRIT] Aboba, et al., "Criteria for Evaluating AAA Protocols for 2657 Network Access", RFC 2989, Nov 2000. 2659 [DiamEAP] G. Zorn, "Diameter EAP Application", draft-ietf-aaa- 2660 eap-01.txt, IETF work in progress, August 2002. 2662 [DiamCMS] P. Calhoun, W. Bulley, S. Farrell, "Diameter CMS Security 2663 Application", draft-ietf-aaa-diameter-cms-sec-04.txt, IETF 2664 work in progress, March 2002. 2666 [DiamMIP] P. Calhoun, C. Perkins, T. Johansson, "Diameter Mobile IP 2667 Application", draft-ietf-aaa-diameter-mobileip-13.txt, 2668 IETF work in progress, October 2002. 2670 [Congdon] P. Congdon, et.al "IEEE 802.1X RADIUS Usage Guidelines", 2671 draft-congdon-8021x-RADIUS-20.txt, IETF work in progress, 2672 June 2002. 2674 [802.1X] IEEE Standard for Local and metropolitan networks - Port- 2675 Based Network Access Control, IEEE Std 802.1X-2001, June 2676 2001 2678 [CDMA2000] 3GPP2 "P.S0001-A v3.0", Wireless IP Network Standard, July 2679 2001. 2680 http://www.3gpp2.com/Public_html/specs/P.S0001-A_v3.0.pdf 2682 [TCPCompress] Jacobson, "Compressing TCP/IP headers for low-speed serial 2683 links", RFC 1144, February 1990. 2685 [PPPMP] Sklower, Lloyd, McGregor, Carr, "The PPP Multilink 2686 Protocol (MP)", RFC 1717, November 1994. 2688 [PPTP] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, 2689 W., Zorn, G., "Point-to-Point Tunneling Protocol (PPTP)", 2690 RFC 2637, July 1999 2692 [L2F] Valencia, A., Littlewood, M., Kolar, T., "Cisco Layer Two 2693 Forwarding (Protocol) 'L2F'", RFC 2341, May 1998 2695 [L2TP] Townsley, W. M., Valencia, A., Rubens, A., Pall, G. S., 2696 Zorn, G., Palter, B., "Layer Two Tunneling Protocol 2697 (L2TP)", RFC 2661, August 1999 2699 [ATMP] Hamzeh, K., "Ascend Tunnel Management Protocol - ATMP", 2700 RFC 2107, February 1997 2702 [MSMPPE] G. Pall, G. Zorn, "Microsoft Point-To-Point Encryption 2703 (MPPE) Protocol", RFC 3078, March 2001. 2705 [UTF-8] F. Yergeau, "UTF-8, a transformation format of ISO 10646", 2706 RFC 2279, January 1998. 2708 [STD51] W. Simpson, Editor, "The Point-to-Point Protocol (PPP)", 2709 STD 51, RFC 1661, July 1994 2711 [IANAConsid] Narten, Alvestrand, "Guidelines for Writing an IANA 2712 Considerations Section in RFCs", BCP 26, RFC 2434, October 2713 1998 2715 Acknowledgements 2717 The authors would like to thank Carl Rigney, Allan C. Rubens, William 2718 Allen Simpson, and Steve Willens for their work on the original 2719 RADIUS [RADIUS], from which many of the concepts in this 2720 specification were derived. Thanks, also, to: Carl Rigney for 2721 [RADIUSACCT] and [RADIUSEXT]; Ward Willats for [RADIUSEXT]; Glen 2722 Zorn, Bernard Aboba and Dave Mitton for [RADTUNLACCT] and [RADIPV6]; 2723 Dory Leifer, John Shriver, Matt Holdrege and Ignacio Goyret for their 2724 work on [RADTUNNELS]. This document stole text and concepts from both 2725 [RADTUNNELS] and [RADIUSEXT]. Thanks go to Carl Williams for 2726 providing IPv6 specific text. 2728 The authors would also like to acknowledge the following people for 2729 their contributions in the development of the Diameter protocol: 2730 Bernard Aboba, Jari Arkko, William Bulley, Daniel C. Fox, Lol Grant, 2731 Nancy Greene, Jeff Hagg, Peter Heitman, Paul Krumviede, Fergal 2732 Ladley, Ryan Moats, Victor Muslin, Kenneth Peirce, Sumit Vakil, John 2733 R. Vollbrecht and Jeff Weisberg. 2735 Finally, Pat Calhoun would like to thank Sun Microsystems since most 2736 of the effort put into this document was done while he was in their 2737 employ. 2739 Authors' Addresses 2741 Questions about this memo can be directed to: 2743 Pat R. Calhoun 2744 Black Storm Networks 2745 250 Cambridge Avenue, Suite 200 2746 Palo Alto, California, 94306 2747 USA 2749 Phone: 1 650-617-2932 2750 Fax: 1 650-786-6445 2751 E-mail: pcalhoun@diameter.org 2753 Glen Zorn 2754 Cisco Systems, Inc. 2755 500 108th Avenue N.E., Suite 500 2756 Bellevue, WA 98004 2757 USA 2759 Phone: 1 425-471-4861 2760 E-Mail: gwz@cisco.com 2762 David Spence 2763 Interlink Networks, Inc. 2764 775 Technology Drive, Suite 200 2765 Ann Arbor, MI 48108 2766 USA 2768 Phone: 1 734-821-1203 2769 Fax: 1 734-821-1235 2770 EMail: dspence@interlinknetworks.com 2772 David Mitton 2773 Circular Logic Unlimited 2774 733 Turnpike St #154 2775 North Andover, MA 01845 2777 Email: david@mitton.com 2779 Full Copyright Statement 2781 Copyright (C) The Internet Society (2002). All Rights Reserved. 2783 This document and translations of it may be copied and furnished to 2784 others, and derivative works that comment on or otherwise explain it 2785 or assist in its implementation may be prepared, copied, published 2786 and distributed, in whole or in part, without restriction of any 2787 kind, provided that the above copyright notice and this paragraph are 2788 included on all such copies and derivative works. However, this 2789 document itself may not be modified in any way, such as by removing 2790 the copyright notice or references to the Internet Society or other 2791 Internet organizations, except as needed for the purpose of 2792 developing Internet standards in which case the procedures for 2793 copyrights defined in the Internet Standards process must be 2794 followed, or as required to translate it into languages other than 2795 English. The limited permissions granted above are perpetual and will 2796 not be revoked by the Internet Society or its successors or assigns. 2797 This document and the information contained herein is provided on an 2798 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2799 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2800 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2801 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2802 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.