idnits 2.17.1 draft-calhoun-diameter-framework-09.txt: -(235): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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? == There is 1 instance of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 31 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 32 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The 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 (February 2001) is 8471 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '14' is defined on line 1263, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 1266, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 1269, but no explicit reference was found in the text == Unused Reference: '25' is defined on line 1299, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2138 (ref. '1') (Obsoleted by RFC 2865) ** Obsolete normative reference: RFC 2486 (ref. '3') (Obsoleted by RFC 4282) ** Obsolete normative reference: RFC 2139 (ref. '4') (Obsoleted by RFC 2866) == Outdated reference: A later version (-08) exists of draft-calhoun-diameter-res-mgmt-07 == Outdated reference: A later version (-06) exists of draft-ietf-aaa-acct-05 ** Obsolete normative reference: RFC 2002 (ref. '7') (Obsoleted by RFC 3220) ** Obsolete normative reference: RFC 1825 (ref. '8') (Obsoleted by RFC 2401) ** Obsolete normative reference: RFC 2284 (ref. '10') (Obsoleted by RFC 3748) ** Obsolete normative reference: RFC 2572 (ref. '12') (Obsoleted by RFC 3412) ** Obsolete normative reference: RFC 3012 (ref. '15') (Obsoleted by RFC 4721) ** Obsolete normative reference: RFC 1409 (ref. '16') (Obsoleted by RFC 1416) ** Obsolete normative reference: RFC 2960 (ref. '24') (Obsoleted by RFC 4960) ** Obsolete normative reference: RFC 2560 (ref. '25') (Obsoleted by RFC 6960) == Outdated reference: A later version (-07) exists of draft-calhoun-diameter-strong-crypto-06 Summary: 18 errors (**), 0 flaws (~~), 12 warnings (==), 2 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: Informational Glen Zorn 5 Cisco Systems, Inc. 6 Ping Pan 7 Bell Labs 8 Haseeb Akhtar 9 Nortel Networks 10 February 2001 12 Diameter Framework Document 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at: 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at: 33 http://www.ietf.org/shadow.html. 35 This document is an individual contribution for consideration by the 36 AAA Working Group of the Internet Engineering Task Force. Comments 37 should be submitted to the diameter@diameter.org mailing list. 39 Distribution of this memo is unlimited. 41 Copyright (C) The Internet Society 1999. All Rights Reserved. 43 Abstract 45 Current Internet Service Providers (ISPs) scale their networks by 46 using the RADIUS protocol, which provides user Authentication, 47 Authorization and Accounting (AAA) of Dial-up PPP clients. The recent 48 work done in the Roaming Operations (ROAMOPS) Working Group was to 49 investigate whether RADIUS could be used in a roaming network, and 50 concluded that RADIUS was ill-suited for inter-domain purposes. 52 The IETF has formed a new NAS Requirements Working Group, and part of 53 their charter is to document the next generation NAS' AAA 54 requirements. Recently, the Mobile-IP Working Group also documented 55 their own AAA requirements that would help Mobile IP scale for 56 Inter-Domain mobility. 58 The Diameter protocol is a follow-on to the RADIUS protocol. Diameter 59 addresses the known RADIUS deficiencies, and is intended for use with 60 the NASREQ, ROAMOPS and Mobile IP application space. 62 Table of Contents 64 1.0 Introduction 65 1.1 Requirements language 66 1.2 Terminology 67 2.0 Problems to be addressed 68 2.1 Strict limitation of attribute data 69 2.2 Strict limitation on concurrent pending messages 70 2.3 Inability to control flow to servers 71 2.4 No retransmission procedure 72 2.5 End to end message acknowledgment 73 2.6 Heavy processing cost 74 2.7 Silent discarding of packets 75 2.8 Inefficient Server Fail-Over 76 2.9 Inefficient use of RADIUS servers in proxy environments 77 2.10 No unsolicited messages 78 2.11 Replay Attacks 79 2.12 Hop-by-Hop security 80 2.13 No support for vendor-specific commands 81 2.14 No alignment requirements 82 2.15 Mandatory Shared Secret 83 3.0 Diameter Architecture 84 3.1 Diameter Base Protocol 85 3.1.1 Proxy Support 86 3.1.2 Broker Support 87 3.2 Strong Security Extension 88 3.3 Mobile-IP Extension 89 3.4 NASREQ Extension 90 3.5 Accounting Extension 91 3.6 Resource Management 92 3.7 Diameter Command Naming Conventions 93 3.7.1 Request/Answer 94 3.7.2 Query/Response 95 3.7.3 Indication 96 4.0 Why not LDAP? 97 5.0 References 98 6.0 Acknowledgements 99 7.0 Author's Addresses 100 8.0 Full Copyright Statement 102 1.0 Introduction 104 Historically, the RADIUS protocol has been used to provide AAA 105 services for dial-up PPP [17] and terminal server access. Over time, 106 routers and network access servers (NAS) have increased in complexity 107 and density, making the RADIUS protocol increasingly unsuitable for 108 use in such networks. 110 The Roaming Operations Working Group (ROAMOPS) has published a set of 111 specifications [19, 20, 21] that define how a PPP user can gain 112 access to the Internet without having to dial into his/her home 113 service provider's modem pool. This is achieved by allowing service 114 providers to cross-authenticate their users. Effectively, a user can 115 dial into any service provider's point of presence (POP) that has a 116 roaming agreement with his/her home Internet service provider (ISP), 117 the benefit being that the user does not have to incur a long 118 distance charge while traveling, which can sometimes be quite 119 expensive. 121 Given the number of ISPs today, ROAMOPS realized that requiring each 122 ISP to set up roaming agreements with all other ISPs did not scale. 123 Therefore, the working group defined a "broker", which acts as an 124 intermediate server, whose sole purpose is to set up these roaming 125 agreements. A collection of ISPs and a broker is called a "roaming 126 consortium". There are many such brokers in existence today; many 127 also provide settlement services for member ISPs. 129 The Mobile-IP Working Group has recently changed its focus to inter 130 administrative domain mobility, which is a requirement for cellular 131 carriers wishing to deploy IETF-based mobility protocols. The current 132 cellular carriers requirements [22, 23] are very similar to the 133 ROAMOPS model, with the exception that the access protocol is 134 Mobile-IP [2] instead of PPP. 136 The Diameter protocol was not designed from the ground up. Instead, 137 the basic RADIUS model was retained while fixing the flaws in the 138 RADIUS protocol itself. Diameter does not share a common protocol 139 data unit (PDU) with RADIUS, but does borrow sufficiently from the 140 protocol to ease migration. 142 The basic concept behind Diameter is to provide a base protocol that 143 can be extended in order to provide AAA services to new access 144 technologies. Currently, the protocol only concerns itself with 145 Internet access, both in the traditional PPP sense as well as taking 146 into account the ROAMOPS model, and Mobile-IP. 148 Although Diameter could be used to solve a wider set of AAA problems, 149 we are currently limiting the scope of the protocol in order to 150 ensure that the effort remains focussed on satisfying the 151 requirements of network access. Note that a truly generic AAA 152 protocol used by many applications might provide functionality not 153 provided by Diameter. Therefore, it is imperative that the designers 154 of new applications understand their requirements before using 155 Diameter. 157 1.1 Requirements language 159 In this document, the key words "MAY", "MUST", "MUST NOT", 160 "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be 161 interpreted as described in [9]. 163 1.2 Terminology 165 Accounting 166 The act of collecting information on resource usage for the 167 purpose of trend analysis, auditing, billing, or cost allocation. 169 Authentication 170 The act of verifying the identity of an entity (subject). 172 Authorization 173 The act of determining whether a requesting entity (subject) will 174 be allowed access to a resource (object). 176 AVP 177 The Diameter protocol consists of a header followed by one or more 178 Attribute-Value-Pair (AVP). The AVP includes a header and is used 179 to encapsulation authentication, authorization or accounting 180 information. 182 Broker 183 A broker is a business term commonly used in AAA infrastructures. 184 A broker is either a proxy or redirect server, and MAY be operated 185 by roaming consortiums. 187 Diameter Client 188 A Diameter Client is a device at the edge of the network that 189 performs access control. An example of a Diameter client is a 190 Network Access Server (NAS) or a Foreign Agent (FA). 192 Diameter Server 193 A Diameter server is a device that is not acting as a NAS or FA. 194 Servers can be proxy, redirect, or home servers 196 Downstream Server 197 Diameter Proxy servers identify a downstream server as one that is 198 providing routing services towards the home server for a 199 particular message. 201 Home Domain 202 A Home Domain is the administrative domain with whom the user 203 maintains an account relationship. 205 Home Server 206 A Diameter Home Server is one that authenticates and/or authorizes 207 access for users of a particular realm. The same server MAY also 208 act as a proxy or redirect server for other realms, in which case 209 it is not acting as a Home Server for these realms. 211 Integrity Check Value (ICV) 212 An Integrity Check Value is an unforgeable or secure hash of the 213 message with a shared secret. 215 Interim accounting 216 An interim accounting message provides a snapshot of usage during 217 a user's session. It is typically implemented in order to provide 218 for partial accounting of a user's session in the event of a 219 device reboot or other network problem that prevents the reception 220 of a session summary message or session record. 222 Local Domain 223 A local domain is the administrative domain providing services to 224 a user. An administrative domain MAY act as a local domain for 225 certain users, while being a home domain for others. 227 Network Access Identifier 228 The Network Access Identifier, or NAI [3], is used in the Diameter 229 protocol to extract a user's identity and realm. The identity is 230 used to identify the user during authentication and/or 231 authorization, while the realm is used for message routing 232 purposes. 234 Proxy Server 235 A proxy server �ses the realm portion of the NAI to route Diameter 236 messages. Proxy servers are typically used to minimize the number 237 of security relationships that are required between Diameter 238 servers. 240 Realm 241 The string in the NAI that immediately follows the '@' character. 242 NAI realm names are required to be unique, and are piggybacked on 243 the administration of the DNS namespace. Diameter makes use of the 244 realm, also loosely referred to as domain, to determine whether 245 messages can be satisfied locally, or whether they must be 246 proxied. 248 Real-time Accounting 249 Real-time accounting involves the processing of information on 250 resource usage within a defined time window. Time constraints are 251 typically imposed in order to limit financial risk. 253 Redirect Server 254 A Diameter redirect server provides realm to address translation, 255 by returning information necessary for Diameter peers to 256 communicate directly. Redirect servers are different from proxies 257 since they do not participate in the routing of messages between 258 end Diameter nodes. 260 Roaming Relationships 261 Roaming relationships include relationships between companies and 262 ISPs, relationships among peer ISPs within a roaming association, 263 and relationships between an ISP and a roaming consortia. 264 Together, the set of relationships forming a path between a local 265 ISP's authentication proxy and the home authentication server is 266 known as the roaming relationship path. 268 Session 269 The Diameter protocol is session based. When an authorization 270 request is initially transmitted, it includes a session identifier 271 that is used for the duration of the session. The Session- 272 Identifier AVP contains the identifier and must be globally 273 unique. 275 Session record 276 A session record represents a summary of the resource consumption 277 of a user over the entire session. Accounting gateways creating 278 the session record may do so by processing interim accounting 279 events or accounting events from several devices serving the same 280 user. 282 Upstream Server 283 Diameter Proxy servers identify an upstream server as one that is 284 providing routing services towards the Diameter client. 286 2.0 Problems to be addressed 288 The RADIUS protocol was designed in the early 1990's as an attempt to 289 solve a scaling problem associated with dial-in and telnet servers. 290 Over time the networks became more complex (e.g. roaming networks) 291 and the Network Access Servers (NAS) increased in complexity and 292 density. These changes combined with a massive deployment of the 293 protocol uncovered some fundamental issues with the protocol that 294 needed to be fixed. The Diameter protocol was designed as a next 295 generation RADIUS protocol, designed with roaming and high density 296 NASes in mind. 298 This section will describe the documented, and undocumented, RADIUS 299 problems known today. Further sections will describe how the Diameter 300 protocol addresses each one of these problems. 302 2.1 Strict limitation of attribute data 304 One of problems that RADIUS suffers from is its inherent limitation 305 on the length of attribute data. This limitation is imposed by the 306 fact that the protocol's attribute header only reserves one byte for 307 the length field. The RADIUS protocol does specify that larger data 308 can be spanned across multiple attributes, however doing so 309 introduces a new set of problems. The RADIUS protocol also allows 310 multiple attributes of the same type to be included within a message. 311 Therefore, it is difficult for a RADIUS server, or client, to 312 determine whether multiple identical attributes are in fact multiple 313 independent attributes, or a single fragmented attribute. 315 2.2 Strict limitation on concurrent pending messages 317 The RADIUS protocol states that the identifier field, found within 318 the header, is used to identify retransmissions. This one byte field 319 imposes a strict limitation on the number of requests that can be 320 pending at any given time to 255. In the early 1990's, this number 321 was sufficient, but the increased density of most NASes today make 322 the protocol nearly unusable. Later versions of the protocol 323 specification attempts to solve this problem by making use of 324 multiple UDP ports, and making use of as many ports as necessary to 325 ensure that no more than 255 simultaneous requests are pending. 327 The RADIUS protocol also requires that retransmitted request, which 328 include changes to the packet, include a new value in the Identifier 329 field. Note that most retransmissions do include updated information, 330 and therefore typically require a new Identifier field. This further 331 reduces the number of sessions that can be supported by the 332 Identifier field. 334 2.3 Inability to control flow to servers 335 Given the rather bursty nature of the RADIUS protocol, current 336 servers have no way of properly managing their receive buffers. This 337 is in part due to the fact that RADIUS operates over UDP, and does 338 not include any windowing support. This has been known to cause 339 large bursts of requests to be directed to a server, which can burden 340 a server's ability to respond in a timely manner. This problem is 341 most prevalent in cases where a server becomes unavailable and all 342 requests must be sent to an alternate server, or when an ingress port 343 on the NAS becomes available (e.g. T3 port on NAS). 345 2.4 No retransmission procedure 347 Given that the RADIUS protocol requires that the Identifier field be 348 changed in retransmissions that have updated information, RADIUS 349 server developers have had to design clever tricks to identify 350 retransmissions. One common method is to cache all packets received 351 in a time window (e.g. 60 seconds). When such servers receive a 352 packet, it compares the contents of certain attributes, which are 353 know to be static across retransmissions, with corresponding 354 attributes in all packets in the cache. When a match is found, a 355 retransmission has been detected. This burden placed on RADIUS 356 servers add additional latency, which may cause NAS retransmissions 357 (see Section 2.5). 359 2.5 End to end message acknowledgment 361 The RADIUS protocol requires that a NAS retransmit a request until a 362 successful or failed response is received, and does not permit a 363 RADIUS server to retransmit a response. Since RADIUS servers 364 typically have to perform a database lookup to authenticate the user, 365 such operations MAY be lengthy, and cause the NAS to assume that the 366 request was never received, and retransmit (causing further 367 congestion). 369 In cases when proxy servers are used, retransmissions are even more 370 likely since each proxy must identify retransmissions, validate the 371 request, optionally impose some local policy decision, and forward to 372 the downstream server. 374 2.6 Limited server failure detection 376 The RADIUS protocol, operating over UDP, does not provide a clear 377 method for a NAS to detect whether the lack of a response for a given 378 request is the result of congestion, or server failure. In networks 379 that do not employ proxies, this is not an issue. However, in 380 networks that do make use of proxies, the lack of a response MAY not 381 be a local problem, but a problem with a downstream or home server. 382 The NAS does not have a mechanism to identify that the local server 383 is still available, and MUST retransmit all pending requests to an 384 alternate server, including those destined for different downstream 385 or home servers. This places a burden not only on the offending home 386 server, but also on the NAS, proxies and all other home servers that 387 will receive retransmissions. 389 2.7 Silent discarding of packets 391 The RADIUS protocol states that messages that do not contain the 392 expected information, or messages that have errors are silently 393 discarded. Silently discarding messages causes the NAS to assume that 394 the local RADIUS server is no longer reachable, and causes it to 395 retransmit all pending requests to alternate servers (see Section 396 2.6). Such messages will be retransmitted to alternate servers, and 397 again silently discarded, and so on. This will occur until the NAS 398 abandons the request. 400 2.8 Inefficient Server Fail-Over 402 Most NAS implementations support a number of RADIUS servers, 403 consisting of a primary server with a set of alternate servers. When 404 the NAS detects that the primary can no longer be used, all pending 405 messages are transmitted to an alternate server. When the alternate 406 is not available, the next alternate server in the list is used. 408 Given that the RADIUS server operates over UDP, and has no watchdog 409 mechanism, the NAS has no way to know in advance whether an alternate 410 server is reachable. Therefore, if two or more consecutive servers in 411 the server list are unavailable, denial of service to users can be 412 very lengthy. 414 2.9 Inefficient use of RADIUS servers in proxy environments 416 As previously mentioned, NASes have no method of knowing whether the 417 lack of a response is due to a failure on the local, downstream 418 proxies, or the home server. Further, servers do not retransmit 419 RADIUS requests on behalf of the NAS. Therefore, should a primary 420 home server become unavailable, the local server does not retransmit 421 to an alternate server in the home network, but rather waits for the 422 NAS to timeout and retransmit to the local alternate server, 423 requiring parallel links between servers (see figure 1). 425 Local ISP Home ISP 426 +--------+ +--------+ 427 | Primary| | Primary| 428 +-------+ | Proxy |----------->| Home | 429 | |----------->| Server | | Server | 430 |Network| +--------+ +--------+ 431 |Access | 432 |Server | +--------+ +--------+ 433 | |----------->| 2 nd | | 2 nd | 434 +-------+ | Proxy |----------->| Home | 435 | Server | | Server | 436 +--------+ +--------+ 438 Figure 1: RADIUS Proxy Network 440 Take an example where an ISP issues two authentication requests, one 441 for abc.net and another for xyz.com. Let's also assume that abc.net's 442 primary server is down, while xyz's 2nd server is down. Should such a 443 problem occur, all requests for abc.net would cause the NAS to switch 444 to the local ISP's 2nd server, while all requests to xyz.net would 445 cause the NAS to switch back to the local ISP's primary server. 447 2.10 No unsolicited messages 449 The RADIUS protocol does not allow a server to send unsolicited 450 messages to the NAS. As network services became more complex, this 451 limitation has forced manufacturers to deviate from the RADIUS 452 protocol, causing interoperability problems. Server initiated 453 messages are typically used for accounting purposes and to request 454 that a NAS terminate a specific user session. 456 2.11 Replay Attacks 458 Although RADIUS messages contain hop-by-hop authentication, the 459 protocol does not include any replay attack prevention. This means 460 that a malfunctioning server, or malicious user, can replay an old 461 packet without detection. For servers that maintain state 462 information, such as those that limit the number of concurrent 463 sessions for a given user, a denial of service is very simple by 464 replaying old RADIUS messages. For other servers, this problem is 465 limited to duplicate accounting messages. 467 2.12 Hop-by-Hop security 469 The RADIUS protocol uses hop-by-hop security, which means that every 470 hop in a RADIUS proxy network adds authentication data that is used 471 by the next peer in the chain. RADIUS has no facility for securing 472 the message between the NAS and the home server, eliminating the 473 ability for proxy servers to modify critical components in messages. 474 This has caused opportunities for fraud in RADIUS networks, since 475 intermediate nodes can easily modify information (e.g. accounting 476 information), and such events are difficult to traceable. 478 2.13 No support for vendor-specific commands 480 Although the RADIUS protocol does support vendor-specific attributes, 481 it does not allow for vendor-specific commands. This has forced 482 vendors to abuse the address space, creating interoperability 483 problems in mixed vendor environments. 485 2.14 No alignment requirements 487 Unlike most newer IETF protocols, the RADIUS protocol does not impose 488 any alignment requirements, which adds an unnecessary burden on most 489 processors. All fields within the header and attributes must be 490 treated as byte aligned characters. 492 2.15 Mandatory Shared Secret 494 The RADIUS protocol requires that a shared secret exists between two 495 peers. Therefore, even if IP Security was deployed to secure to 496 communication, the shared secret would still be required. 498 3.0 Diameter Architecture 500 The Diameter architecture consists of a base protocol and a set of 501 protocol extensions (such as strong security, NASREQ, Mobile-IP and 502 accounting). Functionality common to all supported services is 503 implemented in the base protocol, while application-specific 504 functionality may be provided through the extension mechanism. 506 The base protocol [18] must be supported for all Diameter 507 applications, and defines the basic PDU format, a few primitives and 508 the basic security services offered by the protocol. Unlike RADIUS, 509 the Diameter protocol operates over SCTP [24], which provides 510 reliability and an well defined retransmission and timeout mechanism. 511 Additionally, Diameter defines a fail-over strategy, which is lacking 512 in the RADIUS protocol. SCTP provides a windowing scheme, which 513 allows the AAA servers to limit the flow of incoming packets. This 514 can then be used by the AAA clients to distribute the traffic load 515 across multiple servers. The transport layer's retransmission and 516 timeout timers allow clients and servers to detect the reachability 517 state of peers, allowing for quick transition to back-up servers. 519 As previously discussed, the ROAMOPS model introduces the proxy, or 520 broker, which acts as an intermediate server forwarding requests to 521 user's home ISPs. ROAMOPS also described a set of attacks that one 522 could mount if such a network was built using the RADIUS protocol 523 [21]. In order to provide secure broker services, security between 524 the NAS and the home server is required at the application layer, 525 preventing such servers from modifying contents of RADIUS messages. 527 The Diameter Strong Security Extension defines a set of extensions to 528 the base protocol that provide authentication, confidentiality and 529 non-repudiation at the Attribute-Value-Pair (AVP) level. With these 530 extensions, it is possible to secure portions of a Diameter message, 531 while other parts of the message are not secured. Secured objects are 532 called protected AVPs; non-secured objects are called unprotected 533 AVPs. Using Diameter, proxies can add, delete or modify unprotected 534 AVPs in a message. 536 The RADIUS protocol provides dial-up PPP AAA services by providing 537 three commands and many Attributes. Attributes in RADIUS are 538 analogous to AVPs in Diameter. In order to ease migration from RADIUS 539 to Diameter, the first 256 AVPs in the Diameter AVP space are 540 reserved for RADIUS compatibility. This allows both protocols to 541 share a common dictionary and policy rules for PPP user profiles. 543 The RADIUS protocol has support for the Extensible Authentication 544 Protocol (EAP) [10], but RADIUS' lack of support for large attributes 545 and its inherent unreliability has made the integration of the 546 protocols very difficult. 548 The Diameter NASREQ Extension defines a set of 549 authentication/authorization commands, which can be used for CHAP, 550 PAP and EAP. Diameter's support for larger AVPs and the SCTP 551 transport properties have made the use of EAP much more palatable, 552 allowing for end-to-end user authentication, which reduces many of 553 authentication replay attacks known to exist with CHAP and PAP. 555 Unlike PPP, Mobile-IP hosts do not have a long-lived "nailed-up" 556 connection to a PPP server, but rather get service from routers that 557 provide service in a particular cell. In the Mobile-IP world, the 558 router is known as a Foreign Agent, while the moving hosts are known 559 as Mobile Nodes. The mobile node's home network has a host that 560 forwards all messages destined to the mobile node through the Foreign 561 Agent. This router is commonly referred to as the Home Agent. 563 Mobile-IP [7] allows the mobile nodes to move from one cell (subnet) 564 to another while retaining the same IP address, minimizing the impact 565 to applications. Although the Mobile-IP protocol could be deployed in 566 a small network with any AAA services, a larger network suffers from 567 many scaling issues such as: 569 - Static mobile node home address 570 - Static mobile node home agent 571 - Requirement to pre-configure mobile node profile on home agents 572 - No inter-domain mobility 574 Both PPP and Mobile-IP require that usage data be collected for uses 575 such as capacity planning and for accounting purposes. The current 576 standard protocol for accounting is SNMP [12], but experience 577 indicates that SNMP often is not the correct protocol for service 578 accounting. Today many applications and services use RADIUS 579 accounting [4] as their accounting protocol, however the RADIUS 580 accounting protocol is not an IETF standard; in addition, it suffers 581 from similar scaling and security problems. The Diameter accounting 582 extension [11] is designed to allow accounting information to be sent 583 across administrative domains (optionally through brokers), and has 584 been derived from an accounting requirements document [6, 8]. 586 +-----------+ 587 | Mobile-IP | 588 | | 589 | Extension | 590 +-----------+ 591 +-----------+ ^ +------------+ 592 | NASREQ | | | Accounting | 593 | | | | | 594 | Extension | | | Extension | 595 +-----------+ | +------------+ 596 ^ | ^ 597 | | | 598 v v v 599 +----------------------------------+---------------------+ 600 | | | 601 | Diameter Base Protocol | Strong Security | 602 | | | 603 +----------------------------------+---------------------+ 604 Figure 2: Diameter Protocol Architecture 606 3.1 Diameter Base Protocol 608 The Base Protocol defines the Diameter message format, a set of 609 primitives and how the messages are transmitted in a secure fashion. 611 The Base Protocol assumes a peer-to-peer communication model, as 612 opposed to a client-server model. The following goals motivated the 613 design of the base protocol: 615 - lightweight and simple to implement protocol 616 - Large AVP space 617 - Efficient encoding of attributes, similar to RADIUS 618 - Support for vendor specific AVPs and Commands 619 - Support for large number of simultaneous pending requests 620 - Reliability provided by underlying SCTP 621 - Well-defined fail-over scheme 622 - Ability to quickly detect unreachable peers 623 - No silent message discards 624 - Support of unsolicited messages to "clients" 625 - integrity and confidentiality at the AVP level 626 - Hop-by-Hop security 627 - One session per authentication/authorization flow 628 - Provide redirect (referal) services, to allow bypassing of 629 broker 631 The Diameter base protocol is intended to simply provide a secure 632 transport for the messages defined in the various application- 633 specific extensions. It is therefore imperative that the base be 634 lightweight and simple to implement. 636 In the Diameter protocol, data objects are encapsulated within the 637 Attribute Value Pair (AVP). An AVP consists of three parts: the 638 Identifier, Length and Data. A unique AVP Identifier is assigned to 639 all data objects in order to be able to distinguish the data 640 contained. The AVP Identifier namespace must be sufficiently large to 641 ensure that future protocol extensibility is not limited by the size 642 of the namespace, as in the RADIUS protocol. Furthermore, vendors 643 wishing to add "proprietary" extensions must be allowed to do so by 644 using a vendor-specific namespace, managed by IANA. 646 For many years the question as to whether RADIUS should operate over 647 UDP or TCP has led to heated discussion. It must be determined 648 whether the benefits that UDP provides are worth the implementation 649 complexities. Over time, it has become clear that these benefits are 650 well worth the cost. The issue with TCP is that an AAA protocol 651 requires a quick retransmission and fail-over scheme, which TCP 652 cannot provide. The Diameter protocol must be able to operate over a 653 transport that has an aggressive retransmission strategy in order to 654 efficiently switch to an alternate host when the peer in question is 655 no longer reachable. 657 Contrary to RADIUS, the Diameter protocol requires that each node in 658 a proxy chain acknowledge a request, or response, at the "transport" 659 layer. Since Diameter operates over SCTP, which provides a reliable 660 transport, each node in a proxy chain is responsible for 661 retransmission of unacknowledged messages. 663 The SCTP transport provides retransmission detection, which greatly 664 simplifies server implementations, and consequently allows a given 665 server to support a much larger number of transactions per second. 666 SCTP also provides windowing, which allows the flow of packets to a 667 specific server to be controlled. Clever implementations can then 668 decide to send the packets to an alternate server that can handle the 669 load. 671 With the exception of a few security related errors, the Diameter 672 protocol requires that all messages be acknowledged, either with a 673 successful response or one that contains an error code. 675 Where the RADIUS protocol is client-server, the Diameter protocol is 676 peer to peer, allowing unsolicited messages to be sent to NASes. 677 There are many benefits to peer-to-peer AAA protocols. One example is 678 the on-demand retrieval of accounting data; another, server-initiated 679 session termination. 681 The Base Diameter protocol provides for hop-by-hop security, similar 682 to the scheme employed by RADIUS today. However, the Diameter 683 protocol also provides for replay protection through a timestamp 684 mechanism. This security scheme requires a long lived security 685 association to be established by peers, or can make use of keying 686 material negotiated out of band. The Base Protocol also allows the 687 built-in security measure to be turned off, (i.e., in cases where 688 IPSec is in use). 690 The Diameter protocol is a session-oriented protocol, meaning that 691 for each user being authenticated, there exists a session between the 692 initiator of the authentication/authorization request and the home 693 Diameter server. Sessions are identified through a session 694 identifier, which is globally unique at any given time. All 695 subsequent Diameter transactions (e.g. accounting) must include the 696 session identifier to reference the session. A Session termination 697 message exists in order to end a Diameter session, and all sessions 698 have a timeout value in order to ensure that they can be cleaned up 699 properly. 701 Since today's processors work more efficiently when objects are 702 aligned on a 32-bit boundary, the Diameter protocol requires 32-bit 703 alignment of all headers and the data. This has recently become a 704 common requirement for many new protocols at the IETF. 706 3.1.1 Proxy Support 708 The Diameter protocol was designed from the beginning to support 709 roaming networks. This means that every node in the network is 710 responsible for it's own retransmissions, and the protocol does allow 711 each node to know a priori the reachability state of each peer. This 712 allows for a resilient network, and efficient retransmission scheme. 713 Figure 3 depicts a network where each Diameter server can communicate 714 with all other servers. 716 Figure 3 depicts an example of a Diameter network that includes two 717 proxy servers in the local network for resilience. Once a message has 718 been sent from the NAS to one of its local proxy servers, they are 719 responsible for any retransmissions of the message to one of the home 720 servers. Since the underlying transport provides quick peer failure 721 detection, upon such notification, the local proxies can quickly 722 transmit the message to the alternate peer in the home network. 724 Figure 3 depicts an example of a proxy network that includes 725 alternate servers for resilience. Each node in the proxy chain is 726 responsible for its own retransmissions and fail-over detection. 727 This provides the following benefits: 729 - The number of Diameter nodes in the network is greatly reduced 730 - The latency involved in switch-over to an alternate peer is 731 greatly reduced 732 - Reliability is increased 734 local ISP Home ISP 735 +--------+ +--------+ 736 | Primary| | Primary| 737 +-------+ | Proxy |------------>| Home | 738 | |----------->| Server |<-----+----->| Server | 739 |Network| +--------+ | +--------+ 740 |Access | | 741 |Server | +--------+ | +--------+ 742 | |----------->| 2 nd |<-----+----->| 2 nd | 743 +-------+ | Proxy |------------>| Home | 744 | Server | | Server | 745 +--------+ +--------+ 747 Figure 3: Diameter Proxy Network 749 3.1.2 Redirect Support 751 A redirect server is one that provides simple Diameter message 752 "routing" functions. Redirect servers are generally deployed in order 753 to reduce the configuration information that would otherwise be 754 necessary on all servers owned members of a roaming consortium. 756 Redirect servers allow Diameter entities to communicate directly by 757 providing NAI realm to home server translation services. When a 758 request is received by a redirect server, a redirect response is 759 returned to the initiator of the request with the information 760 necessary to communicate directly with servers in the home domain. 762 A broker, owned by a roaming consortium, MAY also provide Certificate 763 Authority services, by issuing certificates to all Diameter servers 764 within the consortium (or alternatively sign existing certificates). 765 This eliminates the need for long lived shared secrets between 766 Diameter servers, and enables protocols such as IP Security to be 767 used. In the event that non repudiation is required, public key 768 cryptography can be used to sign usage information in accounting 769 messages. 771 If deemed necessary, a redirect server MAY include the home server's 772 certificates in the redirect response to the requesting Diameter 773 server. 775 +------------------+ +---------+ 776 | Redirect | | CRL DB/ | 777 | Server | | OCSP | 778 +------------------+ +---------+ 779 ^ 780 Request | Response with 781 | Result Code = 782 | Redirect 783 v 784 +----------+ +----------+ 785 | Local | | Home | 786 | Diameter |<------------>| Diameter | 787 | Server | | Server | 788 +----------+ Direct +----------+ 789 Communication 790 Figure 4: Diameter Broker Returning Redirect Indication 792 It is important to note that redirect servers MAY forbid direct 793 communication of accounting messages. This may be required in cases 794 where the server needs such information to provide such services as 795 auditing and settlement services. Such servers MAY also required that 796 both parties sign accounting messages in a serial fashion, as 797 specified in [26]. 799 3.2 Strong Security Extension 800 The Diameter base protocol allows Diameter servers to communicate 801 securely, using hop-by-hop authentication. Hop-by-hop authentication 802 means that the requesting server has secure communication with a 803 proxy or redirect server, and the proxy has secure communicate with 804 the home server. 806 The Strong Security extension [26] provides strong authentication of 807 selective AVPs, which MAY be used for repudiation purposes. This 808 extension also allows for secure communication through intermediate 809 Diameter proxies. 811 The extension achieves this functionality by allowing the 812 Cryptographic Message Syntax (CMS) S/MIME object to be encapsulated 813 within a Diameter AVP. The CMS object MAY be used for authentication, 814 confidentiality and to carry certificates and certificate revocation 815 lists (CRLs). The extension also provides for multi-party signatures, 816 which is useful in environments where two or more parties must sign 817 information, such as an accounting record. 819 Diameter clients (e.g. NAS, FA) aren't required to implement strong 820 security. It is possible for the local Proxy server to provide this 821 functionality, and MAY require that strong security only be used when 822 messages traverse administrative domain boundaries. 824 The strong security extension MUST only be used in networks that 825 include a Public Key Infrastructure (PKI). 827 3.3 Mobile-IP Extension 829 The Mobile-IP protocol is used to manage mobility of an IP host 830 across IP subnets [7]. Recent activity within the Mobile-IP Working 831 Group has defined the interaction between Mobile-IP and AAA in order 832 to provide: 834 - Better scaling of security associations 835 - Mobility across administrative domain boundaries 836 - Dynamic home agent assignment 838 The Mobile IP protocol [7] works well when all mobile nodes belong to 839 the same administrative domain. Some of the current work within the 840 Mobile IP Working Group is to allow Mobile IP to scale across 841 administrative domains. This work requires modifications to the 842 existing Mobile IP trust model. 844 Figure 5 depicts the Diameter trust model for Mobile-IP. In this 845 model each network contains mobile nodes (MN) and a Diameter server. 846 Each mobility device shares a security association (SA) with the 847 Diameter server within its own home network. This means that none of 848 the mobility devices initially share a security association. The 849 Diameter servers in both administrative domains can either share a 850 direct security association, or can have a security association with 851 an intermediate proxy. 853 Proxy AAA 854 +--------+ 855 | | 856 |Diameter| 857 +------->| |<------+ 858 | +--------+ | 859 Local | SA SA | Home 860 AAA v v AAA 861 +--------+ +--------+ 862 | | SA4 | | 863 |Diameter|=======================|Diameter| 864 | |(when no proxy is used)| | 865 +--------+ +--------+ 866 ^ ^ ^ 867 | | | 868 SA1 | SA2 | | SA3 869 | | | 870 v v v 871 +--------+ +--------+ +--------+ 872 | | | | | | 873 | FA | | MN | | HA | 874 | | | | | | 875 +--------+ +--------+ +--------+ 876 Figure 5 - Mobile-IP AAA Trust Model 878 Figure 6 provides an example of a Mobile-IP network that includes 879 Diameter. In the integrated Mobile-IP/Diameter Network, it is assumed 880 that each mobility agent shares a security association between itself 881 and its local Diameter server. Further, the Home and Local Diameter 882 servers both share a security association with the broker's Diameter 883 server. Lastly, it is assumed that each mobile node shares a trust 884 relationship with its home Diameter Server. 886 Local Access Broker Home IP 887 Provider Network Network Network 888 +--------+ +--------+ +--------+ 889 | | | | | | 890 |Diameter|<---->|Diameter|<---->|Diameter| 891 | | | | | | 892 +--------+ +--------+ +--------+ 893 ^ ^ 894 | | 895 AAA | | AAA 896 | | 897 v v 898 +---------+ +---------+ 899 | | | | 900 | FA | | HA | 901 | | | | 902 +---------+ +---------+ 903 ^ 904 | Home Network 905 | -Private Network 906 Mobile | -Home Provider 907 IP | -Home ISP 908 v 909 +--------+ 910 | Mobile | 911 | Node | 912 +--------+ 913 Figure 6 - General Wireless IP Architecture for Mobile-IP AAA 915 In this example, a Mobile Node appears within a local network and 916 issues a registration to the Foreign Agent. Since the Foreign Agent 917 does not share any security association with the Home Agent, it sends 918 a Diameter request to its local Diameter server, which includes the 919 authentication information and the Mobile-IP registration request. 920 The Mobile Node cannot communicate directly with the home Diameter 921 Server for two reasons: 923 - It does not have access to the network. The registration 924 request is sent by the Mobile Node to request access to the 925 network. 926 - The Mobile Node may not have an IP address, and may be 927 requesting that one be assigned to it by its home provider. 929 The Local Diameter Server will determine whether the request can be 930 satisfied locally through the use of the Network Access Identifier 931 [3] provided by the Mobile Node. The NAI has the form of user@realm 932 and the Diameter Server uses the realm portion of the NAI to identify 933 the Mobile Node's home Diameter Server. If the Local Diameter Server 934 does not share any security association with the Mobile Node's home 935 Diameter Server, it may forward the request to a proxy or redirect 936 server. If the server has a relationship with the home network, it 937 can forward the request (or redirect), otherwise a failure indication 938 is sent back to the Local Diameter Server. 940 When the home Diameter Server receives the Diameter Request, it 941 authenticates the user and begins the authorization phase. The 942 authorization phase includes the generation of: 944 - Dynamic session keys to be distributed among all mobility agents 945 - Optional dynamic assignment of a home agent 946 - Optional dynamic assignment of a home address (note this could 947 be done by the home agent). 948 - Optional assignment of QOS parameters for the mobile node [22] 950 Once authorization is complete, the home Diameter Server issues an 951 unsolicited Diameter request to the Home Agent, which includes the 952 information in the original Diameter request as well as the 953 authorization information generated by the home Diameter server. The 954 Home Agent retrieves the Registration Request from the Diameter 955 request and processes it, then generates a Registration Reply that is 956 sent back to the home Diameter server in a Diameter response. The 957 message is sent to the Local Server, through the proxy if one was 958 used, and finally to the Foreign Agent. 960 The Diameter servers maintain session state information based on the 961 authorization information. If a Mobile Node moves to another Foreign 962 Agent within the local administrative domain, a request to the local 963 Diameter server can be done in order to immediately return the keys 964 that were issued to the previous Foreign Agent. This eliminates an 965 additional round trip through the internet when micro mobility is 966 involved, and enables smooth hand-off. In order for the Diameter 967 server to be able to provide the keying information to the new 968 Foreign Agent, they must have a pre-existing security association. 970 Note that smooth hand-off is really a mobility function, and it is 971 not clear that Diameter should be involved. However, this example is 972 provided for completeness. 974 If the Mobile Node enters a service area owned by a new service 975 provider, the authentication and authorization request will have to 976 be sent back to the home Diameter server, which will create new 977 keying information. 979 3.3.1. Minimized Internet Traversal 980 Although it would have been possible for the Diameter interactions to 981 be performed for basic authentication and authorization, and the 982 Registration flow to be sent directly to the Home Agent from the 983 Foreign Agent, one of the key Mobile-IP Diameter requirements is to 984 minimize Internet traversals. Including the Registration Request and 985 Replies in the Diameter messages allows for a single traversal to 986 authenticate the user, perform authorization and process the 987 Registration Request. This streamlined approach is required in order 988 to minimize the latency involved in getting wireless (cellular) 989 devices access to the network. New registrations should not increase 990 the connect time more than what the current cellular networks 991 provide. 993 3.3.2. Key Distribution 995 In order to allow the scaling of wireless data access across 996 administrative domains, it is necessary to minimize the security 997 associations required. This means that each Foreign Agent does not 998 share a security association with each Home Agent on the Internet. 999 The Mobility Agents share a security association with their local 1000 Diameter server, which in turn shares a security association with 1001 other Diameter servers. Again, the use of proxies (as defined by 1002 ROAMOPS) allows such services to scale by allowing the number of 1003 relationships established by the providers to be reduced. 1005 After a Mobile Node is authenticated, the authorization phase 1006 includes the generation of Sessions Keys. Specifically, three keys 1007 are generated: 1009 - K1 Key to be shared between the Mobile Node and the Home Agent 1010 - K2 Key to be shared between the Mobile Node and the Foreign 1011 Agent 1012 - K3 Key to be shared between the Foreign Agent and the Home Agent 1014 Each key is encrypted in two separate methods. K1 is encrypted using 1015 SA3 (for the Home Agent), and using SA2 (for the Mobile Node). K2 is 1016 encrypted using SA4 (for the Foreign Agent) and using SA2 (for the 1017 Mobile Node). Lastly, K3 is encrypted using SA4 (for the Foreign 1018 Agent), and using SA3 (for the Home Agent). When the Foreign Diameter 1019 Server receives the keys, they are decrypted and re-encrypted using 1020 SA1. All of the Security Associations (SAx) are shown in figure 5. 1021 The keys destined for the foreign and home agent are propagated to 1022 the mobility nodes via the Diameter protocol, while the keys destined 1023 for the Mobile Node are sent via the Mobile-IP protocol. 1025 Figure 7 depicts the new security associations used for Mobile-IP 1026 message integrity using the keys derived by the Diameter server. 1028 +--------+ +--------+ 1029 | | K3 | | 1030 | FA |<-------------------->| HA | 1031 | | | | 1032 +--------+ +--------+ 1033 ^ ^ 1034 | K2 K1 | 1035 | +--------+ | 1036 | | | | 1037 +------>| MN |<------+ 1038 | | 1039 +--------+ 1040 Figure 7 - Security Association after Key Distribution 1042 Once the session keys have been established and propagated, the 1043 mobility devices can exchange registration information directly 1044 without the need of the Diameter infrastructure. However the session 1045 keys have a lifetime, after which the Diameter infrastructure must be 1046 used in order to acquire new session keys. 1048 3.4 NASREQ Extension 1050 The NASREQ extension provides authentication and authorization for 1051 dial-in PPP users, terminal server access and tunneling applications, 1052 such as L2TP. The extension makes use of the attributes defined in 1053 the RADIUS protocol to carry the data objects. This was intended to 1054 ease migration of existing RADIUS servers to Diameter since they 1055 could share a single dictionary and user profile. Furthermore, this 1056 would reduce the amount of processing required for an inter-working 1057 system that acts as a RADIUS/Diameter bridge. 1059 Diameter has native EAP support that solves known problems in the 1060 RADIUS protocol. Furthermore, Diameter takes end-to-end 1061 authentication one step further by providing for end-to-end 1062 authentication via PPP's CHAP. This allows for a more secure 1063 authentication infrastructure without having to replace or modify the 1064 installed base of clients. 1066 If end-to-end CHAP is used in bridged Diameter/RADIUS environments, 1067 the bridge host is responsible for generating the challenge to the 1068 user. 1070 The remaining authentication and authorization logic found in RADIUS 1071 implementations can then be re-used. The basic changes are the 1072 message formats and the transmission mechanism as defined in the 1073 Diameter base protocol. This section does not detail RADIUS 1074 authentication and authorization. The interested reader should refer 1075 to [1]. 1077 3.5 Accounting Extension 1079 The Accounting extension provides usage collection to both the 1080 Mobile-IP and the NASREQ extensions. The accounting requirements 1081 specifications [6, 8] define that an accounting protocol must provide 1082 the following functionality: 1084 - Negotiable transfer mechanism. 1085 - Provide general purpose AVPs. 1086 - Flexible to allows new extensions to use the accounting 1087 extension. 1088 - Scalable to allows millions to users and thousands of sites. 1089 - Secure accounting data transfer. 1091 Like the RADIUS protocol, Diameter includes accounting usage 1092 information in AVPs. The Accounting extension defines a set of 1093 accounting AVPs that are used for all services, while each extension 1094 defines their own service specific accounting AVPs. 1096 The Diameter Accounting Extension allows accounting information to be 1097 sent in real-time. Real-time accounting transfers are useful in 1098 environments where timely arrival of the information is required, 1099 such as when debit cards are used. 1101 The Diameter protocol is session oriented, and each session typically 1102 has a finite lifetime. Prior to the timeout of a session, a user 1103 typically needs to be re-authentication and/or re-authorized in order 1104 to extend the life of the session. In the Mobile-IP world, this 1105 equates to the mobility registration lifetime, while in PPP this 1106 means that the PPP authentication must be re-opened. When a re- 1107 authentication and/or re-authorization occurs, a new token is 1108 generated, which is used in the corresponding accounting message. 1110 The Diameter Accounting extension combined with the Strong Security 1111 [26] extension (see section 3.2), provides strong authentication of 1112 accounting data, which MAY be used for repudiation purposes. The 1113 strong security extension also allows multiple parties to sign the 1114 accounting information, which is beneficial in environments that 1115 include a referral broker. The foreign and home servers can both 1116 sequentially sign the accounting record, and submit the result to the 1117 broker. The broker can then use the signatures to ensure that both 1118 parties agreed to the contents of the accounting record. 1120 3.6 Resource Management 1121 Many network access services requiring AAA support have a requirement 1122 for servers that maintain session state information. An example of 1123 such a requirement is in the dial-up PPP world. With the introduction 1124 of flat-rate internet access, there has been a surge in fraud where a 1125 user provides his username/password pair to other people. The end 1126 result is that a single username (account) can have simultaneous 1127 concurrent sessions. 1129 Internet Service Providers have had to implement proprietary 1130 extensions to RADIUS, in order to attempt to identify when such fraud 1131 occurs. Unfortunately, since RADIUS does not provide the necessary 1132 functionality required to maintain state information, these solutions 1133 have been largely unreliable. 1135 The Diameter Base Protocol [18], the Accounting extension [11], the 1136 Mobile IP [13] and NASREQ [23] extensions provide some of the 1137 functionality that is required for servers to maintain state 1138 information, such as: 1140 - Reliable Transport 1141 - Indication of the termination of a session 1142 - A Reboot message 1143 - Interim Accounting 1144 - Accounting On/Off message 1145 - Ability to re-authorize an existing session 1147 Although the above features do allow nodes to maintain state 1148 information, it MAY be necessary for Diameter nodes to request a 1149 snapshot of active sessions from a peer. This may be used when state 1150 information is lost, which could occur after a device failure, or 1151 this may be done periodically in order to ensure that the state is 1152 current. 1154 The Diameter Resource Management extension [5] provides the messages 1155 that are required for a node to request a snapshot of active sessions 1156 from a peer. State information is exchange via the Resource-Token 1157 AVP, which is used to encapsulate a set of AVPs that describe the 1158 session and resources used. There is one Resource-Token AVP for each 1159 active session. 1161 3.7 Diameter Command Naming Conventions 1163 The following conventions are proposed for the naming of Diameter 1164 messages. Diameter commands typically start with an object name, and 1165 end with one of the following verbs: 1167 3.7.1 Request/Answer 1169 Request is used when the command is asking the peer to do something 1170 for it, for example, authorize a user, or terminate a session. The 1171 Answer MUST contain either a positive or negative result code, 1172 telling the requester whether or not the request successfully 1173 occurred. Other information can also be returned in the Answer. 1175 For example, AA-Request asks the peer device to authorize and/or 1176 authenticate a user in order to set up a session. The request may 1177 fail, thus the answer may be positive or negative. 1179 3.7.2 Query/Response 1181 Query is used when the command is asking for information that it 1182 expects the peer to have. An example would be querying for current 1183 configuration information, or querying for information on resources 1184 or sessions in use. The Response usually contains a positive result 1185 code and the information, or a negative result code with the reason 1186 for not answering the query. 1188 For example, Resource-Query requests the peer device to return 1189 specific information about one or more resources. The answer is 1190 returned in a Resource-Response. 1192 3.7.3 Indication 1194 Indication is used when the command is giving information on 1195 something that is about to or has already occurred. The peer 1196 receiving the message does not respond to the message, but a 1197 transport level acknowledgement must be done in order to ensure that 1198 the message was reliably delivered. 1200 4.0 Why not LDAP? 1202 One common question is whether LDAP would provide the functionality 1203 required. 1205 A Server MAY wish to access policies using LDAP, but the use of LDAP 1206 between the client and the server is not possible. The use of LDAP in 1207 this case would require that all routers have read/write access to 1208 the directory. Most customers would not accept this requirements and 1209 it is not efficient. 1211 In the case of roaming, customers would have to open up their 1212 directory so outside routers have writable access. The security 1213 implications set aside, having 1000's of routers constantly 1214 read/write to the directory would cause some additional problems to 1215 the Directory Service. 1217 Finally, LDAP does not provide server initiated messages which is a 1218 requirement for an AAA protocol. 1220 5.0 References 1222 [1] Rigney, et alia, "RADIUS", RFC-2138, Livingston, April 1997 1224 [2] Veizades, Guttman, Perkins, Kaplan, "Service Location Protocol", 1225 RFC-2165, June 1997. 1227 [3] Aboba, Beadles, "The Network Access Identifier", RFC 2486, Janu- 1228 ary 1999. 1230 [4] Rigney, "RADIUS Accounting", RFC-2139, April 1997. 1232 [5] P. Calhoun, "Diameter Resource Management", draft-calhoun- 1233 diameter-res-mgmt-07.txt, IETF Work in Progress, January 2001. 1235 [6] B. Aboba, J. Arkko, D. Harrington. "Introduction to Accounting 1236 Management", draft-ietf-aaa-acct-05.txt, IETF work in progress, 1237 June 2000. 1239 [7] C. Perkins, Editor. IP Mobility Support. RFC 2002, October 1240 1996. 1242 [8] S. Kent, R. Atkinson, "Security Architecture for the Internet 1243 Protocol", RFC 1825, November 1998. 1245 [9] Bradner, "Key words for use in RFCs to Indicate Requirements 1246 Levels", BCP 14, RFC 2119, March 1997. 1248 [10] L. Blunk, J. Vollbrecht, "Extensible Authentication Protocol 1249 (EAP)", RFC 2284, March 1998. 1251 [11] J. Arkko, P. Calhoun, P. Patel, G. Zorn, "Diameter Accounting 1252 Extension", draft-calhoun-diameter-accounting-09.txt, IETF work 1253 in progress, January 2001. 1255 [12] J. Case, D. Harrington, R. Presuhn, B. Wijnen, "Message Process- 1256 ing and Dispatching for the Simple Network Management Proto- 1257 col:", RFC 2572, April 1999. 1259 [13] P. Calhoun, C. Perkins, "Diameter Mobile IP Extensions", draft- 1260 calhoun-diameter-mobileip-12.txt, IETF work in progress, January 1261 2001. 1263 [14] M. Baum, H. Perritt, "Electronic Contracting, Publishing and EDI 1264 Law", Prentice-Hall, ISBN 0-471-53135-9. 1266 [15] P. Calhoun, C. Perkins "Mobile IP Foreign Agent 1267 Challenge/Response Extension", RFC 3012, November 2000. 1269 [16] D. Harkins, D. Carrell, "The Internet Key Exchange (IKE)" RFC 1270 1409, November 1998. 1272 [17] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661, STD 1273 51, July 1994. 1275 [18] P. Calhoun, A. Rubens, H. Akhtar, E. Guttman, "Diameter Base 1276 Protocol", draft-calhoun-diameter-18.txt, IETF work in progress, 1277 January 2001. 1279 [19] B. Aboba, G. Zorn, "Criteria for Evaluating Roaming Protocols", 1280 RFC 2477, January 1999. 1282 [20] B. Aboba, J. Lu, J. Alsop, J. Ding, W. Wang, "Review of Roaming 1283 Implementations", RFC 2194, September 1997. 1285 [21] B. Aboba, J. Vollbrecht, "Proxy Chaining and Policy Implementa- 1286 tion in Roaming", RFC 2607, June 1999. 1288 [22] T. Hiller and al, "CDMA2000 Wireless Data Requirements for AAA", 1289 draft-hiller-cdma2000-aaa-02.txt, IETF work in progress, Sep- 1290 tember 2000. 1292 [23] P. Calhoun, W. Bulley, A. Rubens, J. Haag, "Diameter NASREQ 1293 Extension", draft-calhoun-diameter-nasreq-06.txt, IETF work in 1294 progress, January 2001. 1296 [24] R. Stewart et al., "Simple Control Transmission Protocol", RFC 1297 2960, October 2000. 1299 [25] Myers, Ankney, Malpani, Galperin, Adams, "X.509 Internet Public 1300 Key Infrastructure Online Certificate Status Protocol (OCSP)", 1301 RFC 2560, June 1999. 1303 [26] P. Calhoun, W. Bulley, S. Farrell, "Diameter Strong Security 1304 Extension", draft-calhoun-diameter-strong-crypto-06.txt, IETF 1305 work in progress, January 2001. 1307 6.0 Acknowledgements 1309 The Authors would like to thanks Bernard Aboba and Jari Arkko for 1310 their Accounting Requirements contribution. Thanks also goes to Erik 1311 Guttman for some very useful comments in helping make this draft more 1312 readable. The Mobile-IP Extension section was text originally writ- 1313 ten by Pat Calhoun for another Internet-Draft, which was subsequently 1314 cleaned up by Dave Spence. The authors would like to thank Nenad 1315 Trifunovic, Tony Johansson and Pankaj Patel for their participation 1316 in the Document Reading Party. A final thanks to Stephen Farrell for 1317 his security review. 1319 7.0 Author's Addresses 1321 Questions about this memo can be directed to: 1323 Pat R. Calhoun 1324 Sun Laboratories, Network and Security 1325 Sun Microsystems, Inc. 1326 15 Network Circle 1327 Menlo Park, California, 94025 1328 USA 1330 Phone: +1 650-786-7733 1331 Fax: +1 650-786-6445 1332 E-mail: pcalhoun@eng.sun.com 1334 Glen Zorn 1335 Cisco Systems, Inc. 1336 500 108th Avenue N.E., Suite 500 1337 Bellevue, WA 98004 1338 USA 1340 Phone: +1 425 438 8218 1341 E-Mail: gwz@cisco.com 1343 Ping Pan 1344 Bell Laboratories 1345 Lucent Technologies 1346 101 Crawfords Corner Road 1347 Holmdel, NJ 07733 1348 USA 1350 Phone: +1 732-332-6744 1351 E-mail: pingpan@dnrc.bell-labs.com 1353 Haseeb Akhtar 1354 Wireless Technology Labs 1355 Nortel Networks 1356 2221 Lakeside Blvd. 1357 Richardson, TX 75082-4399 1358 USA 1360 Phone: +1 972-684-8850 1361 E-Mail: haseeb@nortelnetworks.com 1363 8.0 Full Copyright Statement 1365 Copyright (C) The Internet Society (2001). All Rights Reserved. 1367 This document and translations of it may be copied and furnished to 1368 others, and derivative works that comment on or otherwise explain it 1369 or assist in its implementation may be prepared, copied, published 1370 and distributed, in whole or in part, without restriction of any 1371 kind, provided that the above copyright notice and this paragraph are 1372 included on all such copies and derivative works. However, this docu- 1373 ment itself may not be modified in any way, such as by removing the 1374 copyright notice or references to the Internet Society or other 1375 Internet organizations, except as needed for the purpose of develop- 1376 ing Internet standards in which case the procedures for copyrights 1377 defined in the Internet Standards process must be followed, or as 1378 required to translate it into languages other than English. The lim- 1379 ited permissions granted above are perpetual and will not be revoked 1380 by the Internet Society or its successors or assigns. This document 1381 and the information contained herein is provided on an "AS IS" basis 1382 and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS- 1383 CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 1384 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1385 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1386 FITNESS FOR A PARTICULAR PURPOSE. 1388 9.0 Expiration Date 1390 This memo is filed as and 1391 expires in July 2001.