idnits 2.17.1 draft-ietf-aaa-diameter-nasreq-04.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 56 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 57 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 25 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 == Line 553 has weird spacing: '... of the conte...' == 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: The following tables presents the AVPs defined in this document, and specifies 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 (May 2001) is 8353 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) == Unused Reference: '3' is defined on line 2307, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 2319, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 2333, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 2343, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 2347, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 2354, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 2357, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 2360, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 2363, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 2366, but no explicit reference was found in the text == Unused Reference: '22' is defined on line 2369, but no explicit reference was found in the text == Unused Reference: '23' is defined on line 2372, but no explicit reference was found in the text == Unused Reference: '28' is defined on line 2388, but no explicit reference was found in the text == Unused Reference: '35' is defined on line 2411, but no explicit reference was found in the text == Unused Reference: '36' is defined on line 2413, but no explicit reference was found in the text == Unused Reference: '37' is defined on line 2416, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-aaa-diameter-04 ** Obsolete normative reference: RFC 2486 (ref. '3') (Obsoleted by RFC 4282) ** Downref: Normative reference to an Informational RFC: RFC 2477 (ref. '4') ** Obsolete normative reference: RFC 2373 (ref. '5') (Obsoleted by RFC 3513) -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Obsolete normative reference: RFC 1717 (ref. '9') (Obsoleted by RFC 1990) ** Obsolete normative reference: RFC 1700 (ref. '10') (Obsoleted by RFC 3232) ** Downref: Normative reference to an Informational RFC: RFC 2867 (ref. '11') -- Possible downref: Normative reference to a draft: ref. '13' ** Downref: Normative reference to an Informational RFC: RFC 2637 (ref. '14') ** Downref: Normative reference to an Historic RFC: RFC 2341 (ref. '15') ** Downref: Normative reference to an Informational RFC: RFC 2107 (ref. '17') ** Obsolete normative reference: RFC 2401 (ref. '18') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 1827 (ref. '21') (Obsoleted by RFC 2406) ** Downref: Normative reference to an Informational RFC: RFC 1701 (ref. '22') ** Downref: Normative reference to an Informational RFC: RFC 1853 (ref. '23') == Outdated reference: A later version (-06) exists of draft-ietf-nasreq-criteria-05 ** Downref: Normative reference to an Informational draft: draft-ietf-nasreq-criteria (ref. '24') ** Obsolete normative reference: RFC 2284 (ref. '25') (Obsoleted by RFC 3748) -- Possible downref: Normative reference to a draft: ref. '26' ** Obsolete normative reference: RFC 2434 (ref. '27') (Obsoleted by RFC 5226) -- Duplicate reference: RFC2867, mentioned in '28', was also mentioned in '11'. ** Downref: Normative reference to an Informational RFC: RFC 2867 (ref. '28') ** Obsolete normative reference: RFC 2279 (ref. '29') (Obsoleted by RFC 3629) == Outdated reference: A later version (-20) exists of draft-ietf-aaa-diameter-mobileip-04 == Outdated reference: A later version (-08) exists of draft-calhoun-diameter-res-mgmt-06 -- Possible downref: Normative reference to a draft: ref. '31' ** Downref: Normative reference to an Informational RFC: RFC 2869 (ref. '32') ** Downref: Normative reference to an Informational RFC: RFC 2868 (ref. '33') -- Possible downref: Non-RFC (?) normative reference: ref. '34' ** Downref: Normative reference to an Informational RFC: RFC 2866 (ref. '35') -- Duplicate reference: RFC2869, mentioned in '36', was also mentioned in '32'. ** Downref: Normative reference to an Informational RFC: RFC 2869 (ref. '36') -- Duplicate reference: RFC2868, mentioned in '37', was also mentioned in '33'. ** Downref: Normative reference to an Informational RFC: RFC 2868 (ref. '37') Summary: 28 errors (**), 0 flaws (~~), 28 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AAA Working Group Pat R. Calhoun 3 Internet-Draft Sun Microsystems, Inc. 4 Category: Standards Track William Bulley 5 Merit Network, Inc. 6 Allan C. Rubens 7 Tut Systems, Inc. 8 Jeff Haag 9 Glen Zorn 10 Cisco Systems, Inc. 11 May 2001 13 Diameter NASREQ Extensions 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. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at: 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at: 34 http://www.ietf.org/shadow.html. 36 This document is an individual contribution for consideration by the 37 AAA Working Group of the Internet Engineering Task Force. Comments 38 should be submitted to the diameter@diameter.org mailing list. 40 Distribution of this memo is unlimited. 42 Copyright (C) The Internet Society 2001. All Rights Reserved. 44 Abstract 46 This document describes the Diameter extension that is used for AAA 47 in a PPP/SLIP Dial-Up and Terminal Server Access environment. This 48 extension, combined with the base protocol, satisfies the 49 requirements defined in the NASREQ AAA criteria specification and the 50 ROAMOPS AAA Criteria specification. 52 Given that it is expected that initial deployments of the Diameter 53 protocol in a dial-up environment will include legacy systems, this 54 extension was carefully designed to ease the burden of servers that 55 must perform protocol conversion between RADIUS and Diameter. This 56 is achieved by re-using the RADIUS address space, eliminating the 57 need to perform attribute lookups. 59 Table of Contents 61 1.0 Introduction 62 1.1 Requirements language 63 1.2 Advertising extension support 64 2.0 Supported AVPs 65 2.1 Diameter AVPs 66 2.1.1 Request-Type AVP 67 2.1.2 Filter-Rule AVP 68 2.2 Legacy RADIUS Attributes 69 2.2.1 NAS-IP-Address AVP 70 2.2.2 NAS-Identifier AVP 71 2.2.3 State AVP 72 2.2.4 Class AVP 73 3.0 Legacy RADIUS Authentication Support 74 3.1 Command-Codes Values 75 3.1.1 AA-Request (AAR) Command 76 3.1.1.1 User-Password AVP 77 3.1.1.2 CHAP-Password AVP 78 3.1.1.3 CHAP-Challenge AVP 79 3.1.1.4 ARAP-Password AVP 80 3.1.2 AA-Answer (AAA) Command 81 3.1.2.1 ARAP-Challenge-Response AVP 82 3.1.2.2 Password-Retry AVP 83 3.1.3 AA-Challenge-Ind (ACI) Command 84 3.1.3.1 Prompt AVP 85 3.2 Reply-Message AVP 86 4.0 Extensible Authentication Protocol Support 87 4.1 Alternative Uses 88 4.2 Command-Codes Values 89 4.2.1 Diameter-EAP-Request (DER) Command 90 4.2.2 Diameter-EAP-Answer (DEA) Command 91 4.2.3 Diameter-EAP-Ind (DEI) Command 92 4.3 EAP-Payload AVP 93 5.0 Diameter Session Termination 94 6.0 Call and Session Information 95 6.1 NAS-Port AVP 96 6.2 Filter-Id AVP 97 6.3 Callback-Number AVP 98 6.4 Callback-Id AVP 99 6.5 Idle-Timeout AVP 100 6.6 Called-Station-Id AVP 101 6.7 Calling-Station-Id AVP 102 6.8 NAS-Port-Type AVP 103 6.9 Port-Limit AVP 104 6.10 Connect-Info AVP 105 7.0 Service Specific Authorization AVPs 106 7.1 Service-Type AVP 107 7.2 Framed Access Authorization AVPs 108 7.2.1 Framed-Protocol AVP 109 7.2.2 Framed-Routing AVP 110 7.2.3 Framed-MTU AVP 111 7.2.4 Framed-Compression AVP 112 7.2.5 IP Access 113 7.2.5.1 Framed-IP-Address AVP 114 7.2.5.2 Framed-IP-Netmask AVP 115 7.2.5.3 Framed-IP-Route AVP 116 7.2.6 IPX Access 117 7.2.6.1 Framed-IPX-Network AVP 118 7.2.7 Appletalk Access 119 7.2.7.1 Framed-AppleTalk-Link AVP 120 7.2.7.2 Framed-AppleTalk-Network AVP 121 7.2.7.3 Framed-AppleTalk-Zone AVP 122 7.2.8 ARAP Access 123 7.2.8.1 ARAP-Features AVP 124 7.2.8.2 ARAP-Zone-Access AVP 125 7.2.8.3 ARAP-Security AVP 126 7.2.8.4 ARAP-Security-Data AVP 127 7.3 Non-Framed Access Authorization AVPs 128 7.3.1 Login-IP-Host AVP 129 7.3.2 Login-Service AVP 130 7.3.3 TCP Services 131 7.3.3.1 Login-TCP-Port AVP 132 7.3.4 LAT Services 133 7.3.4.1 Login-LAT-Service AVP 134 7.3.4.2 Login-LAT-Node AVP 135 7.3.4.3 Login-LAT-Group AVP 136 7.3.4.4 Login-LAT-Port AVP 137 7.4 Tunneling AVP 138 7.4.1 Tunnel-Type AVP 139 7.4.2 Tunnel-Medium-Type AVP 140 7.4.3 Tunnel-Client-Endpoint AVP 141 7.4.4 Tunnel-Server-Endpoint AVP 142 7.4.5 Tunnel-Password AVP 143 7.4.6 Tunnel-Private-Group-ID AVP 144 7.4.7 Tunnel-Assignment-ID AVP 145 7.4.8 Tunnel-Preference AVP 146 7.4.9 Tunnel-Client-Auth-ID AVP 147 7.4.10 Tunnel-Server-Auth-ID AVP 148 8.0 Accounting Considerations 149 8.1 Accounting-Input-Octets AVP 150 8.2 Accounting-Output-Octets AVP 151 8.3 Accounting-Session-Time AVP 152 8.4 Accounting-Input-Packets AVP 153 8.5 Accounting-Output-Packets AVP 154 8.6 Accounting-Authentication-Type AVP 155 8.7 Acct-Tunnel-Connection AVP 156 8.8 Acct-Tunnel-Packets-Lost AVP 157 9.0 Interactions with Resource Management 158 10.0 RADIUS/Diameter Protocol Interactions 159 10.1 RADIUS request forwarded as Diameter request 160 10.2 Diameter request forwarded as RADIUS request 161 11.0 AVP Occurrence Table 162 11.1 NASREQ Command AVP Table 163 11.2 Accounting AVP Table 164 11.2.1 Framed Access 165 11.2.2 Non-Framed Access 166 12.0 IANA Considerations 167 12.1 Command Codes 168 12.2 AVP Codes 169 12.3 Request-Type AVP Values 170 12.4 Extension Identifier 171 13.0 Security Considerations 172 14.0 References 173 15.0 Acknowledgements 174 16.0 Authors' Addresses 175 17.0 Full Copyright Statement 176 18.0 Expiration Date 178 1.0 Introduction 180 This document describes the Diameter extension that is used for AAA 181 in a PPP/SLIP Dial-Up and Terminal Server Access environment. This 182 extension, combined with the base protocol [2], satisfies the 183 requirements defined in the NASREQ AAA criteria specification [24] 184 and the ROAMOPS AAA Criteria specification [4]. 186 This document is divided into three main sections. The first section 187 defines the Diameter Command-Codes and AVPs that are needed to 188 support legacy authentication protocols, those that are typically 189 supported by RADIUS [1] servers. The second section defines the 190 Command-Codes and AVPs necessary for a Diameter node to support PPP's 191 Extensible Authentication Protocol (EAP) [25]. The third section 192 contains the Authorization AVPs that are needed for the various 193 services offered by a NAS, such as PPP dial-in, terminal server and 194 tunneling applications, such as L2TP [16]. 196 Given that it is expected that initial deployments of the Diameter 197 protocol in a dial-up environment will include legacy systems, this 198 extension was carefully designed to ease the burden of servers that 199 must perform protocol conversion between RADIUS and Diameter. This 200 is achieved by re-using the RADIUS address space, eliminating the 201 need to perform attribute lookups. 203 The value assigned for the Extension-Id [2] AVP is one (1). 205 1.1 Requirements language 207 In this document, the key words "MAY", "MUST", "MUST NOT", 208 "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be 209 interpreted as described in [12]. 211 1.2 Advertising extension support 213 Diameter nodes conforming to this specification MAY advertise support 214 by including the value of one (1) in either the Device-Reboot-Ind 215 Command's [2] Auth-Extension-Id or Acct-Extension-Id AVPs. 217 2.0 Supported AVPs 219 This section lists all of the Diameter AVPs and the legacy RADIUS 220 attributes supported by this extension. 222 2.1 Diameter AVPs 224 This section will define all of the AVPs that are not backward 225 compatible with the RADIUS protocol [1]. A Diameter message that 226 includes one of these AVPs MAY cause interoperability issues should 227 the request traverse a AAA node that only supports the RADIUS 228 protocol. However, the Diameter protocol SHOULD NOT be hampered from 229 future developments due to the existing installed base. 231 The following table describes the Diameter AVPs defined in the NASREQ 232 extension, their AVP Code values, types, possible flag values and 233 whether the AVP MAY be encrypted. 235 +---------------------+ 236 | AVP Flag rules | 237 |----+-----+----+-----|----+ 238 AVP Section | | |SHLD| MUST|MAY | 239 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 240 -----------------------------------------|----+-----+----+-----|----| 241 EAP-Payload 402 4.3 OctetString| M | P | | V | Y | 242 Filter-Rule 400 2.1.2 OctetString| M | P | | V | Y | 243 Request-Type 401 2.1.1 Unsigned32 | M | P | | V | N | 244 Tunneling 403 7.4 Grouped | M | P | | V | N | 246 2.1.1 Request-Type AVP 248 The Request-Type AVP (AVP Code 401) is of type Unsigned32 and is used 249 to determine the type of request being transmitted. Note that a 250 request with this AVP set to a value other than 251 AUTHORIZE_AUTHENTICATE MAY break backward RADIUS compatibility. The 252 following values are defined: 254 AUTHENTICATE_ONLY 1 255 The request being sent is for authentication only, and MUST 256 contain the relevant authentication AVPs that are needed by the 257 Diameter server to authenticate the user. 259 AUTHORIZE_ONLY 2 260 The request being sent is for authorization only, and MUST 261 contain the authorization AVPs that are necessary to identify 262 the service being requested/offered. 264 AUTHORIZE_AUTHENTICATE 3 265 The request contains a request for both authentication and 266 authorization. The request MUST include both the relevant 267 authentication information, and authorization information 268 necessary to identify the service being requested/offered. 270 2.1.2 Filter-Rule AVP 272 The Filter-Rule AVP (AVP Code 400) is of type OctetString, encoded in 273 the UTF-8 [29] format, and provides filter rules that need to be 274 configured on the NAS for the user. One or more such AVPs MAY be 275 present in an authorization response. 277 Each packet can be filtered based on the following information that 278 is associated with it: 280 Direction (in or out) 281 Source and destination IP address (possibly masked) 282 Protocol 283 Source and destination port (lists or ranges) 284 TCP flags 285 IP fragment flag 286 IP options 287 ICMP types 289 Rules for the appropriate direction are evaluated in order, with the 290 first matched rule terminating the evaluation. Each packet is 291 evaluated once. If no rule matches, the packet is dropped if the last 292 rule evaluated was a permit, and passed if the last rule was a deny. 294 The filters in the Filter-Rule AVP MUST follow the format: 296 action dir proto from src to dst [options] 298 action permit - Allow packets that match the rule. 299 deny - Drop packets that match the rule. 301 dir "in" is from the terminal, "out" is to the terminal. 303 proto An IP protocol specified by number. The "ip" keyword 304 means any protocol will match. 306 src and dst
[ports] 308 The
may be specified as: 309 ipno An IPv4 or IPv6 number in dotted-quad or 310 canonical IPv6 form. Only this exact IP 311 number will match the rule. 312 ipno/bits An IP number as above with a mask width of 313 the form 1.2.3.4/24. In this case all IP 314 numbers from 1.2.3.0 to 1.2.3.255 will 315 match. The bit width MUST be valid for 316 the IP version and the IP number MUST NOT 317 have bits set beyond the mask. 319 The sense of the match can be inverted by preceding 320 an address with the not modifier, causing all other 321 addresses to be matched instead. This does not 322 affect the selection of port numbers. 324 The keyword "any" is 0.0.0.0/0 or the IPv6 325 equivalent. The keyword "assigned" is the address 326 or set of addresses assigned to the terminal. The 327 first rule SHOULD be "deny in ip !assigned". 329 With the TCP and UDP protocols, optional ports may be 330 specified as: 332 {port|port-port}[,port[,...]] 334 The `-' notation specifies a range of ports 335 (including boundaries). 337 Fragmented packets which have a non-zero offset (i.e. 338 not the first fragment) will never match a rule which 339 has one or more port specifications. See the frag 340 option for details on matching fragmented packets. 342 options: 343 frag Match if the packet is a fragment and this is not the 344 first fragment of the datagram. frag may not be used 345 in conjunction with either tcpflags or TCP/UDP port 346 specifications. 348 ipoptions spec 349 Match if the IP header contains the comma separated 350 list of options specified in spec. The supported IP 351 options are: 353 ssrr (strict source route), lsrr (loose source route), 354 rr (record packet route) and ts (timestamp). The 355 absence of a particular option may be denoted with a 356 `!'. 358 tcpoptions spec 359 Match if the TCP header contains the comma separated 360 list of options specified in spec. The supported TCP 361 options are: 363 mss (maximum segment size), window (tcp window 364 advertisement), sack (selective ack), ts (rfc1323 365 timestamp) and cc (rfc1644 t/tcp connection count). 366 The absence of a particular option may be denoted with 367 a `!'. 369 established 370 TCP packets only. Match packets that have the RST or 371 ACK bits set. 373 setup TCP packets only. Match packets that have the SYN bit 374 set but no ACK bit. 376 tcpflags spec 377 TCP packets only. Match if the TCP header contains the 378 comma separated list of flags specified in spec. The 379 supported TCP flags are: 381 fin, syn, rst, psh, ack and urg. The absence of a 382 particular flag may be denoted with a `!'. A rule which 383 contains a tcpflags specification can never match a 384 fragmented packet which has a non-zero offset. See the 385 frag option for details on matching fragmented packets. 387 icmptypes types 388 ICMP packets only. Match if the ICMP type is in the 389 list types. The list may be specified as any 390 combination of ranges or individual types separated by 391 commas. The supported ICMP types are: 393 echo reply (0), destination unreachable (3), source 394 quench (4), redirect (5), echo request (8), router 395 advertisement (9), router solicitation (10), time-to- 396 live exceeded (11), IP header bad (12), timestamp 397 request (13), timestamp reply (14), information request 398 (15), information reply (16), address mask request (17) 399 and address mask reply (18). 401 There is one kind of packet that the NAS MUST always discard, that is 402 an IP fragment with a fragment offset of one. This is a valid 403 packet, but it only has one use, to try to circumvent firewalls. 405 A NAS that is unable to interpret or apply a deny rule MUST 406 terminate the session. A NAS that is unable to interpret or apply 407 a permit rule MAY apply a more restrictive rule. A NAS MAY apply 408 deny rules of its own before the supplied rules, for example to 409 protect the NAS owner's infrastructure. 411 The rule syntax is a modified subset of ipfw(8) from FreeBSD, and the 412 ipfw.c code may provide a useful base for implementations. 414 2.2 Legacy RADIUS Attributes 416 The Diameter protocol reserves the first 255 AVP identifiers for 417 "legacy RADIUS" support. The following table contains the RADIUS 418 attributes supported by this Diameter extension, their AVP code 419 values, types, possible flag values and whether the AVP MAY be 420 encrypted. RADIUS attributes not listed are not supported by the 421 Diameter protocol. 423 +---------------------+ 424 | AVP Flag rules | 425 |----+-----+----+-----|----+ 426 AVP Section | | |SHLD| MUST|MAY | 427 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 428 -----------------------------------------|----+-----+----+-----|----| 429 Accounting- 45 8.6 Unsigned32 | | P | | V | Y | 430 Authentication-Type | | | | | | 431 Accounting-Input- 42 8.1 Unsigned32 | | P | | V | Y | 432 Octets | | | | | | 433 Accounting-Input- 47 8.4 Unsigned32 | | P | | V | Y | 434 Packets | | | | | | 435 Accounting- 43 8.2 Unsigned32 | | P | | V | Y | 436 Output-Octets | | | | | | 437 Accounting- 48 8.5 Unsigned32 | | P | | V | Y | 438 Output-Packets | | | | | | 439 Accounting- 46 8.3 Unsigned32 | | P | | V | Y | 440 Session-Time | | | | | | 441 Acct-Tunnel- 68 8.7 OctetString| | P | | V | Y | 442 Connection | | | | | | 443 Acct-Tunnel- 86 8.8 OctetString| | P | | V | Y | 444 Packets-Lost | | | | | | 445 ARAP-Challenge- 84 3.1.2.1 OctetString| M | P | | V | Y | 446 Response | | | | | | 447 ARAP-Features 71 7.2.8.1 OctetString| M | P | | V | Y | 448 ARAP-Password 70 3.1.1.4 OctetString| M | P | | V | Y | 449 ARAP-Security 73 7.2.8.3 Unsigned32 | M | P | | V | Y | 450 ARAP-Security- 74 7.2.8.4 OctetString| M | P | | V | Y | 451 Data | | | | | | 452 ARAP-Zone-Access 72 7.2.8.2 Unsigned32 | M | P | | V | Y | 453 Callback-Id 20 6.4 OctetString| M | P | | V | Y | 454 Callback-Number 19 6.3 OctetString| M | P | | V | Y | 455 Called-Station-Id 30 6.6 OctetString| M | P | | V | Y | 456 Calling-Station- 31 6.7 OctetString| M | P | | V | Y | 457 Id | | | | | | 458 CHAP-Challenge 60 3.1.1.3 OctetString| M | P | | V | Y | 459 CHAP-Password 3 3.1.1.2 OctetString| M | P | | V | Y | 460 Class 25 2.2.4 OctetString| M | P | | V | Y | 461 Connect-Info 77 6.10 OctetString| | P | | V | Y | 462 Filter-Id 11 6.2 OctetString| M | P | | V | Y | 463 Framed-Appletalk- 37 7.2.7.1 Unsigned32 | M | P | | V | Y | 464 Link | | | | | | 465 +---------------------+ 466 | AVP Flag rules | 467 |----+-----+----+-----|----+ 468 AVP Section | | |SHLD| MUST|MAY | 469 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 470 -----------------------------------------|----+-----+----+-----|----| 471 Framed-Appletalk- 38 7.2.7.2 Unsigned32 | M | P | | V | Y | 472 Network | | | | | | 473 Framed-Appletalk- 39 7.2.7.3 OctetString| M | P | | V | Y | 474 Zone | | | | | | 475 Framed-Protocol 7 7.2.1 Unsigned32 | M | P | | V | Y | 476 Framed-IP-Address 8 7.2.5.1 Address | M | P | | V | Y | 477 Framed- 13 7.2.4 Unsigned32 | M | P | | V | Y | 478 Compression | | | | | | 479 Framed-IP-Netmask 9 7.2.5.2 Address | M | P | | V | Y | 480 Framed-IP-Route 22 7.2.5.3 OctetString| M | P | | V | Y | 481 Framed-IPX- 23 7.2.6.1 OctetString| M | P | | V | Y | 482 Network | | | | | | 483 Framed-MTU 12 7.2.3 Unsigned32 | M | P | | V | Y | 484 Framed-Routing 10 7.2.2 Unsigned32 | M | P | | V | Y | 485 Idle-Timeout 28 6.5 Unsigned32 | M | P | | V | Y | 486 Login-IP-Host 14 7.3.1 Address | M | P | | V | Y | 487 Login-LAT-Group 36 7.3.4.3 OctetString| M | P | | V | Y | 488 Login-LAT-Node 35 7.3.4.2 OctetString| M | P | | V | Y | 489 Login-LAT-Port 63 7.3.4.4 OctetString| M | P | | V | Y | 490 Login-LAT-Service 34 7.3.4.1 Unsigned32 | M | P | | V | Y | 491 Login-Service 15 7.3.2 Unsigned32 | M | P | | V | Y | 492 Login-TCP-Port 16 7.3.3.1 Unsigned32 | M | P | | V | Y | 493 NAS-Identifier 32 2.2.2 OctetString| M | P | | V | Y | 494 NAS-IP-Address 4 2.2.1 Address | M | P | | V | Y | 495 NAS-Port 5 6.1.1 Unsigned32 | M | P | | V | Y | 496 NAS-Port-Type 61 6.8 Unsigned32 | M | P | | V | Y | 497 Password-Retry 75 3.1.2.2 Unsigned32 | | P | | V | Y | 498 Port-Limit 62 6.9 Unsigned32 | M | P | | V | Y | 499 Prompt 76 3.1.3.1 Unsigned32 | | P | | V | Y | 500 Reply-Message 18 3.2 OctetString| M | P | | V | Y | 501 Service-Type 6 7.1 Unsigned32 | M | P | | V | Y | 502 State 24 2.2.3 OctetString| M | P | | V | Y | 503 Tunnel- 82 7.4.7 OctetString| M | P | | V | Y | 504 Assignment-Id | | | | | | 505 Tunnel-Client- 90 7.4.9 OctetString| M | P | | V | Y | 506 Auth-ID | | | | | | 507 Tunnel-Client- 66 7.4.3 OctetString| M | P | | V | Y | 508 Endpoint | | | | | | 509 Tunnel-Medium- 65 7.4.2 Unsigned32 | M | P | | V | Y | 510 Type | | | | | | 511 Tunnel-Password 69 7.4.5 OctetString| M | P | | V | Y | 512 +---------------------+ 513 | AVP Flag rules | 514 |----+-----+----+-----|----+ 515 AVP Section | | |SHLD| MUST|MAY | 516 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 517 -----------------------------------------|----+-----+----+-----|----| 518 Tunnel-Preference 83 7.4.8 Unsigned32 | M | P | | V | Y | 519 Tunnel-Private- 81 7.4.6 OctetString| M | P | | V | Y | 520 Group-ID | | | | | | 521 Tunnel-Server- 91 7.4.10 OctetString| M | P | | V | Y | 522 Auth-ID | | | | | | 523 Tunnel-Server- 67 7.4.4 OctetString| M | P | | V | Y | 524 Endpoint | | | | | | 525 Tunnel-Type 64 7.4.1 Unsigned32 | M | P | | V | Y | 526 User-Password 2 3.1.1.1 OctetString| M | P | | V | Y | 528 The AVPs defined in this section SHOULD only used when a 529 Diameter/RADIUS gateway function is invoked, and are not used in the 530 Diameter protocol. 532 2.2.1 NAS-IP-Address AVP 534 The NAS-IP-Address AVP (AVP Code 4) [1] is of type Address, and 535 contains the IP Address of the NAS providing service to the user. 536 When this AVP is present, the Origin-FQDN AVP DOES NOT represent the 537 NAS providing service to the user. Note that this AVP SHOULD only 538 added by a RADIUS/Diameter protocol gateway (see Section 10.0). 540 2.2.2 NAS-Identifier AVP 542 The NAS-Identifier AVP (AVP Code 32) [1] is of type OctetString, 543 encoded in the UTF-8 [29] format, and contains the Identity of the 544 NAS providing service to the user. When this AVP is present, the 545 Origin-FQDN AVP DOES NOT represent the NAS providing service to the 546 user. Note that this AVP SHOULD only added by a RADIUS/Diameter 547 protocol gateway (see Section 10.0). 549 2.2.3 State AVP 551 The State AVP (AVP Code 24) is of type OctetString and is used to 552 transmit the contents of the RADIUS State attribute, and no 553 interpretation of the contents should be made. Note that this AVP 554 SHOULD only added by a RADIUS/Diameter protocol gateway (see Section 555 10.0). 557 2.2.4 Class AVP 559 The Class AVP (AVP Code 25) is of type OctetString and is used to 560 transmit the contents of the RADIUS Class attribute, and no 561 interpretation of the contents should be made. Note that this AVP 562 SHOULD only added by a RADIUS/Diameter protocol gateway (see Section 563 10.0). 565 3.0 Legacy RADIUS Authentication Support 567 This section defines the new Command-Code [2] values required to 568 support the legacy authentication protocols (i.e. PAP, CHAP), as well 569 as the AVPs that are necessary to carry the authentication 570 information in the Diameter protocol. The functionality defined here 571 provides a RADIUS-like AAA service, over a more reliable and secure 572 transport, as defined in the base protocol [2]. 574 Unlike the RADIUS protocol [1], the Diameter protocol does not 575 require authentication information to be contained in a request from 576 the client. Therefore, it is possible to send a request for 577 authorization only. The type of service depends upon the Request-Type 578 AVP. This difference MAY cause operational issues in environments 579 that need RADIUS interoperability, and it MAY be necessary that 580 protocol conversion gateways add some authentication information when 581 transmitting to a RADIUS server. 583 The Diameter protocol allows for users to be periodically re- 584 authenticated and/or re-authorized. In such instances, the Session-Id 585 AVP in the AAR message MUST be the same as the one present in the 586 original authentication/authorization message. A Diameter server 587 informs the NAS of the authorized session lifetime via the Session- 588 Timeout AVP [1]. 590 A NAS MUST re-authenticate and/or authorize after the period provided 591 by the server. Furthermore, it is possible for Diameter servers to 592 issue an unsolicited re-authentication and/or re-authorization by 593 issuing an AA-Challenge-Ind message to the NAS. Upon receipt of such 594 a message, the NAS is instructed to issue a request to re- 595 authenticate and/or re-authorize the client. 597 3.1 Command-Codes Values 599 This section defines new Command-Code [2] values that MUST be 600 supported by all Diameter implementations that conform to this 601 specification. The following Command Codes are defined in this 602 section: 604 Command-Name Abbrev. Code Reference 605 -------------------------------------------------------- 606 AA-Answer AAA 265 3.1.2 607 AA-Challenge-Ind ACI 267 3.1.3 608 AA-Request AAR 265 3.1.1 610 3.1.1 AA-Request (AAR) Command 612 The AA-Request message (AAR), indicated by the Command-Code field set 613 to 265 and the 'R' bit set in the message flags field, is used in 614 order to request authentication and/or authorization for a given PPP 615 user. The type of request is identified through the Request-Type AVP, 616 and the default mode is both authentication and authorization. 618 If Authentication is requested the User-Name attribute SHOULD be 619 present, as well as any additional authentication AVPs that would 620 carry the password information. A request for authorization only 621 SHOULD include the information from which the authorization will be 622 performed, such as the User-Name, or DNIS and ANI AVPs. Certain 623 networks MAY use different AVPs for authorization purposes. A request 624 for authorization will include some AVPs defined in sections 2.0, 6.0 625 and 7.0. 627 It is possible for a single session to be authorized only first, then 628 followed by an authentication request. However, the inverse SHOULD 629 NOT be permitted. 631 If the AA-Request is a result of an AA-Challenge-Ind, the Session-Id 632 MUST be identical as the one provided in the initial AA-Request for 633 the same session. If the AA-Request is a result of an AA-Challenge- 634 Ind that included a State AVP, the same AVP MUST be present in the 635 following AA-Request. 637 Message Format 638 ::= < Diameter Header: 265, R > 639 < Session-Id > 640 { Auth-Extension-Id } 641 { Origin-FQDN } 642 { Origin-Realm } 643 { Destination-Realm } 644 { Service-Type } 645 [ Destination-FQDN ] 646 [ NAS-Identifier ] 647 [ User-Name ] 648 [ User-Password ] 649 [ ARAP-Password ] 650 [ CHAP-Password ] 651 [ CHAP-Challenge ] 652 [ Idle-Timeout ] 653 [ State ] 654 [ Authorization-Lifetime ] 655 [ Session-Timeout ] 656 * [ AVP ] 657 * [ Proxy-Info ] 658 * [ Route-Record ] 660 3.1.1.1 User-Password AVP 662 The User-Password AVP (AVP Code 2) is of type OctetString and 663 contains the password of the user to be authenticated, or the user's 664 input following an AA-Challenge-Ind. 666 This AVP MUST be encrypted using one of the methods described in [2] 667 or [13]. Unless this AVP is used for one-time passwords, the User- 668 Password AVP SHOULD NOT be used in non-trusted proxy environments. 670 The clear-text password (prior to encryption) MUST NOT be longer than 671 128 bytes in length. 673 3.1.1.2 CHAP-Password AVP 675 The CHAP-Password AVP (AVP Code 3) is of type Complex and contains 676 the response value provided by a PPP Challenge-Handshake 677 Authentication Protocol (CHAP) [6] user in response to the challenge. 679 If the CHAP-Password AVP is found in a message, the CHAP-Challenge 680 AVP (see section 3.1.1.3) MUST be present as well. 682 0 1 2 3 683 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 AVP Header (AVP Code = 3) 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | CHAP Ident | Data ... 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 The CHAP Ident field contains the one octet CHAP Identifier from the 691 user's CHAP response [6]. The Data field is 16 octets, and contains 692 the CHAP Response from the user. The actual computation of the CHAP 693 response can be found in [6]. 695 3.1.1.3 CHAP-Challenge AVP 697 The CHAP-Challenge AVP (AVP Code 60) is of type OctetString and 698 contains the CHAP Challenge sent by the NAS to a PPP Challenge- 699 Handshake Authentication Protocol (CHAP) [6] user. 701 3.1.1.4 ARAP-Password AVP 703 The ARAP-Password AVP (AVP Code 70) is of type OctetString and is 704 only present when the Framed-Protocol AVP (see Section 7.2.1) is 705 included in the message and is set to ARAP. This AVP MUST NOT be 706 present if the User-Password or CHAP-Password AVPs are present. See 707 [32] for more information on the contents of this AVP. 709 3.1.2 AA-Answer (AAA) Command 711 The AA-Answer (AAA) message, indicated by the Command-Code field set 712 to 265 and the 'A' bit set in the message flags field, is sent in 713 response to the AA-Request message. If authorization was requested, a 714 successful response will include the authorization AVPs appropriate 715 for the service being provided, as defined in section 2.0, 6.0 and 716 7.0 718 Message Format 719 ::= < Diameter Header: 265, A > 720 < Session-Id > 721 { Auth-Extension-Id } 722 { Result-Code } 723 { Origin-FQDN } 724 { Origin-Realm } 725 { Service-Type } 726 { Destination-FQDN } 727 [ User-Name ] 728 [ Error-Reporting-FQDN ] 729 [ Idle-Timeout ] 730 [ Authorization-Lifetime ] 731 [ Session-Timeout ] 732 * [ AVP ] 733 * [ Proxy-Info ] 734 * [ Route-Record ] 736 3.1.2.1 ARAP-Challenge-Response AVP 738 The ARAP-Challenge-Response AVP (AVP Code 84) is of type OctetString 739 and is only present when the Framed-Protocol AVP (see Section 7.2.1) 740 is included in the message and is set to ARAP. This AVP contains an 8 741 octet response to the dial-in client's challenge. The RADIUS server 742 calculates this value by taking the dial-in client's challenge from 743 the high order 8 octets of the ARAP-Password AVP and performing DES 744 encryption on this value with the authenticating user's password as 745 the key. If the user's password is less than 8 octets in length, the 746 password is padded at the end with NULL octets to a length of 8 747 before using it as a key. 749 3.1.2.2 Password-Retry AVP 751 The Password-Retry AVP (AVP Code 75) is of type Unsigned32 and MAY be 752 included in the AA-Answer if the Result-Code indicates an 753 authentication failure. The value of this AVP indicates how many 754 authentication attempts a user may be permitted before being 755 disconnected. This AVP is primarily intended for use when the 756 Framed-Protocol AVP (see Section 7.2.1) is set to ARAP. 758 3.1.3 AA-Challenge-Ind (ACI) Command 760 The AA-Challenge-Ind (ACI) message, indicated by the Command-Code 761 field set to 267 and the 'I' bit set in the message flags field, is 762 sent by a Diameter Home server to issue a challenge requiring a 763 response to a dial-up user. The message MAY have one or more Reply- 764 Message AVP, the User-Name AVP and it MAY have zero or one State AVP. 765 No other AVPs are permitted in an AA-Challenge-Ind other than 766 security related AVPs [2, 13]. 768 A Failed ACI would contain the same Command-Code, but would require 769 that only be 'F' bit be set. 771 On receipt of an AA-Challenge-Ind, the Identifier field is matched 772 with a pending AA-Request. Invalid messages are silently discarded. 774 The receipt of a valid AA-Challenge-Ind indicates that a new AA- 775 Request SHOULD be sent. The NAS MAY display the text message, if any, 776 to the user, and then prompt the user for a response. It then sends 777 its original AA-Request with a new request ID, with the User-Password 778 AVP replaced by the user's response (encrypted), and including the 779 State AVP from the AA-Challenge-Ind, if any. 781 A NAS that supports PAP MAY forward the Reply-Message to the dial-in 782 client and accept a PAP response which it can use as though the user 783 had entered the response. If the NAS cannot do so, it should treat 784 the AA-Challenge-Ind as though it had received an AA-Answer with a 785 Result-Code AVP set to a value other than DIAMETER_SUCCESS instead. 787 When possible, authentication mechanisms that include more than a 788 single authentication round trip SHOULD use EAP (see section 4.0) 789 instead of the AA-Challenge-Ind. This command has been maintained for 790 RADIUS backward compatibility. 792 AA-Challenge-Ind ::= < Diameter Header: 267, I > 793 < Session-Id > 794 { Auth-Extension-Id } 795 { Result-Code } 796 { Destination-Realm } 797 { Destination-FQDN } 798 { Origin-FQDN } 799 { Origin-Realm } 800 { Service-Type } 801 [ User-Name ] 802 [ Error-Reporting-FQDN ] 803 [ State ] 804 * [ AVP ] 805 * [ Reply-Message ] 806 * [ Proxy-Info ] 807 * [ Route-Record ] 809 3.1.3.1 Prompt AVP 810 The Prompt AVP (AVP Code 76) is of type Unsigned32, and MAY be 811 present in the AA-Challenge-Ind message. When present, it is used by 812 the NAS to determine whether the user's response, when entered, 813 should be echoed. 815 The supported values are listed in [34]. 817 3.2 Reply-Message AVP 819 The Reply-Message AVP (AVP Code 18) is of type OctetString, encoded 820 in the UTF-8 [29] format, and contains text which MAY be displayed to 821 the user. When used in an AA-Answer message with a successful 822 Result-Code AVP it indicates the success message. When found in the 823 same message with a Result-Code other than Diameter-SUCCESS it 824 contains the failure message. 826 The Reply-Message AVP MAY indicate a dialog message to prompt the 827 user before another AA-Request attempt. When used in an AA- 828 Challenge-Ind, it MAY indicate a dialog message to prompt the user 829 for a response. 831 Multiple Reply-Message's MAY be included and if any are displayed, 832 they MUST be displayed in the same order as they appear in the 833 message. 835 4.0 Extensible Authentication Protocol Support 837 The Extensible Authentication Protocol (EAP), described in [25], 838 provides a standard mechanism for support of additional 839 authentication methods within PPP. Through the use of EAP, support 840 for a number of authentication schemes may be added, including smart 841 and token cards, Kerberos, Public Key, One Time Passwords, and 842 others. 844 This section describes the Command-Codes values and AVPs that are 845 required for an EAP payload to be encapsulated within the Diameter 846 protocol. Since authentication occurs between the PPP client and its 847 home Diameter server, end-to-end authentication is achieved, reducing 848 the possibility for fraudulent authentication, such as replay and 849 man-in-the-middle attacks. End-to-end authentication also provides 850 for mutual (bi-directional) authentication, which is not possible 851 with PAP and CHAP in a roaming environment. 853 The Diameter/EAP extension allows a home Diameter server to initiate 854 an unsolicited authentication request to the user. This allows the 855 home server to periodically ensure that the user is still active, 856 which is useful when a server requires re-authentication to extend 857 the "life" of a session [26]. Server-initiated authentication can 858 reduce the number of protocol exchanges over the Internet. 860 The EAP conversation between the authenticating peer and the NAS 861 begins with the negotiation of EAP within LCP. Once EAP has been 862 negotiated, the NAS will typically send to the Diameter server a 863 Diameter-EAP-Request message with a NULL EAP-Payload AVP, signifying 864 an EAP-Start. The Port number and NAS Identifier MUST be included in 865 the AVPs issued by the NAS in the Diameter-EAP-Request packet. 867 If the Diameter home server supports EAP, it MUST respond with a 868 Diameter-EAP-Ind message containing an EAP-Payload AVP that includes 869 an encapsulated EAP payload [25]. The EAP payload is forwarded by the 870 NAS to the PPP client. The initial Diameter-EAP-Ind normally includes 871 an EAP-Request/Identity, requesting the PPP client to identify 872 itself. Upon receipt of the PPP client's EAP-Response [25], the NAS 873 will then issue a second Diameter-EAP-Request message, with the 874 client's EAP payload encapsulated within the EAP-Payload AVP. The 875 conversation continues until the Diameter server sends a Diameter- 876 EAP-Answer with a Result-Code AVP indicating success or failure. A 877 Result-Code AVP containing a failure indication SHOULD also include 878 an EAP-Payload AVP containing an EAP-Failure [25] payload, and the 879 NAS SHOULD disconnect the PPP client by issuing a LCP terminate. If 880 the Result-Code AVP indicates success, the EAP-Payload AVP MUST 881 encapsulate an EAP-Success [25] payload, and the NAS SHOULD 882 successfully terminate the PPP authentication phase. If authorization 883 was requested, a successful Diameter-EAP-Answer MUST also include the 884 appropriate authorization AVPs required for the service requested 885 (see sections 2.0, 6.0 and 7.0). 887 The above scenario creates a situation in which the NAS never needs 888 to manipulate an EAP packet. An alternative may be used in situations 889 where an EAP-Request/Identity message will always be sent by the NAS 890 to the authenticating peer. This involves having the NAS send an 891 EAP-Request/Identity message to the PPP client, and forwarding the 892 EAP-Response/Identity packet to the Diameter server in the EAP- 893 Payload AVP of a Diameter-EAP-Request packet. While this approach 894 will save a round-trip, it cannot be universally employed. There are 895 circumstances in which the user's identity may not be needed (such as 896 when authentication and accounting is handled based on the calling or 897 called phone number), and therefore an EAP-Request/Identity packet 898 may not necessarily be issued by the NAS to the authenticating peer. 900 Unless the NAS interprets the EAP-Response/Identity packet returned 901 by the authenticating peer, it will not have access to the user's 902 identity. Therefore, the Diameter Server SHOULD return the user's 903 identity by inserting it in the User-Name attribute of subsequent 904 Diameter-EAP-Answer packets. Without the user's identity, the 905 Session-Id AVP MAY be used for accounting and billing, however 906 operationally this MAY be very difficult to manage. 908 The Diameter-EAP-Ind message MAY be sent by a Diameter server in 909 order to initiate an unsolicited authentication of the PPP user, as 910 described in [26]. This functionality allows a home Diameter server 911 to easily extend the "life" of a session for a particular service, 912 while reducing the total number of authentication round-trips, should 913 the NAS initiate the periodic authentication. 915 Should an EAP authentication session be interrupted due to a home 916 server failure, the session MAY be directed to an alternate server, 917 but the authentication session will have to be restarted from the 918 beginning. 920 When Diameter is used in a roaming environment, the NAS SHOULD issue 921 the EAP-Request/Identity request to the PPP client, and forward the 922 EAP-Response in the initial Diameter-EAP-Request message. This allows 923 any Diameter proxies or brokers to identify the user, and forward the 924 message to the appropriate home server. If a response is received 925 with the Result-Code set to DIAMETER_COMMAND_UNSUPPORTED [2], it is 926 an indication that a Diameter server in the proxy chain does not 927 support EAP. The NAS MAY re-open LCP and attempt to negotiate another 928 PPP authentication protocol, such as PAP or CHAP. A NAS SHOULD be 929 cautious when determining whether a less secure authentication 930 protocol will be used, since this could be a result of a bidding down 931 attack. 933 4.1 Alternative uses 935 Currently the conversation between the backend authentication server 936 and the Diameter server is proprietary because of lack of 937 standardization. In order to increase standardization and provide 938 interoperability between Diameter vendors and backend security 939 vendors, it is recommended that Diameter-encapsulated EAP be used for 940 this conversation. 942 This has the advantage of allowing the Diameter server to support EAP 943 without the need for authentication-specific code within the Diameter 944 server. Authentication-specific code can then reside on a backend 945 authentication server instead. 947 In the case where Diameter-encapsulated EAP is used in a conversation 948 between a Diameter server and a backend authentication server, the 949 latter will typically return an Diameter-EAP-Answer/EAP-Payload/EAP- 950 Success message without inclusion of the expected authorization AVPs 951 required in a successful response. This means that the Diameter 952 server MUST add these attributes prior to sending an Diameter-EAP- 953 Answer/EAP-Payload/EAP-Success message to the NAS. 955 4.2 Command-Codes Values 957 This section defines new Command-Code [2] values that MUST be 958 supported by all Diameter implementations conforming to this 959 specification. The following Command Codes are defined in this 960 section: 962 Command-Name Abbrev. Code Reference 963 -------------------------------------------------------- 964 Diameter-EAP-Answer DEA 268 4.2.2 965 Diameter-EAP-Ind DEI 270 4.2.3 966 Diameter-EAP-Request DER 268 4.2.1 968 4.2.1 Diameter-EAP-Request (DER) Command 970 The Diameter-EAP-Request (DER) command, indicated by the Command-Code 971 field set to 268 and the 'R' bit set in the message flags field, is 972 sent by a Diameter client to a Diameter server and conveys an EAP- 973 Response [25] from the dial-up PPP client. The Diameter-EAP-Request 974 MUST contain one EAP-Payload AVP, which contains the actual EAP 975 payload. An EAP-Payload AVP with no data MAY be sent to the Diameter 976 server to initiate an EAP authentication session. 978 Upon receipt of a Diameter-EAP-Request, a Diameter server MUST issue 979 a reply. The reply may be either: 981 1) a Diameter-EAP-Ind containing an EAP-Request encapsulated 982 within an EAP-Payload attribute 983 2) a Diameter-EAP-Answer containing an EAP-Success encapsulated 984 within an EAP-Payload and a Result-Code indicating success. 985 3) a Diameter-EAP-Answer containing an EAP-Failure encapsulated 986 within an EAP-Payload and a Result-Code indicating failure. 987 4) A Message-Reject-Ind packet with a Result-Code set to 988 DIAMETER_COMMAND_UNSUPPORTED if a Diameter server does not 989 support the EAP extension. 991 Message Format 992 ::= < Diameter Header: 268, R > 993 < Session-Id > 994 { Auth-Extension-Id } 995 { Origin-FQDN } 996 { Origin-Realm } 997 { Destination-Realm } 998 { Service-Type } 999 { EAP-Payload } 1000 [ Destination-FQDN ] 1001 [ Authorization-Lifetime ] 1002 [ Session-Timeout ] 1003 [ User-Name ] 1004 [ Idle-Timeout ] 1005 [ NAS-IP-Address ] 1006 [ NAS-Identifier ] 1007 [ State ] 1008 * [ AVP ] 1009 * [ Proxy-Info ] 1010 * [ Route-Record ] 1012 4.2.2 Diameter-EAP-Answer (DEA) Command 1014 The Diameter-EAP-Answer (DEA) message, indicated by the Command-Code 1015 field set to 268 and the 'A' bit set in the message flags field, is 1016 sent by the Diameter server to the client to indicate either a 1017 successful or failed authentication. The Diameter-EAP-Answer message 1018 SHOULD include an EAP payload of type EAP-Success or EAP-Failure 1019 encapsulated within an EAP-Payload AVP. The Result-Code AVP MUST 1020 indicate a failure if the EAP-Failure payload is present, while the 1021 AVP MUST indicate success if the EAP-Success payload is present. 1023 If the message from the Diameter client included a request for 1024 authorization, a successful response MUST include the authorization 1025 AVPs that are relevant to the service being provided. 1027 Message Format 1028 ::= < Diameter Header: 268, A > 1029 < Session-Id > 1030 { Auth-Extension-Id } 1031 { Result-Code } 1032 { Origin-FQDN } 1033 { Origin-Realm } 1034 { Destination-FQDN } 1035 { Service-Type } 1036 [ Error-Reporting-FQDN ] 1037 [ EAP-Payload ] 1038 [ User-Name ] 1039 [ Idle-Timeout ] 1040 [ Authorization-Lifetime ] 1041 [ Session-Timeout ] 1042 * [ AVP ] 1043 * [ Proxy-Info ] 1044 * [ Route-Record ] 1046 4.2.3 Diameter-EAP-Ind (DEI) Command 1048 The Diameter-EAP-Ind (DEI) command, indicated by the Command-Code set 1049 to 270 and the 'I' bit set in the message flags field, has two uses. 1050 This message MAY be sent in response to a Diameter-EAP-Request 1051 message, and MUST contain an EAP-Response payload [25] encapsulated 1052 within an EAP-Payload AVP. 1054 A Failed DEI would contain the same Command-Code, but would require 1055 that only be 'F' bit be set. 1057 Alternatively, this message MAY also be sent unsolicited from a 1058 Diameter server to a client to request re-authentication of a PPP 1059 client. For re-authentication, it is recommended that the Identity 1060 request be skipped in order to reduce the number of authentication 1061 round trips. This is only possible when the user's identity is 1062 already known by the home Diameter server. 1064 Upon receipt of the message, the NAS MUST issue the EAP payload to 1065 the PPP Client, and SHOULD respond with a Diameter-EAP-Request 1066 containing the EAP-Response [25] packet. 1068 Message Format 1069 ::= 1070 < Session-Id > 1071 { Auth-Extension-Id } 1072 { Destination-FQDN } 1073 { Destination-Realm } 1074 { Origin-FQDN } 1075 { Origin-Realm } 1076 { EAP-Payload } 1077 { Service-Type } 1078 [ User-Name ] 1079 * [ AVP ] 1080 * [ Proxy-Info ] 1081 * [ Route-Record ] 1083 4.3 EAP-Payload AVP 1085 The EAP-Payload AVP (AVP Code 402) is of type OctetString and is used 1086 to encapsulate the actual EAP payload [25] that is being exchanged 1087 between the dial-up PPP client and the home Diameter server. 1089 5.0 Diameter Session Termination 1091 When a Network Access Server (NAS) receives an indication that a 1092 user's session is being disconnected (e.g. LCP Terminate is 1093 received), the NAS MUST issue a Session-Termination-Request (STR) [2] 1094 to its Diameter Server. This will ensure that any resources 1095 maintained on the servers is freed appropriately. 1097 Further, a NAS that receives a Session-Termination-Ind (STI) [2] MUST 1098 disconnect the PPP (or tunneling) session and respond with an STR 1099 message. 1101 6.0 Call and Session Information 1103 This section contains the authorization AVPs that are needed to 1104 identify call and session information, and allows the server to set 1105 constraints on a session. 1107 6.1 NAS-Port AVP 1109 The NAS-Port AVP (AVP Code 5) is of type Unsigned32 and contains the 1110 physical port number of the NAS which is authenticating the user, and 1111 is normally only present in an authentication and/or authorization 1112 request. Note that this is using "port" in its sense of a physical 1113 connection on the NAS, not in the sense of a TCP or UDP port number. 1114 Either NAS-Port or NAS-Port-Type (AVP Code 61) or both SHOULD be 1115 present in the request, if the NAS differentiates among its ports. 1117 6.2 Filter-Id AVP 1119 The Filter-Id AVP (AVP Code 11) is of type OctetString, encoded in 1120 the UTF-8 [29] format, and contains the name of the filter list for 1121 this user. Zero or more Filter-Id AVPs MAY be sent in an 1122 authorization response. 1124 Identifying a filter list by name allows the filter to be used on 1125 different NASes without regard to filter-list implementation details. 1126 However, this AVP is not roaming friendly since filter naming differs 1127 from one service provider to another. 1129 In non-RADIUS environments, it is strongly recommended that the 1130 Filter-Rule AVP be used instead. 1132 6.3 Callback-Number AVP 1134 The Callback-Number AVP (AVP Code 19) is of type OctetString, encoded 1135 in the UTF-8 [29] format, and contains a dialing string to be used 1136 for callback. It MAY be used in an authentication and/or 1137 authorization request as a hint to the server that a Callback service 1138 is desired, but the server is not required to honor the hint in the 1139 corresponding response. 1141 The codification of the range of allowed usage of this field is 1142 outside the scope of this specification. 1144 6.4 Callback-Id AVP 1146 The Callback-Id AVP (AVP Code 20) is of type OctetString, encoded in 1147 the UTF-8 [29] format, and contains the name of a place to be called, 1148 to be interpreted by the NAS. This AVP MAY be present in an 1149 authentication and/or authorization response. 1151 This AVP is not roaming friendly since it assumes that the Callback- 1152 Id is configured on the NAS. It is therefore preferable to use the 1153 Callback-Number AVP instead. 1155 6.5 Idle-Timeout AVP 1156 The Idle-Timeout AVP (AVP Code 28) is of type Unsigned32 and sets the 1157 maximum number of consecutive seconds of idle connection allowed to 1158 the user before termination of the session or prompt. It MAY be used 1159 in an authentication and/or authorization request (or challenge) as a 1160 hint to the server that an idle timeout is desired, but the server is 1161 not required to honor the hint in the corresponding response. 1163 6.6 Called-Station-Id AVP 1165 The Called-Station-Id AVP (AVP Code 30) is of type OctetString, 1166 encoded in the UTF-8 [29] format, and allows the NAS to send in the 1167 request the phone number that the user called, using Dialed Number 1168 Identification (DNIS) or a similar technology. Note that this may be 1169 different from the phone number the call comes in on. It SHOULD only 1170 be present in authentication and/or authorization requests. 1172 If the Request-Type AVP is set to authorization-only and the User- 1173 Name AVP is absent, the Diameter Server MAY perform authorization 1174 based on this field. This can be used by a NAS to request whether a 1175 call should be answered based on the DNIS. 1177 The codification of the range of allowed usage of this field is 1178 outside the scope of this specification. 1180 6.7 Calling-Station-Id AVP 1182 The Calling-Station-Id AVP (AVP Code 31) is of type OctetString, 1183 encoded in the UTF-8 [29] format, and allows the NAS to send in the 1184 request the phone number that the call came from, using Automatic 1185 Number Identification (ANI) or a similar technology. It SHOULD only 1186 be present in authentication and/or authorization requests. 1188 If the Request-Type AVP is set to authorization-only and the User- 1189 Name AVP is absent, the Diameter Server MAY perform authorization 1190 based on this field. This can be used by a NAS to request whether a 1191 call should be answered based on the ANI. 1193 The codification of the range of allowed usage of this field is 1194 outside the scope of this specification. 1196 6.8 NAS-Port-Type AVP 1198 The NAS-Port-Type AVP (AVP Code 61) is of type Unsigned32 and 1199 contains the type of the physical port of the NAS which is 1200 authenticating the user. It can be used instead of or in addition to 1201 the NAS-Port (5) AVP. This AVP SHOULD only be used in authentication 1202 and/or authorization requests. This AVP MAY be combined with the 1203 NAS-Port AVP to assist in differentiating its ports. 1205 The supported values are defined in [34]. 1207 6.9 Port-Limit AVP 1209 The Port-Limit AVP (AVP Code 62) is of type Unsigned32 and sets the 1210 maximum number of ports to be provided to the user by the NAS. It 1211 MAY be used in an authentication and/or authorization request as a 1212 hint to the server that multilink PPP [9] service is desired, but the 1213 server is not required to honor the hint in the corresponding 1214 response. 1216 6.10 Connect-Info AVP 1218 The Connect-Info AVP (AVP Code 77) is of type OctetString and is sent 1219 in the AA-Request message, and indicates the nature of the user's 1220 connection. The value consists of UTF-8 encoded 10646 characters. 1221 The connection speed SHOULD be included at the beginning of the first 1222 Connect-Info AVP in the message. If the transmit and receive 1223 connection speeds differ, they may both be included in the first AVP 1224 with the transmit speed first (the speed the NAS modem transmits at), 1225 a slash (/), the receive speed, then optionally other information. 1227 7.0 Service Specific Authorization AVPs 1229 This section contains the RADIUS authorization AVPs that are 1230 supported in the Diameter protocol. The Service-Type AVP MUST be 1231 present in all messages, and based on the value of the Service-Type 1232 AVP, additional AVPs defined in sections 7.2, 7.3 and 7.4 MAY be 1233 present. 1235 7.1 Service-Type AVP 1237 The Service-Type AVP (AVP Code 6) is of type Unsigned32 and contains 1238 the type of service the user has requested, or the type of service to 1239 be provided. One such AVP MAY be present in an authentication and/or 1240 authorization request or response. A NAS is not required to implement 1241 all of these service types, and MUST treat unknown or unsupported 1242 Service-Types as though a response with a Result-Code other than 1243 Diameter-SUCCESS had been received instead. 1245 When used in a request, the Service-Type AVP SHOULD be considered to 1246 be a hint to the server that the NAS has reason to believe the user 1247 would prefer the kind of service indicated, but the server is not 1248 required to honor the hint. The following values have been defined 1249 for the Service-Type AVP: 1251 The complete list of defined values can be found in [1] and [34]. The 1252 following values are extracted from [1], and are listed here since 1253 they are further qualified: 1255 Login 1 1256 The user should be connected to a host. The message MAY include 1257 additional AVPs defined in section 7.3. 1259 Framed 2 1260 A Framed Protocol should be started for the User, such as PPP 1261 or SLIP. The message MAY include additional AVPs defined in 1262 section 7.2, or 7.4 for tunneling services. 1264 Callback Login 3 1265 The user should be disconnected and called back, then connected 1266 to a host. The message MAY include additional AVPs defined in 1267 section 7.3. 1269 Callback Framed 4 1270 The user should be disconnected and called back, then a Framed 1271 Protocol should be started for the User, such as PPP or SLIP. 1272 The message MAY include additional AVPs defined in section 7.2, 1273 or 7.4 for tunneling services. 1275 7.2 Framed Access Authorization AVPs 1277 This section contains the authorization AVPs that are necessary to 1278 support framed access, such as PPP, SLIP, etc. AVPs defined in this 1279 section MAY be present in a message if the Service-Type AVP was set 1280 to "Framed" or "Callback Framed". 1282 7.2.1 Framed-Protocol AVP 1284 The Framed-Protocol AVP (AVP Code 7) is of type Unsigned32 and 1285 contains the framing to be used for framed access. This AVP MAY be 1286 present in both requests and responses. The supported values are 1287 listed in [34]. 1289 7.2.2 Framed-Routing AVP 1290 The Framed-Routing AVP (AVP Code 10) is of type Unsigned32 and 1291 contains the routing method for the user, when the user is a router 1292 to a network. This AVP SHOULD only be present in authorization 1293 responses. The supported values are listed in [34]. 1295 7.2.3 Framed-MTU AVP 1297 The Framed-MTU AVP (AVP Code 12) is of type Unsigned32 and contains 1298 the Maximum Transmission Unit to be configured for the user, when it 1299 is not negotiated by some other means (such as PPP). This AVP SHOULD 1300 only be present in authorization responses. The MTU value MUST be 1301 between the range of 64 and 65535. 1303 7.2.4 Framed-Compression AVP 1305 The Framed-Compression AVP (AVP Code 13) is of type Unsigned32 and 1306 contains the compression protocol to be used for the link. It MAY be 1307 used in an authorization request as a hint to the server that a 1308 specific compression type is desired, but the server is not required 1309 to honor the hint in the corresponding response. 1311 More than one compression protocol AVP MAY be sent. It is the 1312 responsibility of the NAS to apply the proper compression protocol to 1313 appropriate link traffic. 1315 The supported values are listed in [34]. 1317 7.2.5 IP Access 1319 The AVPs defined in this section are used when the user requests, or 1320 is being granted, access to IP. They are only present if the Framed- 1321 Protocol AVP (see Section 7.2.1) is set to PPP, SLIP, Gandalf 1322 proprietarySingleLink/MultiLink protocol, or X.75 Synchronous. 1324 7.2.5.1 Framed-IP-Address AVP 1326 The Framed-IP-Address AVP (AVP Code 8) is of type Address and 1327 contains the address to be configured for the user. It MAY be used in 1328 an authorization request as a hint to the server that a specific 1329 address is desired, but the server is not required to honor the hint 1330 in the corresponding response. 1332 Two addresses have special significance; 0xFFFFFFFF and 0xFFFFFFFE. 1333 The value 0xFFFFFFFF indicates that the NAS should allow the user to 1334 select an address (e.g. Negotiated). The value 0xFFFFFFFE indicates 1335 that the NAS should select an address for the user (e.g. Assigned 1336 from a pool of addresses kept by the NAS). 1338 7.2.5.2 Framed-IP-Netmask AVP 1340 The Framed-IP-Netmask AVP (AVP Code 9) is of type Address and 1341 contains the IP netmask to be configured for the user when the user 1342 is a router to a network. It MAY be used in an authorization request 1343 as a hint to the server that a specific netmask is desired, but the 1344 server is not required to honor the hint in the corresponding 1345 response. This AVP MUST be present in a response if the request 1346 included this AVP with a value of 0xFFFFFFFF. 1348 7.2.5.3 Framed-IP-Route AVP 1350 The Framed-IP-Route AVP (AVP Code 22) is of type OctetString, encoded 1351 in the UTF-8 [29] format, and contains the routing information to be 1352 configured for the user on the NAS. Zero or more such AVPs MAY be 1353 present in an authorization response. 1355 The string MUST contain a destination prefix in dotted quad form 1356 optionally followed by a slash and a decimal length specifier stating 1357 how many high order bits of the prefix should be used. That is 1358 followed by a space, a gateway address in dotted quad form, a space, 1359 and one or more metrics separated by spaces. For example, 1360 "192.168.1.0/24 192.168.1.1 1". 1362 The length specifier may be omitted in which case it should default 1363 to 8 bits for class A prefixes, 16 bits for class B prefixes, and 24 1364 bits for class C prefixes. For example, "192.168.1.0 192.168.1.1 1". 1366 Whenever the gateway address is specified as "0.0.0.0" the IP address 1367 of the user SHOULD be used as the gateway address. 1369 7.2.6 IPX Access 1371 The AVPs defined in this section are used when the user requests, or 1372 is being granted, access to IPX. They are only present if the 1373 Framed-Protocol AVP (see Section 7.2.1) is set to PPP, Xylogics 1374 proprietary IPX/SLIP, Gandalf proprietarySingleLink/MultiLink 1375 protocol, or X.75 Synchronous. 1377 7.2.6.1 Framed-IPX-Network AVP 1378 The Framed-IPX-Network AVP (AVP Code 23) is of type OctetString, 1379 encoded in the UTF-8 [29] format, and contains the IPX Network number 1380 to be configured for the user. It MAY be used in an authorization 1381 request as a hint to the server that a specific address is desired, 1382 but the server is not required to honor the hint in the corresponding 1383 response. 1385 Two addresses have special significance; 0xFFFFFFFF and 0xFFFFFFFE. 1386 The value 0xFFFFFFFF indicates that the NAS should allow the user to 1387 select an address (e.g. Negotiated). The value 0xFFFFFFFE indicates 1388 that the NAS should select an address for the user (e.g. assigned 1389 from a pool of one or more IPX networks kept by the NAS). 1391 7.2.7 Appletalk Access 1393 The AVPs defined in this section are used when the user requests, or 1394 is being granted, access to Appletalk. They are only present if the 1395 Framed-Protocol AVP (see Section 7.2.1) is set to PPP, Gandalf 1396 proprietary SingleLink/MultiLink protocol, or X.75 Synchronous. 1398 7.2.7.1 Framed-AppleTalk-Link AVP 1400 The Framed-AppleTalk-Link AVP (AVP Code 37) is of type Unsigned32 and 1401 contains the AppleTalk network number which should be used for the 1402 serial link to the user, which is another AppleTalk router. This AVP 1403 MUST only be present in an authorization response and is never used 1404 when the user is not another router. 1406 Despite the size of the field, values range from zero to 65535. The 1407 special value of zero indicates that this is an unnumbered serial 1408 link. A value of one to 65535 means that the serial line between the 1409 NAS and the user should be assigned that value as an AppleTalk 1410 network number. 1412 7.2.7.2 Framed-AppleTalk-Network AVP 1414 The Framed-AppleTalk-Network AVP (AVP Code 38) is of type Unsigned32 1415 and contains the AppleTalk Network number which the NAS should probe 1416 to allocate an AppleTalk node for the user. This AVP MUST only be 1417 present in an authorization response and is never used when the user 1418 is not another router. Multiple instances of this AVP indicate that 1419 the NAS may probe using any of the network numbers specified. 1421 Despite the size of the field, values range from zero to 65535. The 1422 special value zero indicates that the NAS should assign a network for 1423 the user, using its default cable range. A value between one and 1424 65535 (inclusive) indicates the AppleTalk Network the NAS should 1425 probe to find an address for the user. 1427 7.2.7.3 Framed-AppleTalk-Zone AVP 1429 The Framed-AppleTalk-Zone AVP (AVP Code 39) is of type OctetString 1430 and contains the AppleTalk Default Zone to be used for this user. 1431 This AVP MUST only be present in an authorization response. Multiple 1432 instances of this AVP in the same message are not allowed. 1434 The codification of the range of allowed usage of this field is 1435 outside the scope of this specification. 1437 7.2.8 ARAP Access 1439 The AVPs defined in this section are used when the user requests, or 1440 is being granted, access to ARAP. They are only present if the 1441 Framed-Protocol AVP (see Section 7.2.1) is set to AppleTalk Remote 1442 Access Protocol (ARAP). 1444 7.2.8.1 ARAP-Features AVP 1446 The ARAP-Features AVP (AVP Code 71) is of type OctetString, and MAY 1447 be present in the AA-Accept message if the Framed-Protocol AVP is set 1448 to the value of ARAP. See [32] for more information of the format of 1449 this AVP. 1451 7.2.8.2 ARAP-Zone-Access AVP 1453 The ARAP-Zone-Access AVP (AVP Code 72) is of type Unsigned32, and MAY 1454 be present in the AA-Accept message if the Framed-Protocol AVP is set 1455 to the value of ARAP. 1457 The supported values are listed in [34], and are defined in [32]. 1459 7.2.8.3 ARAP-Security AVP 1461 The ARAP-Security AVP (AVP Code 73) is of type Unsigned32, and MAY be 1462 present in the AA-Challenge-Ind message if the Framed-Protocol AVP is 1463 set to the value of ARAP. See [32] for more information of the 1464 format of this AVP. 1466 7.2.8.4 ARAP-Security-Data AVP 1468 The ARAP-Security AVP (AVP Code 74) is of type OctetString, and MAY 1469 be present in the AA-Request or AA-Challenge-Ind message if the 1470 Framed-Protocol AVP is set to the value of ARAP. This AVP contains 1471 the security module challenge or response associated with the ARAP 1472 Security Module specified in ARAP-Security. 1474 7.3 Non-Framed Access Authorization AVPs 1476 This section contains the authorization AVPs that are needed to 1477 support terminal server functionality. AVPs defined in this section 1478 MAY be present in a message if the Service-Type AVP was set to 1479 "Login" or "Callback Login". 1481 7.3.1 Login-IP-Host AVP 1483 The Login-IP-Host AVP (AVP Code 14) is of type Address and contains 1484 the system with which to connect the user, when the Login-Service AVP 1485 is included. It MAY be used in an authorization request as a hint to 1486 the server that a specific host is desired, but the server is not 1487 required to honor the hint in the corresponding response. 1489 Two addresses have special significance; 0xFFFFFFFF and 0xFFFFFFFE. 1490 The value 0xFFFFFFFF indicates that the NAS SHOULD allow the user to 1491 select an address. The value zero indicates that the NAS SHOULD 1492 select a host to connect the user to. 1494 7.3.2 Login-Service AVP 1496 The Login-Service AVP (AVP Code 15) is of type Unsigned32 and 1497 contains the service which should be used to connect the user to the 1498 login host. This AVP SHOULD only be present in authorization 1499 responses. 1501 The supported values are listed in [34]. 1503 7.3.3 TCP Services 1505 The AVP described in this section MAY be present if the Login-Service 1506 AVP is set to Telnet, Rlogin, TCP Clear or TCP Clear Quiet. 1508 7.3.3.1 Login-TCP-Port AVP 1509 The Login-TCP-Port AVP (AVP Code 16) is of type Unsigned32 and 1510 contains the TCP port with which the user is to be connected, when 1511 the Login-Service AVP is also present. This AVP SHOULD only be 1512 present in authorization responses. The value MUST NOT be greater 1513 than 65535. 1515 7.3.4 LAT Services 1517 The AVP described in this section MAY be present if the Login-Service 1518 AVP is set to LAT. 1520 7.3.4.1 Login-LAT-Service AVP 1522 The Login-LAT-Service AVP (AVP Code 34) is of type OctetString and 1523 contains the system with which the user is to be connected by LAT. It 1524 MAY be used in an authorization request as a hint to the server that 1525 a specific service is desired, but the server is not required to 1526 honor the hint in the corresponding response. This AVP MUST only be 1527 present in the response if the Login-Service AVP states that LAT is 1528 desired. 1530 Administrators use the service attribute when dealing with clustered 1531 systems, such as a VAX or Alpha cluster. In such an environment 1532 several different time sharing hosts share the same resources (disks, 1533 printers, etc.), and administrators often configure each to offer 1534 access (service) to each of the shared resources. In this case, each 1535 host in the cluster advertises its services through LAT broadcasts. 1537 Sophisticated users often know which service providers (machines) are 1538 faster and tend to use a node name when initiating a LAT connection. 1539 Alternately, some administrators want particular users to use certain 1540 machines as a primitive form of load balancing (although LAT knows 1541 how to do load balancing itself). 1543 The String field contains the identity of the LAT service to use. 1544 The LAT Architecture allows this string to contain $ (dollar), - 1545 (hyphen), . (period), _ (underscore), numerics, upper and lower case 1546 alphabetics, and the ISO Latin-1 character set extension [8]. All LAT 1547 string comparisons are case insensitive. 1549 7.3.4.2 Login-LAT-Node AVP 1551 The Login-LAT-Node AVP (AVP Code 35) is of type OctetString and 1552 contains the Node with which the user is to be automatically 1553 connected by LAT. It MAY be used in an authorization request as a 1554 hint to the server that a specific LAT node is desired, but the 1555 server is not required to honor the hint in the corresponding 1556 response. This AVP MUST only be present in a response if the 1557 Service-Type AVP is set to LAT. 1559 The String field contains the identity of the LAT service to use. 1560 The LAT Architecture allows this string to contain $ (dollar), - 1561 (hyphen), . (period), _ (underscore), numerics, upper and lower case 1562 alphabetics, and the ISO Latin-1 character set extension [8]. All LAT 1563 string comparisons are case insensitive. 1565 7.3.4.3 Login-LAT-Group AVP 1567 The Login-LAT-Group AVP (AVP Code 36) is of type OctetString and 1568 contains a string identifying the LAT group codes which this user is 1569 authorized to use. It MAY be used in an authorization request as a 1570 hint to the server that a specific group is desired, but the server 1571 is not required to honor the hint in the corresponding response. This 1572 AVP MUST only be present in a response if the Service-Type AVP is set 1573 to LAT. 1575 LAT supports 256 different group codes, which LAT uses as a form of 1576 access rights. LAT encodes the group codes as a 256 bit bitmap. 1578 Administrators can assign one or more of the group code bits at the 1579 LAT service provider; it will only accept LAT connections that have 1580 these group codes set in the bit map. The administrators assign a 1581 bitmap of authorized group codes to each user; LAT gets these from 1582 the operating system, and uses these in its requests to the service 1583 providers. 1585 The codification of the range of allowed usage of this field is 1586 outside the scope of this specification. 1588 7.3.4.4 Login-LAT-Port AVP 1590 The Login-LAT-Port AVP (AVP Code 63) is of type OctetString and 1591 contains the Port with which the user is to be connected by LAT. It 1592 MAY be used in an authorization request as a hint to the server that 1593 a specific port is desired, but the server is not required to honor 1594 the hint in the corresponding response. This AVP MUST only be present 1595 in a response if the Service-Type AVP is set to LAT. 1597 The String field contains the identity of the LAT service to use. 1598 The LAT Architecture allows this string to contain $ (dollar), - 1599 (hyphen), . (period), _ (underscore), numerics, upper and lower case 1600 alphabetics, and the ISO Latin-1 character set extension [8]. All LAT 1601 string comparisons are case insensitive. 1603 7.4 Tunneling AVP 1605 The Tunneling AVP (AVP Code 403) is of type Grouped and contains AVPs 1606 used to describe a tunnel. Its Data field has the following ABNF 1607 grammar: 1609 Tunneling = Type Medium Cep Sep Pw Gid Aid Pref Caid Said 1610 Type = Tunnel-Type ; See Section 7.4.1 1611 Medium = Tunnel-Medium-Type ; See Section 7.4.2 1612 Cep = Tunnel-Client-Endpoint ; See Section 7.4.3 1613 Sep = Tunnel-Server-Endpoint ; See Section 7.4.4 1614 Pw = Tunnel-Password ; See Section 7.4.5 1615 Gid = Tunnel-Private-Group-ID ; See Section 7.4.6 1616 Aid = Tunnel-Assignment-ID ; See Section 7.4.7 1617 Pref = Tunnel-Preference ; See Section 7.4.8 1618 Caid = Tunnel-Client-Auth-ID ; See Section 7.4.9 1619 Said = Tunnel-Server-Auth-ID ; See Section 7.1.4.10 1621 +---------------------------------------------------------------+ 1622 | AVP Header (AVP Code = 403) | 1623 +---------------------------------------------------------------+ 1624 | Tunnel-Type AVP | 1625 +---------------------------------------------------------------+ 1626 | Tunnel-Medium-Type AVP | 1627 +---------------------------------------------------------------+ 1628 | Tunnel-Client-Endpoint AVP | 1629 +---------------------------------------------------------------+ 1630 | Tunnel-Server-Endpoint AVP | 1631 +---------------------------------------------------------------+ 1632 | Tunnel-Password AVP | 1633 +---------------------------------------------------------------+ 1634 | Tunnel-Private-Group-Id AVP | 1635 +---------------------------------------------------------------+ 1636 | Tunnel-Assignment-ID AVP | 1637 +---------------------------------------------------------------+ 1638 | Tunnel-Preference AVP | 1639 +---------------------------------------------------------------+ 1640 | Tunnel-Client-Auth-ID AVP | 1641 +---------------------------------------------------------------+ 1642 | Tunnel-Server-Auth-ID AVP | 1643 +---------------------------------------------------------------+ 1645 7.4.1 Tunnel-Type AVP 1646 The Tunnel-Type AVP (AVP Code 64) is of type Unsigned32 and contains 1647 the tunneling protocol(s) to be used (in the case of a tunnel 1648 initiator) or the the tunneling protocol in use (in the case of a 1649 tunnel terminator). It MAY be used in an authorization request as a 1650 hint to the server that a specific tunnel type is desired, but the 1651 server is not required to honor the hint in the corresponding 1652 response. 1654 The Tunnel-Type SHOULD also be present in the corresponding ADIF 1655 Record within the Accounting-Request. 1657 A tunnel initiator is not required to implement any of these tunnel 1658 types; if a tunnel initiator receives a response that contains only 1659 unknown or unsupported Tunnel-Types, the tunnel initiator MUST behave 1660 as though a response was received with the Result-Code indicating a 1661 failure. 1663 The supported values are listed in [34]. 1665 7.4.2 Tunnel-Medium-Type AVP 1667 The Tunnel-Medium-Type AVP (AVP Code 65) is of type Unsigned32 and 1668 contains the transport medium to use when creating a tunnel for those 1669 protocols (such as L2TP) that can operate over multiple transports. 1670 It MAY be used in an authorization request as a hint to the server 1671 that a specific medium is desired, but the server is not required to 1672 honor the hint in the corresponding response. 1674 The Value field contains one of the values listed under "Address 1675 Family Numbers" in [10]. The value of most importance is (1) for IPv4 1676 and (2) for IPv6. 1678 7.4.3 Tunnel-Client-Endpoint AVP 1680 The Tunnel-Client-Endpoint AVP (AVP Code 66) is of type OctetString, 1681 encoded in the UTF-8 [29] format, and contains the address of the 1682 initiator end of the tunnel. It MAY be used in an authorization 1683 request as a hint to the server that a specific endpoint is desired, 1684 but the server is not required to honor the hint in the corresponding 1685 response. 1687 This AVP SHOULD be included in the ADIF Record of the corresponding 1688 Accounting-Request messages, in which case it indicates the address 1689 from which the tunnel was initiated. This AVP, along with the 1690 Tunnel-Server-Endpoint and Session-Id AVP [2], MAY be used to provide 1691 a globally unique means to identify a tunnel for accounting and 1692 auditing purposes. 1694 If Tunnel-Medium-Type is IPv4 (1), then this string is either the 1695 fully qualified domain name (FQDN) of the tunnel client machine, or 1696 it is a "dotted-decimal" IP address. Conformant implementations MUST 1697 support the dotted-decimal format and SHOULD support the FQDN format 1698 for IP addresses. 1700 If Tunnel-Medium-Type is IPv6 (2), then this string is either the 1701 FQDN of the tunnel client machine, or it is a text representation of 1702 the address in either the preferred or alternate form [5]. 1703 Conformant implementations MUST support the preferred form and SHOULD 1704 support both the alternate text form and the FQDN format for IPv6 1705 addresses. 1707 If Tunnel-Medium-Type is neither IPv4 nor IPv6, this string is a tag 1708 referring to configuration data local to the Diameter client that 1709 describes the interface and medium-specific address to use. 1711 7.4.4 Tunnel-Server-Endpoint AVP 1713 The Tunnel-Server-Endpoint AVP (AVP Code 67) is of OctetString, 1714 encoded in the UTF-8 [29] format, and contains the address of the 1715 server end of the tunnel. It MAY be used in an authorization request 1716 as a hint to the server that a specific endpoint is desired, but the 1717 server is not required to honor the hint in the corresponding 1718 response. 1720 This AVP SHOULD be included in the ADIF Record of the corresponding 1721 Accounting-Request messages, in which case it indicates the address 1722 from which the tunnel was initiated. This AVP, along with the 1723 Tunnel-Client-Endpoint and Session-Id AVP [2], MAY be used to provide 1724 a globally unique means to identify a tunnel for accounting and 1725 auditing purposes. 1727 If Tunnel-Medium-Type is IPv4 (1), then this string is either the 1728 fully qualified domain name (FQDN) of the tunnel client machine, or 1729 it is a "dotted-decimal" IP address. Conformant implementations MUST 1730 support the dotted-decimal format and SHOULD support the FQDN format 1731 for IP addresses. 1733 If Tunnel-Medium-Type is IPv6 (2), then this string is either the 1734 FQDN of the tunnel client machine, or it is a text representation of 1735 the address in either the preferred or alternate form [5]. 1736 Conformant implementations MUST support the preferred form and SHOULD 1737 support both the alternate text form and the FQDN format for IPv6 1738 addresses. 1740 If Tunnel-Medium-Type is not IPv4 or IPv6, this string is a tag 1741 referring to configuration data local to the Diameter client that 1742 describes the interface and medium-specific address to use. 1744 7.4.5 Tunnel-Password AVP 1746 The Tunnel-Password AVP (AVP Code 69) is of type OctetString and may 1747 contain a password to be used to authenticate to a remote server. 1748 This AVP MUST only be present in authorization responses in an 1749 encrypted form, using one of the methods described in [2] and [13]. 1751 7.4.6 Tunnel-Private-Group-ID AVP 1753 The Tunnel-Private-Group-ID AVP (AVP Code 81) is of type OctetString, 1754 encoded in the UTF-8 [29] format, and contains the group ID for a 1755 particular tunneled session. The Tunnel-Private-Group-ID AVP MAY be 1756 included in an authorization request if the tunnel initiator can 1757 pre-determine the group resulting from a particular connection and 1758 SHOULD be included in the authorization response if this tunnel 1759 session is to be treated as belonging to a particular private group. 1760 Private groups may be used to associate a tunneled session with a 1761 particular group of users. For example, it MAY be used to facilitate 1762 routing of unregistered IP addresses through a particular interface. 1763 This value SHOULD be included the corresponding ADIF-Record in the 1764 Accounting-Request which pertain to a tunneled session. 1766 7.4.7 Tunnel-Assignment-ID AVP 1768 The Tunnel-Assignment-ID AVP (AVP Code 82) is of type OctetString and 1769 is used to indicate to the tunnel initiator the particular tunnel to 1770 which a session is to be assigned. Some tunneling protocols, such as 1771 PPTP and L2TP, allow for sessions between the same two tunnel 1772 endpoints to be multiplexed over the same tunnel and also for a given 1773 session to utilize its own dedicated tunnel. This attribute provides 1774 a mechanism for Diameter to be used to inform the tunnel initiator 1775 (e.g. PAC, LAC) whether to assign the session to a multiplexed 1776 tunnel or to a separate tunnel. Furthermore, it allows for sessions 1777 sharing multiplexed tunnels to be assigned to different multiplexed 1778 tunnels. 1780 A particular tunneling implementation may assign differing 1781 characteristics to particular tunnels. For example, different 1782 tunnels may be assigned different QOS parameters. Such tunnels may 1783 be used to carry either individual or multiple sessions. The 1784 Tunnel-Assignment-ID attribute thus allows the Diameter server to 1785 indicate that a particular session is to be assigned to a tunnel that 1786 provides an appropriate level of service. It is expected that any 1787 QOS-related Diameter tunneling attributes defined in the future that 1788 accompany this attribute will be associated by the tunnel initiator 1789 with the ID given by this attribute. In the meantime, any semantic 1790 given to a particular ID string is a matter left to local 1791 configuration in the tunnel initiator. 1793 The Tunnel-Assignment-ID AVP is of significance only to Diameter and 1794 the tunnel initiator. The ID it specifies is intended to be of only 1795 local use to Diameter and the tunnel initiator. The ID assigned by 1796 the tunnel initiator is not conveyed to the tunnel peer. 1798 This attribute MAY be included in authorization responses. The tunnel 1799 initiator receiving this attribute MAY choose to ignore it and assign 1800 the session to an arbitrary multiplexed or non-multiplexed tunnel 1801 between the desired endpoints. This attribute SHOULD also be 1802 included in the corresponding ADIF-Record in the Accounting-Request 1803 messages which pertain to a tunneled session. 1805 If a tunnel initiator supports the Tunnel-Assignment-ID AVP, then it 1806 should assign a session to a tunnel in the following manner: 1808 - If this AVP is present and a tunnel exists between the specified 1809 endpoints with the specified ID, then the session should be 1810 assigned to that tunnel. 1812 - If this AVP is present and no tunnel exists between the 1813 specified endpoints with the specified ID, then a new tunnel 1814 should be established for the session and the specified ID 1815 should be associated with the new tunnel. 1817 - If this AVP is not present, then the session is assigned to an 1818 unnamed tunnel. If an unnamed tunnel does not yet exist between 1819 the specified endpoints then it is established and used for this 1820 and subsequent sessions established without the Tunnel- 1821 Assignment-ID attribute. A tunnel initiator MUST NOT assign a 1822 session for which a Tunnel-Assignment-ID AVP was not specified 1823 to a named tunnel (i.e. one that was initiated by a session 1824 specifying this AVP). 1826 Note that the same ID may be used to name different tunnels if such 1827 tunnels are between different endpoints. 1829 7.4.8 Tunnel-Preference AVP 1831 The Tunnel-Preference AVP (AVP Code 83) is of type Unsigned32 and is 1832 used to identify the relative preference assigned to each tunnel when 1833 more than one set of tunneling AVPs is returned within separate 1834 Grouped-AVP AVPs. It MAY be used in an authorization request as a 1835 hint to the server that a specific preference is desired, but the 1836 server is not required to honor the hint in the corresponding 1837 response. 1839 For example, suppose that AVPs describing two tunnels are returned by 1840 the server, one with a Tunnel-Type of PPTP and the other with a 1841 Tunnel-Type of L2TP. If the tunnel initiator supports only one of 1842 the Tunnel-Types returned, it will initiate a tunnel of that type. 1843 If, however, it supports both tunnel protocols, it SHOULD use the 1844 value of the Tunnel-Preference AVP to decide which tunnel should be 1845 started. The tunnel having the numerically lowest value in the Value 1846 field of this AVP SHOULD be given the highest preference. The values 1847 assigned to two or more instances of the Tunnel-Preference AVP within 1848 a given authorization response MAY be identical. In this case, the 1849 tunnel initiator SHOULD use locally configured metrics to decide 1850 which set of AVPs to use. 1852 7.4.9 Tunnel-Client-Auth-ID AVP 1854 The Tunnel-Client-Auth-ID AVP (AVP Code 90) is of type Unsigned32 and 1855 specifies the name used by the tunnel initiator during the 1856 authentication phase of tunnel establishment. It MAY be used in an 1857 authorization request as a hint to the server that a specific 1858 preference is desired, but the server is not required to honor the 1859 hint in the corresponding response. This AVP MUST be present in the 1860 authorization response if an authentication name other than the 1861 default is desired. This AVP SHOULD be included in the corresponding 1862 ADIF-Record of the Accounting-Request messages which pertain to a 1863 tunneled session. 1865 7.4.10 Tunnel-Server-Auth-ID AVP 1867 The Tunnel-Server-Auth-ID AVP (AVP Code 91) is of type OctetString 1868 and specifies the name used by the tunnel terminator during the 1869 authentication phase of tunnel establishment. It MAY be used in an 1870 authorization request as a hint to the server that a specific 1871 preference is desired, but the server is not required to honor the 1872 hint in the corresponding response. This AVP MUST be present in the 1873 authorization response if an authentication name other than the 1874 default is desired. This AVP SHOULD be included in the corresponding 1875 ADIF-Record of the Accounting-Request messages which pertain to a 1876 tunneled session. 1878 8.0 Accounting AVPs 1880 This section contains a description of the AVPs defined in this 1881 document that are to be included in Diameter accounting messages [2]. 1883 8.1 Accounting-Input-Octets AVP 1885 The Accounting-Input-Octets AVP (AVP Code 42) is of type Unsigned64, 1886 and contains the number of octets in IP packets received by the user. 1888 8.2 Accounting-Output-Octets AVP 1890 The Accounting-Output-Octets AVP (AVP Code 43) is of type Unsigned64, 1891 and contains the number of octets in IP packets sent to the user. 1893 8.3 Accounting-Session-Time AVP 1895 The Accounting-Session-Time AVP (AVP Code 46) is of type Unsigned32, 1896 and indicates the length of the current session in seconds. 1898 8.4 Accounting-Input-Packets AVP 1900 The Accounting-Input-Packets (AVP Code 47) is of type Unsigned64, and 1901 contains the number of IP packets received by the user. 1903 8.5 Accounting-Output-Packets AVP 1905 The Accounting-Output-Packets (AVP Code 48) is of type Unsigned64, 1906 and contains the number of IP packets sent to the user. 1908 8.6 Accounting-Authentication-Type AVP 1910 The Accounting-Authentication-Type AVP (AVP Code 45) is of type 1911 Unsigned32, and specifies how the user was authenticated. The 1912 supported values are listed in [34]. 1914 8.7 Acct-Tunnel-Connection AVP 1916 The Acct-Tunnel-Connection AVP (AVP Code 68) is of type OctetString, 1917 and contains the identifier assigned to the tunnel session. This AVP, 1918 along with the Tunnel-Client-Endpoint and Tunnel-Server-Endpoint 1919 AVPs, may be used to provide a means to uniquely identify a tunnel 1920 session for auditing purposes. 1922 The format of the identifier in this AVP depends upon the value of 1923 the Tunnel-Type AVP. For example, to fully identify an L2TP tunnel 1924 connection, the L2TP Tunnel ID and Call ID might be encoded in this 1925 field. The exact encoding of this field is implementation dependent. 1927 8.8 Acct-Tunnel-Packets-Lost AVP 1929 The Acct-Tunnel-Packets-Lost AVP (AVP Code 86) is of type Unsigned32 1930 and contains the number of packets lost on a given link. 1932 9.0 Interactions with Resource Management 1934 The Resource Management extension [31] provides the ability for a 1935 Diameter node to query a peer for session state information. The 1936 document states that service-specific extensions are responsible for 1937 specifying what AVPs are to be present in the Resource-Token [31] 1938 AVP. 1940 In addition to the AVPs listed in [31], the Resource-Token with the 1941 Extension-Id AVP set to one (1) MUST include the Service-Type AVP. In 1942 the event of a framed (PPP) user, the Framed-IP-Address and Framed- 1943 IPX-Network MUST be present if the corresponding network is being 1944 used. For Login users, the Login-IP-Host AVP and Login-Service AVP 1945 MUST be present. For tunneling users, the Tunnel-Type, Tunnel- 1946 Medium-Type, Tunnel-Client-Endpoint, and the Tunnel-Server-Endpoint 1947 AVPs MUST be present. 1949 10.0 RADIUS/Diameter Protocol Interactions 1951 This section describes some basic guidelines that may be used by 1952 servers that act as protocol gateways. Note that this document does 1953 not restrict implementations from creating other methods, as long as 1954 the bridging function doesn't break the RADIUS nor the Diameter 1955 protocol. 1957 There are essentially two different situations that must be handled; 1958 one where a RADIUS request is received that must be forwarded as a 1959 Diameter request, and the inverse. Note that this section uses two 1960 different terms; AVP and attribute. The former is used to signify a 1961 Diameter AVP, while the latter is used to signify a RADIUS attribute. 1963 10.1 RADIUS request forwarded as Diameter request 1965 This section describes the actions that should be followed when a 1966 protocol Gateway receives a RADIUS message that is to be translated 1967 to a Diameter message. 1969 It is important to note that RADIUS servers are inherently stateless, 1970 and this section maintains that assumption. It is quite possible for 1971 the RADIUS messages that comprises the session (i.e. authentication 1972 and accounting messages) be handled by different protocol gateways in 1973 the proxy network. Therefore a RADIUS->Diameter protocol gateway 1974 cannot maintain session state information. 1976 When a protocol gateway receives a RADIUS message, the following 1977 steps should be taken: 1979 - If the NAS-IP-Address attribute is present in the RADIUS 1980 message, the name MUST be translated to its corresponding FQDN, 1981 and encoded in the Diameter message's Origin-FQDN AVP. If the 1982 NAS-Identifier attribute is present, the data can be used in the 1983 Origin-FQDN AVP. 1984 - The Origin-FQDN AVP is added with the local server's identity. 1985 This will ensure that the corresponding response will be 1986 returned to the correct gateway server. 1987 - The Destination-Realm AVP is created from the information found 1988 in the RADIUS User-Name attribute. 1989 - The Gateway Server must maintain state information relevant to 1990 the RADIUS request, such as the Identifier field in the RADIUS 1991 header, any existing RADIUS Proxy-State attribute as well as the 1992 source IP address and port number of the UDP packet. These may 1993 be maintained locally in a state table, or may be saved in a 1994 Proxy-Info AVP. 1995 - If the Acct-Session-Id attribute was found in the request, the 1996 contents are inserted in the Acct-Session-Id AVP. 1997 - If the RADIUS request contained a Class or State attribute, and 1998 the prefix of the data is "Diameter/", the data following the 1999 prefix contains the Diameter Session-Id. If no such attributes 2000 are present, and the RADIUS command is an Access-Request, a new 2001 Session-Id is created. The Session-Id is included in the 2002 Session-Id AVP. 2003 - If the RADIUS message received is an Accounting-Request, with 2004 the Acct-Status-Type attribute set to STOP, the local server 2005 MUST issue a Session-Termination-Request message once the 2006 Diameter Accounting-Answer has been received. 2008 The corresponding Diameter response is always guaranteed to be 2009 received by the same protocol gateway that translated the original 2010 request, due to the contents of the Origin-FQDN AVP in the Diameter 2011 request. The following steps are applied to the response message 2012 during the Diameter to RADIUS translation: 2014 - If the Diameter Command-Code is set to AA-Challenge, the 2015 Diameter Session-Id and the Origin-FQDN AVPs are saved in the 2016 RADIUS State attribute, with the prefix "Diameter/". This is 2017 necessary in order to ensure that the protocol gateway that will 2018 receive the subsequent RADIUS Access-Request will have access to 2019 the Session Identifier, and be able to set the Destination-FQDN 2020 to the correct value. 2021 - If the Command-Code is set to AA-Answer, the Diameter Session-Id 2022 AVP is saved in a new RADIUS Class attribute, whose format 2023 consists of the string "Diameter/" followed by the Diameter 2024 Session Identifier. This will ensure that the subsequent 2025 Accounting messages, which could be received by any protocol 2026 gateway, would have access to the original Diameter Session 2027 Identifier. 2028 - If a Proxy-State attribute was present in the RADIUS request, 2029 the same attribute is added in the response. This information 2030 may be found in the Proxy-Info AVP, or in a local state table. 2031 - If state information regarding the RADIUS request was saved in a 2032 Proxy-Info AVP, the RADIUS Identifier and UDP IP Address and 2033 port number are extracted and used in issuing the RADIUS reply. 2035 10.2 Diameter request forwarded as RADIUS request 2037 When a server receives a Diameter request that is to be forwarded to 2038 a RADIUS entity, the following steps are an example of the steps that 2039 may be followed: 2041 - The Origin-FQDN AVP's value is inserted in the NAS-Identifier 2042 attribute. 2043 - The following information MUST be present in the corresponding 2044 Diameter response, and therefore MUST be saved either in a local 2045 state table, or it MAY be encoded in a RADIUS Proxy-State 2046 attribute: 2047 1. Origin-FQDN AVP 2048 2. Session-Id AVP 2049 3. Proxy-Info AVP 2050 4. Route-Record AVPs (in the proper order) 2051 5. Any other AVP that MUST be present in the response, and 2052 has no corresponding RADIUS attribute. 2054 When the corresponding response is received by the gateway server, 2055 which is guaranteed in the RADIUS protocol, the following steps may 2056 be followed: 2058 - If a Proxy-Info AVP is present, extract the encoded information, 2059 otherwise retrieve the information from the local state table. 2060 - The request's Origin-FQDN information is added to the 2061 Destination-FQDN AVP. 2062 - The Session-Id information is added to the Session-Id AVP. 2063 - The Route-Record AVPs MUST be added to the Diameter message, in 2064 the same order they were present in the request. 2065 - If a Proxy-Info AVP was present in the request, the same AVP MUST 2066 be added to the response. 2067 - If the RADIUS Class or State attributes are present, these 2068 attributes must be present in the Diameter response. 2069 - Any other AVPs that were saved, and MUST be present in the 2070 response, are added to the message. 2072 11.0 AVP Occurrence Table 2074 The following tables presents the AVPs defined in this document, and 2075 specifies in which Diameter messages they MAY, or MAY NOT be present. 2076 Note that AVPs that can only be present within a Grouped AVP are not 2077 represented in this table. 2079 The table uses the following symbols: 2080 0 The AVP MUST NOT be present in the message. 2081 0+ Zero or more instances of the AVP MAY be present in the 2082 message. 2083 0-1 Zero or one instance of the AVP MAY be present in the 2084 message. 2085 1 One instance of the AVP MUST be present in the message. 2087 11.1 NASREQ Command AVP Table 2089 The table in this section is limited to the Command Codes defined in 2090 this specification. 2092 +-----------------------------------+ 2093 | Command-Code | 2094 |-----+-----+-----+-----+-----+-----+ 2095 Attribute Name | AAR | AAA | ACI | DER | DEA | DEI | 2096 ------------------------------|-----+-----+-----+-----+-----|-----| 2097 ARAP-Challenge-Response | 0 | 0-1 | 0-1 | 0 | 0-1 | 0-1 | 2098 ARAP-Features | 0 | 0-1 | 0-1 | 0 | 0-1 | 0-1 | 2099 ARAP-Password | 0-1 | 0 | 0 | 0-1 | 0 | 0 | 2100 ARAP-Security | 0-1 | 0 | 0-1 | 0-1 | 0 | 0-1 | 2101 ARAP-Security-Data | 0+ | 0 | 0 | 0+ | 0 | 0 | 2102 ARAP-Zone-Access | 0 | 0-1 | 0 | 0 | 0-1 | 0 | 2103 Callback-Id | 0 | 0-1 | 0 | 0 | 0-1 | 0 | 2104 +-----------------------------------+ 2105 | Command-Code | 2106 |-----+-----+-----+-----+-----+-----+ 2107 Attribute Name | AAR | AAA | ACI | DER | DEA | DEI | 2108 ------------------------------|-----+-----+-----+-----+-----|-----| 2109 Auth-Extension-Id | 1 | 1 | 1 | 1 | 1 | 1 | 2110 Authorization-Lifetime | 0-1 | 0-1 | 0 | 0-1 | 0-1 | 0 | 2111 Callback-Number | 0-1 | 0-1 | 0 | 0-1 | 0-1 | 0 | 2112 Called-Station-Id | 0-1 | 0 | 0 | 0-1 | 0 | 0 | 2113 Calling-Station-Id | 0-1 | 0 | 0 | 0-1 | 0 | 0 | 2114 CHAP-Challenge | 0-1 | 0 | 0 | 0 | 0 | 0 | 2115 CHAP-Password | 0-1 | 0 | 0 | 0 | 0 | 0 | 2116 Class | 0 | 0+ | 0 | 0 | 0+ | 0 | 2117 Connect-Info | 0-1 | 0 | 0 | 0-1 | 0 | 0 | 2118 Destination-FQDN | 0+ | 1 | 1 | 0+ | 1 | 1 | 2119 Destination-Realm | 0 | 1 | 1 | 1 | 0 | 1 | 2120 EAP-Payload | 0 | 0 | 0 | 1 | 1 | 1 | 2121 Error-Reporting-FQDN | 0 | 0+ | 0+ | 0 | 0+ | 0 | 2122 Filter-Id | 0 | 0+ | 0 | 0 | 0+ | 0 | 2123 Filter-Rule | 0 | 0+ | 0 | 0 | 0+ | 0 | 2124 Framed-Appletalk-Link | 0 | 0-1 | 0 | 0 | 0-1 | 0 | 2125 Framed-Appletalk-Network | 0 | 0+ | 0 | 0 | 0+ | 0 | 2126 Framed-Appletalk-Zone | 0 | 0-1 | 0 | 0 | 0-1 | 0 | 2127 Framed-Compression | 0+ | 0+ | 0 | 0+ | 0+ | 0 | 2128 Framed-IP-Address | 0-1 | 0 | 0 | 0-1 | 0 | 0 | 2129 Framed-IP-Netmask | 0-1 | 0-1 | 0 | 0-1 | 0-1 | 0 | 2130 Framed-IP-Route | 0 | 0+ | 0 | 0 | 0+ | 0 | 2131 Framed-IPX-Network | 0 | 0-1 | 0 | 0 | 0-1 | 0 | 2132 Framed-MTU | 0 | 0-1 | 0 | 0 | 0-1 | 0 | 2133 Framed-Protocol | 0-1 | 0 | 0 | 0-1 | 0 | 0 | 2134 Framed-Routing | 0-1 | 0 | 0 | 0-1 | 0 | 0 | 2135 Idle-Timeout | 0-1 | 0-1 | 0 | 0-1 | 0-1 | 0 | 2136 Login-IP-Host | 0+ | 0+ | 0 | 0 | 0 | 0 | 2137 Login-LAT-Group | 0-1 | 0-1 | 0 | 0 | 0 | 0 | 2138 Login-LAT-Node | 0-1 | 0-1 | 0 | 0 | 0 | 0 | 2139 Login-LAT-Port | 0-1 | 0-1 | 0 | 0 | 0 | 0 | 2140 Login-LAT-Service | 0-1 | 0-1 | 0 | 0 | 0 | 0 | 2141 Login-Service | 0 | 0+ | 0 | 0 | 0 | 0 | 2142 Login-TCP-Port | 0 | 0+ | 0 | 0 | 0 | 0 | 2143 NAS-IP-Address | 1 | 0 | 0 | 1 | 0 | 0 | 2144 NAS-Port | 1 | 0 | 0 | 1 | 0 | 0 | 2145 NAS-Port-Type | 0-1 | 0 | 0 | 0-1 | 0 | 0 | 2146 Origin-FQDN | 1 | 1 | 1 | 1 | 1 | 1 | 2147 Origin-Realm | 1 | 1 | 1 | 1 | 1 | 1 | 2148 Password-Retry | 0 | 0-1 | 0 | 0 | 0 | 0 | 2149 Port-Limit | 0-1 | 0 | 0 | 0-1 | 0 | 0 | 2150 Prompt | 0 | 0 | 0-1 | 0 | 0 | 0 | 2151 Proxy-Info | 0+ | 0+ | 0+ | 0+ | 0+ | 0+ | 2152 Reply-Message | 0 | 0 | 0+ | 0 | 0 | 0 | 2153 +-----------------------------------+ 2154 | Command-Code | 2155 |-----+-----+-----+-----+-----+-----+ 2156 Attribute Name | AAR | AAA | ACI | DER | DEA | DEI | 2157 ------------------------------|-----+-----+-----+-----+-----|-----| 2158 Request-Type | 1 | 1 | 0 | 1 | 1 | 0 | 2159 Result-Code | 0 | 1 | 0 | 0 | 1 | 0 | 2160 Route-Record | 0+ | 0+ | 0+ | 0+ | 0+ | 0+ | 2161 Service-Type | 1 | 1 | 0 | 1 | 1 | 0 | 2162 Session-Id | 1 | 1 | 1 | 1 | 1 | 1 | 2163 Session-Timeout | 0 | 0-1 | 0 | 0 | 0-1 | 0 | 2164 State | 0-1 | 0-1 | 0-1 | 0 | 0-1 | 0 | 2165 Tunneling | 0+ | 0+ | 0 | 0+ | 0+ | 0 | 2166 User-Name | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 2167 User-Password | 0-1 | 0 | 0 | 0 | 0 | 0 | 2169 11.2 Accounting AVP Table 2171 The tables in this section are used to represent which AVPs defined 2172 in this document are to be present in the Accounting messages, 2173 defined in [1]. 2175 11.2.1 Framed Access 2177 The table in this section is used when the Service-Type specifies 2178 Framed Access. 2180 +-----------------------+ 2181 | Command-Code | 2182 |-----+-----+-----+-----+ 2183 Attribute Name | ACR | ACA | ASI | API | 2184 ------------------------------|-----+-----+-----+-----+ 2185 Accounting-Authentication-Type| 1 | 0-1 | 0 | 0 | 2186 Accounting-Input-Octets | 1 | 1 | 0 | 0 | 2187 Accounting-Input-Packets | 1 | 1 | 0 | 0 | 2188 Accounting-Output-Octets | 1 | 1 | 0 | 0 | 2189 Accounting-Output-Packets | 1 | 1 | 0 | 0 | 2190 Accounting-Session-Time | 1 | 1 | 0 | 0 | 2191 Accounting-State | 0 | 0 | 1 | 0 | 2192 Acct-Tunnel-Connection | 0-1 | 0-1 | 0 | 0 | 2193 Acct-Tunnel-Packets-Lost | 0-1 | 0-1 | 0 | 0 | 2194 Framed-AppleTalk-Link | 0-1 | 0-1 | 0 | 0 | 2195 Framed-AppleTalk-Network | 0-1 | 0-1 | 0 | 0 | 2196 Framed-AppleTalk-Zone | 0-1 | 0-1 | 0 | 0 | 2197 Framed-Compression | 0-1 | 0-1 | 0 | 0 | 2198 Framed-IP-Address | 0-1 | 0-1 | 0 | 0 | 2199 +-----------------------+ 2200 | Command-Code | 2201 |-----+-----+-----+-----+ 2202 Attribute Name | ACR | ACA | ASI | API | 2203 ------------------------------|-----+-----+-----+-----+ 2204 Framed-IP-Netmask | 0-1 | 0-1 | 0 | 0 | 2205 Framed-IPX-Network | 0-1 | 0-1 | 0 | 0 | 2206 Framed-MTU | 0-1 | 0-1 | 0 | 0 | 2207 Framed-Protocol | 0-1 | 0-1 | 0 | 0 | 2208 Framed-Route | 0-1 | 0-1 | 0 | 0 | 2209 Framed-Routing | 0-1 | 0-1 | 0 | 0 | 2210 Service-Type | 1 | 1 | 0 | 0 | 2211 Tunnel-Assignment-ID | 0-1 | 0-1 | 0 | 0 | 2212 Tunnel-Client-Endpoint | 0-1 | 0-1 | 0 | 0 | 2213 Tunnel-Medium-Type | 0-1 | 0-1 | 0 | 0 | 2214 Tunnel-Private-Group-ID | 0-1 | 0-1 | 0 | 0 | 2215 Tunnel-Server-Endpoint | 0-1 | 0-1 | 0 | 0 | 2216 Tunnel-Type | 0-1 | 0-1 | 0 | 0 | 2217 ------------------------------|-----+-----+-----+-----+ 2219 11.2.2 Non-Framed Access 2221 The table in this section is used when the Service-Type specifies 2222 Non-Framed Access. 2224 +-----------------------+ 2225 | Command-Code | 2226 |-----+-----+-----+-----+ 2227 Attribute Name | ACR | ACA | ASI | API | 2228 ------------------------------|-----+-----+-----+-----+ 2229 Accounting-Authentication-Type| 1 | 0-1 | 0 | 0 | 2230 Accounting-Input-Octets | 1 | 1 | 0 | 0 | 2231 Accounting-Input-Packets | 1 | 1 | 0 | 0 | 2232 Accounting-Output-Octets | 1 | 1 | 0 | 0 | 2233 Accounting-Output-Packets | 1 | 1 | 0 | 0 | 2234 Accounting-Session-Time | 1 | 1 | 0 | 0 | 2235 Accounting-State | 0 | 0 | 1 | 0 | 2236 Login-IP-Host | 0-1 | 0-1 | 0 | 0 | 2237 Login-LAT-Service | 0-1 | 0-1 | 0 | 0 | 2238 Login-LAT-Node | 0-1 | 0-1 | 0 | 0 | 2239 Login-LAT-Group | 0-1 | 0-1 | 0 | 0 | 2240 Login-LAT-Port | 0-1 | 0-1 | 0 | 0 | 2241 Login-Service | 0-1 | 0-1 | 0 | 0 | 2242 Login-TCP-Port | 0-1 | 0-1 | 0 | 0 | 2243 Service-Type | 1 | 1 | 0 | 0 | 2244 ------------------------------|-----+-----+-----+-----+ 2246 12.0 IANA Considerations 2248 This section contains the namespaces that have either been created in 2249 this specification, or the values assigned to existing namespaces 2250 managed by IANA. 2252 12.1 Command Codes 2254 This specification assigns the values 265, 267, 268 and 270 from the 2255 Command Code namespace defined in [2], and extended in [13] and [30]. 2256 See sections 3.1 and 4.2 for the assignment of the namespace in this 2257 specification. 2259 12.2 AVP Codes 2261 This specification assigns the values 400-403 from the AVP Code 2262 namespace defined in [2], and extended in [13] and [30]. See section 2263 2.1 for the assignment of the namespace in this specification. 2265 This specification also makes use of AVPs in the 0-255 range, which 2266 are defined in [34]. 2268 12.3 Request-Type AVP Values 2270 As defined in Section 2.1.1, the Request-Type AVP (AVP Code 401) 2271 defines the values 1-3. All remaining values are available for 2272 assignment via IETF Consensus [27]. 2274 12.4 Extension Identifier 2276 This specification assigns the value one (1) to the Extension 2277 Identifier namespace defined in [1]. See section 1.2 for more 2278 information. 2280 13.0 Security Considerations 2282 This document does not contain any security protocol, but does 2283 discuss how PPP authentication protocols can be carried within the 2284 Diameter protocol. The PPP authentication protocols that are 2285 described are PAP, CHAP and EAP. 2287 The use of PAP SHOULD be discouraged, since it exposes user's 2288 passwords to possibly non-trusted entities. PAP is also frequently 2289 used for use with One-Time Passwords (OTP), which does not expose any 2290 security risks. However, it is highly recommended that OTP be 2291 supported through the EAP protocol. 2293 This document also describes how CHAP can be carried within the 2294 Diameter protocol, which is required for backward RADIUS 2295 compatibility. The CHAP protocol, as used in a RADIUS environment, 2296 facilitates authentication replay attacks, and therefore SHOULD NOT 2297 be used when EAP is available. 2299 14.0 References 2301 [1] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote Authenti- 2302 cation Dial In User Service (RADIUS)", RFC 2865, June 2000. 2304 [2] Calhoun, Rubens, Akhtar, Guttman, "Diameter Base Protocol", 2305 draft-ietf-aaa-diameter-04.txt, IETF work in progress, May 2001. 2307 [3] Aboba, Beadles, "The Network Access Identifier." RFC 2486. Janu- 2308 ary 1999. 2310 [4] Aboba, Zorn, "Criteria for Evaluating Roaming Protocols", RFC 2311 2477, January 1999. 2313 [5] Hinden, R., Deering, S., "IP Version 6 Addressing Architecture", 2314 RFC 2373, July 1998 2316 [6] W. Simpson, "PPP Challenge Handshake Authentication Protocol 2317 (CHAP)", RFC 1994, August 1996. 2319 [7] Jacobson, "Compressing TCP/IP headers for low-speed serial 2320 links", RFC 1144, February 1990. 2322 [8] ISO 8859. International Standard -- Information Processing -- 2323 8-bit Single-Byte Coded Graphic Character Sets -- Part 1: Latin 2324 Alphabet No. 1, ISO 8859-1:1987. 2325 2327 [9] Sklower, Lloyd, McGregor, Carr, "The PPP Multilink Protocol 2328 (MP)", RFC 1717, November 1994. 2330 [10] Reynolds, J., Postel, J., "Assigned Numbers", STD 2, RFC 1700, 2331 October 1994 2333 [11] G. Zorn, B. Aboba, D. Mitton, "RADIUS Accounting Modifications 2334 for Tunnel Protocol Support", RFC 2867, June 2000. 2336 [12] S. Bradner, "Key words for use in RFCs to Indicate Requirement 2337 Levels", BCP 14, RFC 2119, March 1997. 2339 [13] P. Calhoun, W. Bulley, S. Farrell, "Diameter End-to-End Security 2340 Extension", draft-ietf-aaa-diameter-e2e-sec-02.txt, IETF work in 2341 progress, May 2001. 2343 [14] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W., 2344 Zorn, G., "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637, 2345 July 1999 2347 [15] Valencia, A., Littlewood, M., Kolar, T., "Cisco Layer Two For- 2348 warding (Protocol) 'L2F'", RFC 2341, May 1998 2350 [16] Townsley, W. M., Valencia, A., Rubens, A., Pall, G. S., Zorn, 2351 G., Palter, B., "Layer Two Tunneling Protocol (L2TP)", RFC 2661, 2352 August 1999 2354 [17] Hamzeh, K., "Ascend Tunnel Management Protocol - ATMP", RFC 2355 2107, February 1997 2357 [18] Kent, S., Atkinson, R., "Security Architecture for the Internet 2358 Protocol", RFC 2401, November 1998 2360 [19] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 2361 1996 2363 [20] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, 2364 October 1996 2366 [21] Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 2367 1827, August 1995 2369 [22] Hanks, S., Li, T., Farinacci, D., Traina, P., "Generic Routing 2370 Encapsulation (GRE)", RFC 1701, October 1994 2372 [23] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995 2374 [24] M. Beadles, D. Mitton, "Criteria for Evaluating Network Access 2375 Server Protocols", draft-ietf-nasreq-criteria-05.txt, IETF work 2376 in progress, June 2000. 2378 [25] L. J. Blunk, J. R. Vollbrecht, "PPP Extensible Authentication 2379 Protocol (EAP)." RFC 2284, March 1998. 2381 [26] G. Zorn, P. R. Calhoun, "Limiting Fraud in Roaming", draft- 2382 ietf-roamops-fraud-limit-00.txt, IETF work in progress, May 2383 1999. 2385 [27] Narten, Alvestrand, "Guidelines for Writing an IANA Considera- 2386 tions Section in RFCs", BCP 26, RFC 2434, October 1998 2388 [28] G. Zorn, D. Mitton, B. Aboba, "RADIUS Accounting Modifications 2389 for Tunnel Protocol Support", RFC 2867, June 2000. 2391 [29] F. Yergeau, "UTF-8, a transformation format of ISO 10646", RFC 2392 2279, January 1998. 2394 [30] P. Calhoun, C. Perkins, "Diameter Mobile IP Extensions", draft- 2395 ietf-aaa-diameter-mobileip-04.txt, IETF work in progress, May 2396 2001. 2398 [31] P. Calhoun, "Diameter Resource Management", draft-calhoun- 2399 diameter-res-mgmt-06.txt, IETF Work in Progress, February 2001. 2401 [32] C. Rigney, W. Willats, P. Calhoun, "RADIUS Extensions", RFC 2402 2869, June 2000. 2404 [33] G. Zorn, D. Leifer, A. Rubens, J. Shriver, M. Holdrege, I. Goy- 2405 ret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, 2406 June 2000. 2408 [34] IANA, "RADIUS Types", http://www.isi.edu/in- 2409 notes/iana/assignments/radius-types 2411 [35] C. Rigney, "RADIUS Accounting", RFC 2866, June 2000. 2413 [36] C. Rigney, W. Willats, P. Calhoun, "RADIUS Extensions", RFC 2414 2869, June 2000. 2416 [37] G. Zorn, D. Leifer, A. Rubens, J. Shriver, M. Holdrege, I. Goy- 2417 ret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, 2418 June 2000. 2420 15.0 Acknowledgements 2422 The authors would like to thank Carl Rigney, Allan C. Rubens, William 2423 Allen Simpson, and Steve Willens for their work on the original 2424 RADIUS, from which much of the concepts in this specification were 2425 derived from. Also Carl Rigney and Ward Willats for [32], and Glen 2426 Zorn, Dory Leifer, Allan C. Rubens, John Shriver, Matt Holdrege and 2427 Ignacio Goyret for their work on [33]. This document stole text and 2428 concepts from both [32] and [33]. 2430 The authors would also like to acknowledge the following people for 2431 their contribution in the development of the Diameter protocol: 2433 Bernard Aboba, Jari Arkko, William Bulley, Daniel C. Fox, Lol Grant, 2434 Nancy Greene, Peter Heitman, Paul Krumviede, Fergal Ladley, Ryan 2435 Moats, Victor Muslin, Kenneth Peirce, Sumit Vakil, John R. Vollbrecht 2436 and Jeff Weisberg 2438 16.0 Authors' Addresses 2440 Questions about this memo can be directed to: 2442 Pat R. Calhoun 2443 Network and Security Research Center, Sun Labs 2444 Sun Microsystems, Inc. 2445 15 Network Circle 2446 Menlo Park, California, 94025 2447 USA 2449 Phone: +1 650-786-7733 2450 Fax: +1 650-786-6445 2451 E-mail: pcalhoun@eng.sun.com 2453 William Bulley 2454 Merit Network, Inc. 2455 Building One, Suite 2000 2456 4251 Plymouth Road 2457 Ann Arbor, Michigan 48105-2785 2458 USA 2460 Phone: +1 734-764-9993 2461 Fax: +1 734-647-3185 2462 E-mail: web@merit.edu 2464 Allan C. Rubens 2465 Tut Systems, Inc. 2466 220 E. Huron, Suite 260 2467 Ann Arbor, MI 48104 2468 USA 2470 Phone: +1 734-995-1697 2471 E-Mail: arubens@tutsys.com 2473 Jeff Haag 2474 Cisco Systems 2475 7025 Kit Creek Road 2476 PO Box 14987 2477 Research Triangle Park, NC 27709 2479 Phone: 1-919-392-2353 2480 E-Mail: haag@cisco.com 2482 Glen Zorn 2483 Cisco Systems, Inc. 2484 500 108th Avenue N.E., Suite 500 2485 Bellevue, WA 98004 2486 USA 2488 Phone: +1 425 438 8218 2489 E-Mail: gwz@cisco.com 2491 17.0 Full Copyright Statement 2493 Copyright (C) The Internet Society (2001). All Rights Reserved. 2495 This document and translations of it may be copied and furnished to 2496 others, and derivative works that comment on or otherwise explain it 2497 or assist in its implementation may be prepared, copied, published 2498 and distributed, in whole or in part, without restriction of any 2499 kind, provided that the above copyright notice and this paragraph are 2500 included on all such copies and derivative works. However, this docu- 2501 ment itself may not be modified in any way, such as by removing the 2502 copyright notice or references to the Internet Society or other 2503 Internet organizations, except as needed for the purpose of develop- 2504 ing Internet standards in which case the procedures for copyrights 2505 defined in the Internet Standards process must be followed, or as 2506 required to translate it into languages other than English. The lim- 2507 ited permissions granted above are perpetual and will not be revoked 2508 by the Internet Society or its successors or assigns. This document 2509 and the information contained herein is provided on an "AS IS" basis 2510 and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS- 2511 CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 2512 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 2513 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 2514 FITNESS FOR A PARTICULAR PURPOSE. 2516 18.0 Expiration Date 2518 This memo is filed as and 2519 expires in October 2001.