idnits 2.17.1 draft-calhoun-diameter-framework-03.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 29 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 30 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. ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: '1' is defined on line 1172, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 1211, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 1218, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 1223, 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) -- Possible downref: Normative reference to a draft: ref. '5' == Outdated reference: A later version (-02) exists of draft-aboba-acct-01 -- Possible downref: Normative reference to a draft: ref. '6' ** Obsolete normative reference: RFC 2002 (ref. '7') (Obsoleted by RFC 3220) -- No information found for draft-arkko-acctreq - is the name correct? -- Possible downref: Normative reference to a draft: ref. '8' ** Obsolete normative reference: RFC 2284 (ref. '10') (Obsoleted by RFC 3748) == Outdated reference: A later version (-09) exists of draft-calhoun-diameter-accounting-00 -- Possible downref: Normative reference to a draft: ref. '11' ** Obsolete normative reference: RFC 2572 (ref. '12') (Obsoleted by RFC 3412) == Outdated reference: A later version (-12) exists of draft-calhoun-diameter-mobileip-02 -- Possible downref: Normative reference to a draft: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' == Outdated reference: A later version (-13) exists of draft-ietf-mobileip-challenge-02 ** Obsolete normative reference: RFC 1409 (ref. '16') (Obsoleted by RFC 1416) == Outdated reference: A later version (-18) exists of draft-calhoun-diameter-08 -- Possible downref: Normative reference to a draft: ref. '18' ** Downref: Normative reference to an Informational RFC: RFC 2477 (ref. '19') ** Downref: Normative reference to an Informational RFC: RFC 2194 (ref. '20') ** Downref: Normative reference to an Informational RFC: RFC 2607 (ref. '21') -- Possible downref: Normative reference to a draft: ref. '22' -- Possible downref: Normative reference to a draft: ref. '23' -- No information found for draft-roamops-acctng - is the name correct? -- Possible downref: Normative reference to a draft: ref. '24' ** Obsolete normative reference: RFC 2560 (ref. '25') (Obsoleted by RFC 6960) Summary: 19 errors (**), 0 flaws (~~), 13 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Pat R. Calhoun 2 Category: Standards Track Sun Microsystems, Inc. 3 Title: draft-calhoun-diameter-framework-03.txt Glen Zorn 4 Date: October 1999 Microsoft Corporation 5 Ping Pan 6 Bell Labs 7 Haseeb Akhtar 8 Nortel Networks 10 DIAMETER Framework Document 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at: 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at: 31 http://www.ietf.org/shadow.html. 33 This document is an individual contribution for consideration by the 34 AAA Working Group of the Internet Engineering Task Force. Comments 35 should be submitted to the diameter@ipass.com mailing list. 37 Distribution of this memo is unlimited. 39 Abstract 41 As the number of new internet services has increased in the past 42 couple of years, routers and network access servers (NAS) have had to 43 undergo re-engineering to support them. 45 These new services could often benefit from an Authentication, 46 Authorization and Accounting (AAA) protocol to facilitate off-loading 47 policy information to an external server. 49 The DIAMETER protocol defines a policy protocol used by clients to 50 perform Policy, AAA and Resource Control for Internet Access 51 technologies such as PPP and Mobile-IP 53 Table of Contents 55 1.0 Introduction 56 1.1 Copyright Statement 57 1.2 Requirements language 58 1.3 Terminology 59 2.0 Problems to be addressed 60 3.0 DIAMETER Architecture 61 3.1 DIAMETER Base Protocol 62 3.1.1 Proxy Support 63 3.1.2 Broker Support 64 3.2 End-to-End Security Extension 65 3.3 Mobile-IP Extension 66 3.4 PPP (ROAMOPS) Extension 67 3.5 Accounting Extension 68 3.6 DIAMETER Command Naming Conventions 69 3.6.1 Request/Response 70 3.6.2 Query/Response 71 3.6.3 Indication 72 4.0 Why not LDAP? 73 5.0 References 74 6.0 Acknowledgements 75 7.0 Author's Address 77 1.0 Introduction 79 Historically, the RADIUS protocol has been used to provide AAA 80 services for dial-up PPP [17] and terminal server access. Over time, 81 routers and network access servers (NAS) have increased in complexity 82 and density, making the RADIUS protocol increasingly unsuitable for 83 use in such networks. 85 The Roaming Operations Working Group (ROAMOPS) has published a set of 86 specifications [19, 20, 21] that define how a PPP user can gain 87 access to the Internet without having to dial into his/her home 88 service provider's dial equipment. This is achieved by allowing 89 service providers to cross-authenticate their users. Effectively, a 90 user can dial into any service provider's point of presence (POP) 91 that has a roaming agreement with his/her home Internet service 92 provider (ISP), the benefit being that the user does not have to 93 incur a long distance charge while traveling, which can sometimes be 94 quite expensive. 96 Given the number of ISPs today, ROAMOPS realized that requiring each 97 ISP to set up roaming agreements with all other ISPs did not scale. 98 Therefore, the working group defined a "broker", which acts as an 99 intermediate server, whose sole purpose is to set up these roaming 100 agreements. A collection of ISPs and a broker is called a "roaming 101 consortium". There are many such brokers in existence today; many 102 also provide settlement services for member ISPs. 104 The Mobile-IP Working Group has recently changed its focus to cross- 105 domain mobility, which is a requirement for cellular carriers wishing 106 to deploy IETF-based mobility protocols. The current cellular 107 carriers requirements [22, 23] are very similar to the ROAMOPS model, 108 with the exception that the access protocol is Mobile-IP [2] instead 109 of PPP. 111 The DIAMETER protocol was not designed from the ground up. Instead, 112 the basic RADIUS model was retained while fixing the flaws in the 113 RADIUS protocol itself. DIAMETER does not share a common protocol 114 data unit (PDU) with RADIUS, but does borrow sufficiently from the 115 protocol to ease migration. 117 The basic concept behind DIAMETER is to provide a base protocol that 118 can be extended in order to provide AAA services to new access 119 technologies. Currently, the protocol only concerns itself with PPP 120 access, both in the traditional sense as well as taking into account 121 the ROAMOPS model, and Mobile-IP. 123 Although DIAMETER could be used to solve a wider set of AAA problems, 124 we are currently limiting the scope of the protocol in order to 125 ensure that we do not lose focus. Note that a truly generic AAA 126 protocol used by many applications might provide functionality not 127 provided by DIAMETER. Therefore, it is imperative that the designers 128 of new applications understand their requirements before using 129 DIAMETER. 131 1.1 Copyright Statement 133 Copyright (C) The Internet Society 1999. All Rights Reserved. 135 1.2 Requirements language 137 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 138 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 139 described in [9]. 141 1.3 Terminology 143 [editor's note: lots of new terminology is needed here] 145 AAA 147 Authentication, Authorization and Accounting. 149 AVP 151 The DIAMETER protocol consists of a header followed by objects. 152 Each object is encapsulated in a header known as an Attribute- 153 Value-Pair. 155 Commands 157 The DIAMETER Protocol is a request/response protocol. Each 158 DIAMETER message includes a Command AVP that is used to identify 159 the type of request or response. 161 Integrity Check Vector (ICV) 163 An Integrity Check Vector is an unforgeable or secure hash of the 164 packet with a shared secret. 166 2.0 Problems to be addressed 168 The RADIUS protocol was designed in the early 1990's as an attempt to 169 solve a scaling problem associated with dial-in and telnet servers. 170 Over time the networks became more complex (e.g. roaming networks) 171 and the Network Access Servers (NAS) increased in complexity and 172 density. These changes combined with a massive deployment of the 173 protocol uncovered some fundamental issues with the protocol that 174 needed to be fixed. The DIAMETER protocol was designed as a next 175 generation RADIUS protocol, designed with roaming and high density 176 NASes in mind. 178 This section will describe the documented, and undocumented, RADIUS 179 problems known today. Further sections will describe how the DIAMETER 180 protocol addresses each one of these problems. The problems are: 182 - strict limitation of attribute data. 184 - inefficient retransmission algorithm. 186 - Inability to control flow to servers. 188 - end-to-end message acknowledgement. 190 - no retransmission procedure. 192 - Silent discarding of packets. 194 - No fail-over server support. 196 - client/server protocol. 198 - Authentication Replay Attacks. 200 - Hop-by-Hop security. 202 - No support for user-specific commands. 204 - Heavy processing cost. 206 One of problems that RADIUS suffers from is its inherent limitation 207 on the length of attribute data. This limitation is imposed by the 208 fact that the protocol's attribute header only reserves one byte for 209 the length field. The RADIUS protocol does specify that larger data 210 can be spanned across multiple attributes, however doing so 211 introduces a new set of problems. The RADIUS protocol also allows 212 multiple attributes of the same type to be included within a message. 213 Therefore, it is difficult for a RADIUS server, or client, to 214 determine whether multiple identical attributes are in fact multiple 215 independent attributes, or a single fragmented attribute. 217 The RADIUS protocol states that the identifier field, found within 218 the header, is used to identify retransmissions. This one byte field 219 imposes a strict limitation on the number of requests that can be 220 pending at any given time to 255. In the early 1990's, this number 221 was sufficient, but the increased density of most NASes today make 222 the protocol nearly nearly unusable. Most NASes today have fixed this 223 problem by including information in other attributes to bypass this 224 limitation. However, the RADIUS servers have also had to support this 225 change in protocol since they must be able to properly identify 226 retransmissions. The RADIUS protocol also states that the identifier 227 MUST be changed if any data is changed in a request. 229 For this reason, most RADIUS servers keep a cache of received RADIUS 230 request (e.g. all packets received in the last 60 seconds). The 231 RADIUS servers then attempt to match some attributes within the 232 received requests with all attributes in all packets in the cache. 233 This places a very heavy burden on the RADIUS servers, but 234 unfortunately is the only method of identifying retransmissions given 235 the fact that the RADIUS protocol does not have any good scheme. This 236 hack has proved necessary since some NASes have had to change some 237 information within requests in the retransmission queue (such as 238 session length). 240 Given the rather bursty nature of the RADIUS protocol, current 241 servers have no way of properly managing their receive buffers. This 242 is in part due to the fact that RADIUS operates over UDP, and does 243 not include any windowing support. This has been known to cause 244 large bursts of requests to be directed to a server, which can burden 245 a server's ability to respond in a timely manner. This problem is 246 most prevalent in cases where a server becomes unavailable and all 247 requests must be sent to an alternate server, or when an ingress port 248 on the NAS becomes available (e.g. T3 port on NAS). 250 The RADIUS protocol requires that a NAS retransmit a request until a 251 successful or failed response is received, and does not permit a 252 RADIUS server to retransmit a response. This is problematic since 253 there are many times when a server does receive a request, but cannot 254 respond before the NAS determines that the request must be 255 retransmitted. This can occur for many reasons, including the fact 256 that processing a RADIUS request, which includes authentication and 257 authorization of the user, a database lookup and logging events, can 258 be lengthy. 260 Another reason why NASes typically retransmit is when a SERVER 261 receives a large number of requests, and cannot process all of them 262 in a timely manner. The side effect here is that if the NAS 263 retransmits requests to the server, it simply causes further damage 264 to the busy server. Since the RADIUS server cannot retransmit, some 265 RADIUS servers keep a cache of responses sent in the past 60 seconds 266 in order to minimize processing should a retransmission be received. 267 As previously discussed, identifying a retransmission is a very CPU 268 intensive tasks, but perhaps not quite as intensive as a database 269 lookup. 271 The introduction of proxy RADIUS network have made this 272 acknowledgement scheme even worse, since the end server must respond 273 in a timely manner. Each intermediate RADIUS server adds additional 274 latency to proxied requests due to the application processing cost. 275 This has been known to cause unnecessary retransmission of requests 276 by NASes, which impose heavy burden on the proxies, and the network. 278 When a NAS retransmits a request a maximum number of times, it 279 assumes that the server is no longer available and transmits the 280 packet to an alternate server. If there are many packets in the 281 retransmission queue, all other requests are also transmitted to the 282 new server. Since a burst of requests were sent to the server, the 283 chances that it can satisfy all requests before the retransmission 284 period are very small, which causes unnecessary retransmissions. 286 The RADIUS protocol states that packets that do not contain the 287 expected information, or packets that have errors are silently 288 discarded. Silently discarding packets can create a serious problem 289 since no response is sent to the NAS, which then has to assume that 290 the server is no longer reachable. Since proxy networks are 291 transparent to a NAS, should a server in a proxy chain silently 292 discard a request, it will cause the NAS to assume that the local 293 (first hop) server is no longer available. 295 Most NASes today support a large number of RADIUS servers in an 296 attempt to provide resilience. However, the RADIUS protocol itself 297 makes this very difficult due to the problems described above. Since 298 a NAS does not know a priori whether a specific server is available, 299 when it switches to an alternate server, it must retransmit a packet 300 a maximum number of times before determining that the server in 301 question is down, and that the next server in the configuration chain 302 must be tried. Taking an example of a NAS with 8 servers configured, 303 if the next 3 servers in the configuration chain were down, it would 304 take the NAS x number of seconds to reach an available server (where 305 x is equal to the retransmission interval * the maximum number of 306 retransmissions * 3), which is most often longer than the clients are 307 willing to wait. 309 Serving ISP Home ISP 310 +--------+ +--------+ 311 | Primary| | Primary| 312 +-------+ | Proxy |----------->| Home | 313 | |----------->| Server | | Server | 314 |Network| +--------+ +--------+ 315 |Access | 316 |Server | +--------+ +--------+ 317 | |----------->| 2 nd | | 2 nd | 318 +-------+ | Proxy |----------->| Home | 319 | Server | | Server | 320 +--------+ +--------+ 322 Figure 1: RADIUS Proxy Network 324 Given that a RADIUS server cannot know a priori whether a downstream 325 RADIUS server is reachable, and the fact that the NAS must retransmit 326 any packets, the RADIUS protocol is not well suited to proxy 327 environments. Since servers are not aware of a peer's reachability, 328 most RADIUS networks are designed by creating parallel links between 329 primary and alternate servers (see figure 1). In this example the 330 serving ISP's primary server communicates with the home ISP's primary 331 server, while the 2nd servers communicate directly. When the NAS 332 issues a request to the primary server, the first hop server attempts 333 to proxy the request to the primary server at the home network. The 334 NAS will attempt to retransmit the request n number of times, and the 335 primary server will simply forward the request to the primary server 336 at the home network. 338 Should no response be received, the primary server could attempt to 339 forward the request to the 2nd server at the home network, but since 340 the NAS is controlling the retransmissions, it may not have the 341 opportunity to do so. Therefore, the NAS will redirect all requests 342 to the serving ISP's 2nd server. Given the protocol's limitations, 343 it requires a large number of RADIUS servers in order to provide 344 resilient service. 346 The above problem is further aggravated should the serving ISP 347 attempt to proxy to two different administrative network's servers. 348 Take an example where the serving ISP issues two authentication 349 requests, one for abc.net and another for xyz.com. Let's also assume 350 that abc.net's primary server is down, while xyz's 2nd server is 351 down. Should such a problem occur, all requests for abc.net would 352 cause the NAS to switch to the serving ISP's 2nd server, while all 353 requests to xyz.net would cause the NAS to switch back to the serving 354 ISP's primary server. This clearly illustrates that the RADIUS 355 protocol cannot be reliably used in proxy networks. 357 The RADIUS protocol does not allow a server to send unsolicited 358 messages to the NAS. As network services became more complex, this 359 limitation has forced manufacturers to break the RADIUS protocol in 360 this area in order to allow servers to communicate with the client. 361 This is widely used for accounting purposes, and to allow a server to 362 inform a NAS that a session should be terminated. Unfortunately, the 363 lack of a standard method of doing this has caused many non- 364 interoperable implementations to be deployed. 366 In today's PPP world, the NAS provides a challenge to the user, which 367 is then computed by the PPP user to create the challenge response. 368 This is commonly known as CHAP [26], and is a popular PPP 369 authentication scheme. Before roaming networks existed, service 370 providers would own both the NAS and the RADIUS server and this 371 wasn't considered a problem. However, now that the NAS and the RADIUS 372 server are owned by two separate administrative domains, the fact 373 that the non-trusted NAS generates a challenge provides the ability 374 for authentication replay attacks. A NAS, or any RADIUS server in a 375 proxy chain, can have access to a valid challenge/response pair, 376 which can be replayed at a later time. 378 The EAP protocol [10], which will be supported as part of RADIUS 379 extensions can solve this problem, but the fact that EAP is not 380 widely deployed on clients, and that many EAP authentication 381 transforms cannot be used within RADIUS (due to the limitation on 382 attribute data size) makes it difficult to use. Furthermore, given 383 the RADIUS protocol's requirement for end-to-end retransmissions, 384 since some EAP authentication types involve a higher number of round 385 trips than what RADIUS currently supports, RADIUS and EAP cannot be 386 used on networks that exhibit data loss. This is primarily due to the 387 fact that most EAP (PPP) clients timeout before the authentication 388 can be completed. 390 The RADIUS protocol uses hop-by-hop security, which means that every 391 hop in a RADIUS proxy network adds authentication data that is used 392 by the next peer in the chain. There does not exist the concept of 393 end-to-end security, where security is maintained from the requestor 394 and the responder, even though a request is handled by intermediate 395 nodes. This has caused opportunities for fraud in RADIUS networks, 396 since intermediate nodes can easily modify information (e.g. 397 accounting information), and such events are untraceable. 399 Although the RADIUS protocol does support vendor-specific attributes, 400 it does not allow for vendor-specific commands. This has caused 401 serious inter-operability problems since vendors simply choose 402 command identifiers at random, which can collide with other 403 manufacturer's implementation. 405 Unlike most newer IETF protocols, the RADIUS protocol does not impose 406 any alignment requirements, which adds an unnecessary burden on most 407 processors. All fields within the header and attributes must be 408 treated as byte aligned characters. 410 3.0 DIAMETER Architecture 412 The DIAMETER architecture consists of a base protocol and a set of 413 protocol extensions (such as end-to-end security, PPP, Mobile-IP and 414 accounting). Functionality common to all supported services is 415 implemented in the base protocol, while application-specific 416 functionality may be provided through the extension mechanism. 418 The base protocol [18] must be supported for all DIAMETER 419 applications, and defines the basic PDU format, a few primitives and 420 the basic security services offered by the protocol. Like RADIUS, the 421 DIAMETER protocol operates over UDP but it does define a good 422 retransmission and fail-over strategy that was lacking in RADIUS. The 423 base protocol also defines a windowing scheme, which allows the AAA 424 servers to limit the flow of incoming requests. This can then be used 425 by the AAA clients to distribute the traffic load across multiple 426 servers. The fail-over strategy and the windowing capabilities allow 427 clients and servers to detect the reachability state of peers within 428 the network, allowing for quick transition to back-up servers. 430 As previously discussed, the ROAMOPS model introduces the AAA broker, 431 which acts as an intermediate server redirecting requests to user's 432 home ISPs. ROAMOPS also described a set of attacks that one could 433 mount if such a network was built using the RADIUS protocol [21]. In 434 order to provide secure broker services, end-to-end security is 435 required at the application layer, since messages traverse 436 application gateways (brokers). 438 The DIAMETER End-to-End Security Extension defines a set of 439 extensions to the base protocol that provide end-to-end integrity, 440 confidentiality and non-repudiation at the Attribute-Value-Pair (AVP) 441 level. With these extensions, it is possible to secure portions of a 442 DIAMETER message, while other parts of the message are not secured. 443 Secured objects are called protected AVPs; non-secured objects are 444 called unprotected AVPs. Using DIAMETER, brokers can add, delete or 445 modify unprotected AVPs in a message. 447 The RADIUS protocol provides dial-up PPP AAA services by providing 448 three commands and many Attributes. Attributes in RADIUS are 449 analogous to AVPs in DIAMETER. In order to ease migration from RADIUS 450 to DIAMETER, the first 256 entries in the DIAMETER AVP space are 451 reserved for RADIUS compatibility. This allows both protocols to 452 share a common dictionary and policy rules for PPP user profiles. 453 Recently, the RADIUS protocol adopted support for the Extensible 454 Authentication Protocol (EAP) [10], but RADIUS' lack of support for 455 large attributes and its inherent unreliability has made the 456 integration of the protocols very difficult. 458 The DIAMETER PPP Extension defines a set of 459 authentication/authorization commands, which can be used for CHAP, 460 PAP and EAP. DIAMETER's support for larger AVPs and its 461 retransmission strategy has made the use of EAP much more palatable, 462 allowing for end-to-end user authentication, which reduces many of 463 authentication replay attacks currently documented. 465 Unlike PPP, Mobile-IP hosts do not have a long-lived "nailed-up" 466 connection to a PPP server, but rather get service from routers that 467 provide service in a particular cell. In the Mobile-IP world, the 468 router is known as a Foreign Agent, while the moving hosts are known 469 as Mobile Nodes. The mobile node's home network has a host that 470 forwards all packets destined to the mobile node through the Foreign 471 Agent. This host is commonly referred to as the Home Agent. 473 Mobile-IP [7] allows the mobile nodes to move from one cell (subnet) 474 to another while retaining the same IP address, minimizing the impact 475 to applications. Although the Mobile-IP protocol could be deployed in 476 a small network with any AAA services, a larger network suffers from 477 many scaling issues such as: 479 - Static mobile node home address 481 - Static mobile node home agent 483 - Requirement to pre-configure mobile node profile on home agents 485 - No inter-domain mobility 487 Both PPP and Mobile-IP require that usage data be collected for uses 488 such as capacity planning and for accounting purposes. The current 489 standard protocol for accounting is SNMP [12], but experience 490 indicates that SNMP often is not the correct protocol for service 491 accounting. Today many applications and services use RADIUS 492 accounting [4] as their accounting protocol, however the RADIUS 493 accounting protocol is not an IETF standard; in addition, it suffers 494 from similar scaling and security problems. The DIAMETER accounting 495 extension [11] is designed to allow accounting information to be sent 496 across administrative domains (optionally through brokers), and has 497 been derived from an accounting requirements document [6, 8]. 499 +-----------+ 500 | Mobile-IP | 501 | | 502 | Extension | 503 +-----------+ 504 +-----------+ /|\ +------------+ 505 | ROAMOPS | | | Accounting | 506 | (PPP) | | | | 507 | Extension | | | Extension | 508 +-----------+ | +------------+ 509 /|\ | /|\ 510 | | | 511 \|/ \|/ \|/ 512 +----------------------------------+---------------------+ 513 | | | 514 | DIAMETER Base Protocol | End-to-End Security | 515 | | | 516 +----------------------------------+---------------------+ 517 Figure 2: DIAMETER Protocol Architecture 519 3.1 DIAMETER Base Protocol 521 The Base Protocol defines the DIAMETER message format, a set of 522 primitives and how the messages are transmitted in a secure fashion. 523 The Base Protocol assumes a peer-to-peer communication model, as 524 opposed to a client-server model. The following goals motivated the 525 design of the base protocol: 527 - lightweight and simple to implement. 529 - Large AVP space 531 - Efficient encoding of attributes, similar to RADIUS 533 - Support for vendor specific AVPs and Commands 535 - Support for large number of simultaneous pending requests 537 - Reliable, UDP-based transport 539 - Well-defined retransmission and fail-over scheme 541 - Ability to quickly detect unreachable peers 543 - No silent message discards 545 - Support of unsolicited messages to "clients" 546 - integrity and confidentiality at the AVP level 548 - Hop-by-Hop and End-to-End security 550 - Session-Oriented protocol 552 - Allow direct communication, bypassing the broker 554 The DIAMETER base protocol is intended to simply provide a secure 555 transport for the messages defined in the various application- 556 specific extensions. It is therefore imperative that the base be 557 lightweight and simple to implement. 559 In the DIAMETER protocol, data objects are encapsulated within the 560 Attribute Value Pair (AVP). An AVP consists of three parts: the 561 Identifier, Length and Data. A unique AVP Identifier is assigned to 562 all data objects in order to be able to distinguish the data 563 contained. The AVP Identifier namespace must be sufficiently large to 564 ensure that future protocol extensibility is not limited by the size 565 of the namespace, as in the RADIUS protocol. Furthermore, vendors 566 wishing to add "proprietary" extensions must be allowed to do so by 567 using a vendor-specific namespace, managed by IANA. 569 For many years the question as to whether RADIUS should operate over 570 UDP or TCP has been under heated discussion. It must be determined 571 whether the benefits that UDP provides are worth the implementation 572 complexities. Over time, it has become clear that these benefits are 573 well worth the cost. The issue with TCP is that an AAA protocol 574 requires a quick retransmission and fail-over scheme, which TCP 575 cannot provide. The DIAMETER protocol must be able to control 576 retransmission strategy, and more importantly when to switch to an 577 alternate DIAMETER server. 579 Contrary to RADIUS, the DIAMETER protocol requires that each node in 580 a proxy chain acknowledge a request, or response, at the "transport" 581 layer. Since DIAMETER defines a reliable layer over UDP, this is 582 done through the use of sequence and acknowledgement numbers. This 583 allows each node in a chain to retransmit unacknowledged packets. 585 The DIAMETER protocol provides message sequencing within the header, 586 which can be used to detect retransmissions. This simple 587 retransmission detection can greatly simplify server implementations, 588 and allow a given server to support a much larger number of 589 transactions per second. 591 The DIAMETER protocol provides windowing, which requires that each 592 peer advertise it's receive window. This makes it much simpler for a 593 NAS to send only the number of requests that the next hop DIAMETER 594 server can handle. Clever implementations can then decide to send 595 requests to an alternate server when a primary server is busy. 597 When a DIAMETER peer has not acknowledged a specific message, and the 598 message has been retransmitted some maximum number of times, the peer 599 is assumed to be no longer reachable, and all pending requests can 600 then be issued to an alternate server (providing that they fit within 601 the peer's receive window). The Base Protocol also defines a watchdog 602 message, which is sent to a peer to detect reachability when no 603 traffic has been sent for some time. 605 With the exception of a few security related errors, the DIAMETER 606 protocol requires that all messages be acknowledged, either with a 607 successful response or one that contains an error code. 609 Where the RADIUS protocol is client-server, the DIAMETER protocol is 610 peer to peer, allowing unsolicited messages to be sent to NASes. 611 There are many benefits to peer-to-peer AAA protocols. One example is 612 the on-demand retrieval of accounting data; another, server-initiated 613 session termination. 615 The Base DIAMETER protocol provides for hop-by-hop security, similar 616 to the scheme employed by RADIUS today. However, the DIAMETER 617 protocol also provides for replay protection through a timestamp 618 mechanism. This security scheme requires a long lived security 619 association to be established by peers, or can make use of keying 620 material negotiated out of band. The Base Protocol also allows the 621 built-in security measure to be turned off, (i.e., in cases where 622 IPSec is in use). 624 The DIAMETER protocol is a session-oriented protocol, meaning that 625 each authentication/authorization request must belong to a session, 626 which is identified through a Session Identifier. All subsequent 627 DIAMETER transactions done on behalf of the session MUST include the 628 Session Identifier; a termination message exists to end sessions. 630 Since today's processors work more efficiently when objects are 631 aligned on a 32-bit boundary, the DIAMETER protocol requires 32-bit 632 alignment of all headers and the data. This has recently become a 633 common requirement for many new protocols at the IETF. 635 3.1.1 Proxy Support 637 The DIAMETER protocol was designed from the beginning to support 638 roaming networks. This means that every node in the network is 639 responsible for it's own retransmissions, and the protocol does allow 640 each node to know a priori the reachability state of each peer. This 641 allows for a resilient network, and efficient retransmission scheme. 642 Figure 3 depicts a network where each DIAMETER server can communicate 643 with all other servers. 645 Serving ISP Home ISP 646 +--------+ +--------+ 647 | Primary| | Primary| 648 +-------+ | Proxy |----------->| Home | 649 | |----------->| Server |\ / | Server | 650 |Network| +--------+ \ / +--------+ 651 |Access | X 652 |Server | +--------+ / \ +--------+ 653 | |----------->| 2 nd |/ \ | 2 nd | 654 +-------+ | Proxy |----------->| Home | 655 | Server | | Server | 656 +--------+ +--------+ 658 Figure 3: DIAMETER Proxy Network 660 In the network shown in figure 3, should a request, or response be 661 lost in the network, the last node that handled the lost packet is 662 responsible for retransmitting it to it's peer. Furthermore, should 663 connectivity to a peer be lost, it allowed the node to transmit the 664 packet to an alternate peer. This reduces the number of systems 665 required, processing overhead of intermediate nodes, decreases the 666 latency involved in the switch-over and increases reliability. 668 3.1.2 Broker Support 670 A broker is a proxy server that provides simple DIAMETER message 671 "routing" functions. Brokers are generally deployed in order to 672 reduce the configuration information that would otherwise be 673 necessary on all servers owned by ISPs within a roaming consortium. 674 Brokers can provide two separate functions depending upon the 675 business model. 677 The first where the broker forwards messages to the proper 678 destination based on the NAI information (figure 4). In such a 679 network, when the broker receives a request from a DIAMETER server, 680 it determines the packet's destination and can optionally perform 681 some authorization decisions based on local policy. 683 +------------------+ 684 | DIAMETER | 685 | Broker | 686 +------------------+ 687 /|\ /|\ 688 | | 689 \|/ \|/ 690 +----------+ +----------+ 691 | abc.net | | xyz.net | 692 | DIAMETER | | DIAMETER | 693 | Server | | Server | 694 +----------+ +----------+ 696 Figure 4: DIAMETER Roaming Consortium 698 The DIAMETER broker's organization can also provide Certificate 699 Authority services, by issuing certificates to all DIAMETER servers 700 within the consortium. This allows the broker and the DIAMETER 701 servers to communicate in a secure fashion, without the need for 702 long-lived secrets. Protocols such as IP Security can allow for 703 short-lived session keys to be generated and periodically refreshed. 705 The second broker model allows the end DIAMETER servers to directly 706 communicate (figure 5). In this model the broker simply provides 707 redirect services, which is aimed at reducing the amount of 708 configuration that would otherwise be necessary on all end DIAMETER 709 servers. When a DIAMETER servers sends a request the broker, the 710 broker returns contact information that is then used by the 711 requesting server to issue the request directly to the home DIAMETER 712 server. In order for the end DIAMETER servers to be able to 713 communicate in a secure fashion, a pre-established security 714 association is required. This can be in the form of a long-lived 715 shared secret, which has scaling problems, or via certificates when 716 the broker's organization provides CA services. 718 When the broker provides the message forwarding functions, it can 719 validate that the source and destination DIAMETER servers are in 720 "good standing", which reduces the processing on the end servers. 721 This can be done by having the broker check the server's certificates 722 against a CRL, via an Online Certificate Status Protocols [25], or 723 through local configuration. The broker can optionally attach the 724 source server's certificate if it isn't already present in the 725 message. When a broker receives a request from or destined to a 726 server that is not in "good standing", an error would be returned to 727 the requesting server. 729 +------------------+ +---------+ 730 | DIAMETER | | CRL DB/ | 731 | Broker | | OCSP | 732 +------------------+ +---------+ 733 /|\ 734 Request | Response with 735 | Result Code = 736 | Redirect 737 \|/ 738 +----------+ +----------+ 739 | abc.net |/ \| xyz.net | 740 | DIAMETER |--------------| DIAMETER | 741 | Server |\ /| Server | 742 +----------+ Direct +----------+ 743 Communication 744 Figure 5: DIAMETER Broker Returning Redirect Indication 746 The very fact that the DIAMETER servers in the roaming network do not 747 have to burden themselves with validating certificates against a CRL, 748 or some other certificate validation infrastructure, is a huge 749 advantage. In cases of inter-consortium roaming, the brokers involved 750 can be responsible for validating any certificates involved. Note 751 that it is also possible for the broker to periodically issue new 752 certificates to the roaming consortium members out-of-band in order 753 to eliminate the need to add certificates to each message, decreasing 754 the message size and the per-packet processing penalty. 756 When the broker provides redirect services, the broker can return 757 both the source and the destination server's certificates. The 758 certificates are encapsulated within a DIAMETER attribute, and 759 include a timestamp, an expiration time all signed by the broker. 760 Should the end server's policy be setup such that they will trust the 761 certificate returned by the broker, they do not have to make any 762 additional certificate validation checks. However, local policy may 763 require that the end DIAMETER servers validate periodically. 765 Note that even though some broker's do allow direct communication, 766 some will require that all accounting messages be forwarded by the 767 broker. This is typically required when the broker also provides 768 settlement services. In such a network, the broker normally requires 769 some reassurances that the user was in fact authenticated and 770 authorized by the home DIAMETER server prior to accepting accounting 771 records. The document [5] defines a method by which the broker can 772 get such reassurances. 774 3.2 End-to-End Security Extension 775 The DIAMETER base protocol allows ISP's DIAMETER servers to 776 communicate securely, using hop-by-hop authentication. Hop-by-hop 777 authentication means that the requesting server has secure 778 communication with the broker, and the broker has secure communicate 779 with the destination server. However, the base protocol does not 780 provide the ability for the requesting and destination server to 781 communicate securely through the broker. 783 The End-to-End Security extension provides for end-to-end integrity, 784 confidentiality and non-repudiation at the AVP level. This means that 785 DIAMETER servers can add a Digital Signature over a select set of 786 AVPs, which provides message integrity. Intermediate nodes, such as 787 brokers can also add their own digital signature, should there be a 788 requirement to do so. confidentiality is provided by encrypting AVPs 789 using the target's private key, while non-repudiation is provided via 790 the digital signature previously mentioned. 792 The end-to-end security extension can only be used in networks where 793 the broker issues roaming certificates to all DIAMETER servers that 794 form the roaming consortium. In certain cases, the broker can also 795 act as a settlement agent, similar to the EDI clearing houses [14]. 797 3.3 Mobile-IP Extension 799 The Mobile-IP protocol is used to manage mobility of an IP host 800 across IP subnets [7]. Recent activity within the Mobile-IP Working 801 Group has defined the interaction between Mobile-IP and AAA in order 802 to provide: 804 - Better scaling of security associations 805 - Mobility across administrative domain boundaries 806 - Dynamic home agent assignment 808 The Mobile IP protocol [7] works well when all mobile nodes belong to 809 the same administrative domain. Some of the current work within the 810 Mobile IP Working Group is to allow Mobile IP to scale across 811 administrative domains. This work requires modifications to the 812 existing Mobile IP trust model. 814 Figure 6 depicts the DIAMETER trust model for Mobile-IP. In this 815 model each network contains mobile nodes (MN) and a DIAMETER server. 816 Each mobility device shares a security association (SA) with the 817 DIAMETER server within its own home network. This means that none of 818 the mobility devices initially share a security association. The 819 DIAMETER servers in both administrative domains can either share a 820 direct security association, or can have a security association with 821 an intermediate broker. 823 Broker AAA 824 +--------+ 825 | | 826 |DIAMETER| 827 /=====| |=====\ 828 // +--------+ \\ 829 Foreign // SA SA \\ Home 830 AAA // \\ AAA 831 +--------+ +--------+ 832 | | SA4 | | 833 |DIAMETER|======================|DIAMETER| 834 | |(in lieu of broker or)| | 835 +--------+(in direct comm model)+--------+ 836 || || || 837 || || || 838 SA1|| SA2 || || SA3 839 || || || 840 || || || 841 +---------+ +---------+ +---------+ 842 | | | | | | 843 | FA | | MN | | HA | 844 | | | | | | 845 +---------+ +---------+ +---------+ 846 Figure 6 - Mobile-IP AAA Trust Model 848 Figure 7 provides an example of a Mobile-IP network that includes 849 DIAMETER. In the integrated Mobile-IP/DIAMETER Network, it is assumed 850 that each mobility agent shares a security association between itself 851 and its home DIAMETER server. Further, the Home and Foreign DIAMETER 852 servers both share a security association with the broker's DIAMETER 853 server. Lastly, it is assumed that each mobile node shares a trust 854 relationship with its home DIAMETER Server. 856 Visited Access Broker Home IP 857 Provider Network Network Network 858 +--------+ +--------+ +--------+ 859 | | | | | | 860 |DIAMETER|------|DIAMETER|------|DIAMETER| 861 | | | | | | 862 +--------+ +--------+ +--------+ 863 | | 864 | | 865 AAA | | AAA 866 | | 867 | | 868 +---------+ +---------+ 869 | | | | 870 | FA | | HA | 871 | | | | 872 +---------+ +---------+ 873 | 874 | Visited Access Home Network 875 | Provider Network -Private Network 876 Mobile | -Home Provider 877 IP | -Home ISP 878 | 879 +--------+ 880 | Mobile | 881 | Node | 882 +--------+ 883 Figure 7 - General Wireless IP Architecture for Mobile-IP AAA 885 In this example, a Mobile Node appears within a foreign network and 886 issues a registration to the Foreign Agent. Since the Foreign Agent 887 does not share any security association with the Home Agent, it sends 888 a DIAMETER request to its local DIAMETER server, which includes the 889 authentication information and the Mobile-IP registration request. 890 The Mobile Node cannot communicate directly with the home DIAMETER 891 Server for two reasons: 893 - It does not have access to the network. The registration request 894 is sent by the Mobile Node to request access to the network. 895 - The Mobile Node may not have an IP address, and may be requesting 896 that one be assigned to it by its home provider. 898 The Foreign DIAMETER Server will determine whether the request can be 899 satisfied locally through the use of the Network Access Identifier 900 [3] provided by the Mobile Node. The NAI has the form of user@realm 901 and the DIAMETER Server uses the realm portion of the NAI to identify 902 the Mobile Node's home DIAMETER Server. If the Foreign DIAMETER 903 Server does not share any security association with the Mobile Node's 904 home DIAMETER Server, it may forward the request to its broker. If 905 the broker has a relationship with the home network, it can forward 906 the request, otherwise a failure indication is sent back to the 907 Foreign DIAMETER Server. 909 When the home DIAMETER Server receives the DIAMETER Request, it 910 authenticates the user and begins the authorization phase. The 911 authorization phase includes the generation of: 913 - Dynamic session keys to be distributed among all mobility agents 914 - Optional dynamic assignment of a home agent 915 - Optional dynamic assignment of a home address (note this could be 916 done by the home agent). 917 - Optional assignment of QOS parameters for the mobile node [22] 919 Once authorization is complete, the home DIAMETER Server issues an 920 unsolicited DIAMETER request to the Home Agent, which includes the 921 information in the original DIAMETER request as well as the 922 authorization information generated by the home DIAMETER server. The 923 Home Agent retrieves the Registration Request from the DIAMETER 924 request and processes it, then generates a Registration Reply that is 925 sent back to the home DIAMETER server in a DIAMETER response. The 926 message is forwarded through the broker back to the Foreign DIAMETER 927 server, and finally to the Foreign Agent. 929 The DIAMETER servers maintain session state information based on the 930 authorization information. If a Mobile Node moves to another Foreign 931 Agent within the foreign domain, a request to the foreign DIAMETER 932 server can be done in order to immediately return the keys that were 933 issued to the previous Foreign Agent. This eliminates an additional 934 round trip through the internet when micro mobility is involved, and 935 enables smooth hand-off. In order for the DIAMETER server to be able 936 to provide the keying information to the new Foreign Agent, they must 937 have a pre-existing security association. 939 Note that smooth hand-off is really a mobility function, and it is 940 not clear that DIAMETER should be involved. However, this example is 941 provided for completeness. 943 If the Mobile Node enters a service area owned by a new service 944 provider, the authentication and authorization request will have to 945 be sent back to the home DIAMETER server, which will create new 946 keying information. 948 3.3.1. Minimized Internet Traversal 950 Although it would have been possible for the DIAMETER interactions to 951 be performed for basic authentication and authorization, and the 952 Registration flow to be sent directly to the Home Agent from the 953 Foreign Agent, one of the key Mobile-IP DIAMETER requirements is to 954 minimize Internet traversals. Including the Registration Request and 955 Replies in the DIAMETER messages allows for a single traversal to 956 authenticate the user, perform authorization and process the 957 Registration Request. This streamlined approach is required in order 958 to minimize the latency involved in getting wireless (cellular) 959 devices access to the network. New registrations should not increase 960 the connect time more than what the current cellular networks 961 provide. 963 3.3.2. Key Distribution 965 In order to allow the scaling of wireless data access across 966 administrative domains, it is necessary to minimize the security 967 associations required. This means that each Foreign Agent does not 968 share a security association with each Home Agent on the Internet. 969 The Mobility Agents share a security association with their local 970 DIAMETER server, which in turn shares a security association with 971 other DIAMETER servers. Again, the use of brokers (as defined by 972 ROAMOPS) allows such services to scale by allowing the number of 973 relationships established by the providers to be reduced. 975 After a Mobile Node is authenticated, the authorization phase 976 includes the generation of Sessions Keys. Specifically, three keys 977 are generated: 979 - k1 - Key to be shared between the Mobile Node and the Home Agent 980 - k2 - Key to be shared between the Mobile Node and the Foreign 981 Agent 982 - k3 - Key to be shared between the Foreign Agent and the Home 983 Agent 985 Each key is encrypted in two separate methods. K1 is encrypted using 986 SA2 (for the Home Agent), and using SA3 (for the Mobile Node). K2 is 987 encrypted using SA4 (for the Foreign Agent) and using SA3 (for the 988 Mobile Node). Lastly, K3 is encrypted using SA1 (for the Foreign 989 Agent), and using SA2 (for the Home Agent). All of the Security 990 Associations (SAx) are shown in figure 6. The keys destined for the 991 foreign and home agent are propagated to the mobility nodes via the 992 DIAMETER protocol, while the keys destined for the Mobile Node are 993 sent via the Mobile-IP protocol. 995 Figure 8 depicts the new security associations used for Mobile-IP 996 message integrity using the keys derived by the DIAMETER server. 998 +--------+ +--------+ 999 | | k3 | | 1000 | FA |======================| HA | 1001 | | | | 1002 +--------+ +--------+ 1003 \\ // 1004 \\ k2 k1 // 1005 \\ +--------+ // 1006 \\ | | // 1007 \=====| MN |=====/ 1008 | | 1009 +--------+ 1010 Figure 8 - Security Association after Key Distribution 1012 Once the session keys have been established and propagated, the 1013 mobility devices can exchange registration information directly 1014 without the need of the DIAMETER infrastructure. However the session 1015 keys have a lifetime, after which the DIAMETER infrastructure must be 1016 used in order to acquire new session keys. 1018 3.4 PPP (ROAMOPS) Extension 1020 The ROAMOPS extension provides authentication and authorization for 1021 PPP users in both intra- and inter-domain networks. The extension 1022 makes use of the attributes defined in the RADIUS protocol to carry 1023 the data objects. This was intended to ease migration of existing 1024 RADIUS servers to DIAMETER since they could share a single dictionary 1025 and user profile. Furthermore, this would reduce the amount of 1026 processing required for an inter-working system that acts as a 1027 RADIUS/DIAMETER bridge. 1029 DIAMETER has native EAP support that works very well, due to the fact 1030 that the known RADIUS problems have been fixed in the base protocol. 1031 Furthermore, DIAMETER takes end-to-end authentication one step 1032 further by providing for end-to-end authentication via PPP's CHAP. 1033 This allows for a more secure authentication infrastructure without 1034 having to replace or modify the installed base of clients. 1036 If end-to-end CHAP is used in bridged DIAMETER/RADIUS environments, 1037 the bridge host is responsible for generating the challenge to the 1038 user. 1040 The remaining authentication and authorization logic found in RADIUS 1041 implementations can then be re-used. The basic changes are the packet 1042 formats and the transmission mechanism as defined in the DIAMETER 1043 base protocol. This section will not detail how RADIUS 1044 authentication and authorization functions given that it is a well 1045 known problem space and has been in use for years. 1047 3.5 Accounting Extension 1049 The Accounting extension provides usage collection to both the 1050 Mobile-IP and the PPP (ROAMOPS) extensions. The accounting 1051 requirements specifications [6, 8] define that an accounting protocol 1052 must provide the following functionality: 1054 - Negotiable transfer mechanism. 1056 - Provide general purpose AVPs. 1058 - Flexible to allows new extensions to use the accounting 1059 extension. 1061 - Scalable to allows millions to users and thousands of sites. 1063 - Secure accounting data transfer. 1065 The DIAMETER protocol encodes the actual accounting information using 1066 the Accounting Data Interchange Format (ADIF) [24]. ADIF was intended 1067 to allow a uniform encoding of accounting data to be transferred over 1068 virtually any transport (e.g. DIAMETER, SMTP, HTTP, etc). 1070 The DIAMETER Accounting Extension makes extensive use of tokens. 1071 Tokens are created by the server during the authorization phase. The 1072 token includes information about the session, which is then used by 1073 the accounting server to ensure that the accounting record received 1074 corresponds to a previously authenticated and authorized session. The 1075 replay protection and digital signature embedded within the token is 1076 used to minimize accounting fraud. See [5] for more information. 1078 The DIAMETER Accounting Extension allows accounting information to be 1079 sent in two modes; real-time and batched. Real-time accounting 1080 transfers are useful in environments where timely arrival of the 1081 information is required, such as when debit cards are used. Batched 1082 accounting transfers are useful in environments that do not need up 1083 to the minute accounting records. However, it is possible that in 1084 inter-domain networks, real-time accounting data delivery will be 1085 more popular since the ISPs involved will want to receive some 1086 guarantees of payment prior to providing service. 1088 The DIAMETER protocol is session oriented, and each session typically 1089 has a finite lifetime. Prior to the timeout of a session, a user 1090 typically needs to be re-authentication and/or re-authorized in order 1091 to extend the life of the session. In the Mobile-IP world, this 1092 equates to the mobility registration lifetime, while in PPP this 1093 means that the PPP authentication must be re-opened [5]. When a re- 1094 authentication and/or re-authorization occurs, a new token is 1095 generated, which is used in the corresponding accounting message. 1097 The DIAMETER Accounting Extension supports non-repudiation of both 1098 the request, and the corresponding response. In the RADIUS world, 1099 even if non-repudiation was added to the protocol, an accounting 1100 acknowledgement does not include the information being acknowledged, 1101 making it very difficult to prove that the peer really accepted the 1102 request. The DIAMETER protocol requires that a hash of the accounting 1103 record be included in the response, which can optionally be signed 1104 for non-repudiation. 1106 3.6 DIAMETER Command Naming Conventions 1108 The following conventions are proposed for the naming of Diameter 1109 messages. Diameter commands typically start with an object name, and 1110 end with one of the following verbs: 1112 3.6.1 Request/Response 1114 Request is used when the command is asking the peer to do something 1115 for it, for example, set up a session, or reconfigure some 1116 parameters. The Response usually contains either a positive or 1117 negative result code, telling the requester whether or not the 1118 request successfully occurred. Other information can also be returned 1119 in the Response. 1121 For example, AA-Request asks the peer device to authorize and/or 1122 authenticate a user in order to set up a session. The request may 1123 fail, thus the response may be positive or negative. 1125 3.6.2 Query/Response 1127 Query is used when the command is asking for information that it 1128 expects the peer to have. An example would be querying for current 1129 configuration information, or querying for information on resources 1130 or sessions in use. The Response usually contains a positive result 1131 code and the information, or a negative result code with the reason 1132 for not answering the query. 1134 For example, Resource-Query requests the peer device to return 1135 specific information about one or more resources. The answer is 1136 returned in a Resource-Response. 1138 3.6.3 Indication 1140 Indication is used when the command is giving information on 1141 something that is about to or has already occurred. The peer 1142 receiving the message does not respond to the message, but a 1143 transport level acknowledgement must be done in order to ensure that 1144 the message was reliably delivered. 1146 For example the base draft defines a message that is used to ensure 1147 that a peer is still active. This is achieve with the Device- 1148 Watchdog-Ind message, which is acknowledgement as defined in [18]. 1150 4.0 Why not LDAP? 1152 One common question is whether LDAP would provide the functionality 1153 required. 1155 A Server MAY wish to access policies using LDAP, but the use of LDAP 1156 between the client and the server is not possible. The use of LDAP in 1157 this case would require that all routers have read/write access to 1158 the directory. Most customers would not accept this requirements and 1159 it is not efficient. 1161 In the case of roaming, customers would have to open up their 1162 directory so outside routers have writeable access. The security 1163 implications set aside, having 1000's of routers constantly 1164 read/write to the directory would cause some additional problems to 1165 the Directory Service. 1167 Finally, LDAP does not provide server initiated messages which is a 1168 requirement for an AAA protocol. 1170 5.0 References 1172 [1] Rigney, et alia, "RADIUS", RFC-2138, Livingston, April 1997 1174 [2] Veizades, Guttman, Perkins, Kaplan, "Service Location 1175 Protocol", RFC-2165, June 1997. 1177 [3] Aboba, Beadles, "The Network Access Identifier", RFC 2486, 1178 January 1999. 1180 [4] Rigney, "RADIUS Accounting", RFC-2139, April 1997. 1182 [5] G. Zorn, P. Calhoun, "Limiting Fraud in Roaming", 1183 draft-ietf-roamops-fraud-limit-00.txt, IETF Work in Progress, 1184 May 1999. 1186 [6] B. Aboba, J. Arkko, "Introduction to Accounting 1187 Management", draft-aboba-acct-01.txt, IETF Work in Progress 1188 June 1999. 1190 [7] C. Perkins, Editor. IP Mobility Support. RFC 2002, October 1191 1996. 1193 [8] J. Arkko, "Requirements for Internet-Scale Accounting 1194 Management", draft-arkko-acctreq-00.txt, IETF Work 1195 in Progress, August 1998. 1197 [9] Bradner, "Key words for use in RFCs to Indicate Requirements 1198 Levels", BCP 14, RFC 2119, March 1997. 1200 [10] L. Blunk, J. Vollbrecht, "Extensible Authentication Protocol 1201 (EAP)", RFC 2284, March 1998. 1203 [11] P. Calhoun, P. Patel, G. Zorn, J. Arkko, "DIAMETER 1204 Accounting Extension", draft-calhoun-diameter-accounting- 1205 00.txt, IETF Work in Progress, October 1999. 1207 [12] J. Case, D. Harrington, R. Presuhn, B. Wijnen, 1208 "Message Processing and Dispatching for the Simple 1209 Network Management Protocol:", RFC 2572, April 1999. 1211 [13] P. Calhoun, C. Perkins, "DIAMETER Mobile IP Extensions", 1212 draft-calhoun-diameter-mobileip-02.txt, IETF Work in 1213 Progress, August 1999. 1215 [14] M. Baum, H. Perritt, "Electronic Contracting, Publishing and 1216 EDI Law", Prentice-Hall, ISBN 0-471-53135-9. 1218 [15] P. Calhoun, C. Perkins "Mobile IP Foreign Agent 1219 Challenge/Response Extension", 1220 draft-ietf-mobileip-challenge-02.txt, IETF Work in progress, 1221 May 1999. 1223 [16] D. Harkins, D. Carrell, "The Internet Key Exchange (IKE)" 1224 RFC 1409, November 1998. 1226 [17] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661, 1227 STD 51, July 1994. 1229 [18] P. Calhoun, A. Rubens, "DIAMETER Base Protocol", 1230 draft-calhoun-diameter-08.txt, IETF Work in Progress, 1231 August 1999. 1233 [19] B. Aboba, G. Zorn, "Criteria for Evaluating Roaming 1234 Protocols", RFC 2477, January 1999. 1236 [20] B. Aboba, J. Lu, J. Alsop, J. Ding, W. Wang, "Review of 1237 Roaming Implementations", RFC 2194, September 1997. 1239 [21] B. Aboba, J. Vollbrecht, "Proxy Chaining and Policy 1240 Implementation in Roaming", RFC 2607, June 1999. 1242 [22] T. Hiller and al, "3G Wireless Data Provider Architecture 1243 Using Mobile IP and AAA", draft-hiller-3gwireless-00.txt, 1244 IETF Work in Progress, March 1999. 1246 [23] E. Gustafsson, A. Jonsson, E. Hubbard, J. Halmkvist, 1247 A. Roos, "Requirements on Mobile IP from a Cellular 1248 Perspective", draft-ietf-mobileip-cellular-requirements- 1249 02.txt, IETF Work in Progress, June 1999. 1251 [24] B. Aboba, D. Lidyard, "The Accounting Data Interchange 1252 Format (ADIF)", draft-roamops-acctng-06.txt, IETF Work 1253 in Progress, August 1999. 1255 [25] Myers, Ankney, Malpani, Galperin, Adams, "X.509 Internet 1256 Public Key Infrastructure Online Certificate Status 1257 Protocol (OCSP)", RFC 2560, June 1999. 1259 [26] W. Simpson, "PPP Challenge Handshake Authentication 1260 Protocol (CHAP)", RFC 1994, August 1996. 1262 6.0 Acknowledgements 1264 The Authors would like to thanks Bernard Aboba and Jari Arkko for 1265 their Accounting Requirements contribution. Thanks also goes to Erik 1266 Guttman for some very useful comments in helping make this draft more 1267 readable. The Mobile-IP Extension section was text originally 1268 written by Pat Calhoun for another Internet-Draft, which was 1269 subsequently cleaned up by Dave Spence. 1271 7.0 Author's Address 1273 Questions about this memo can be directed to: 1275 Pat R. Calhoun 1276 Sun Laboratories, Network and Security 1277 Sun Microsystems, Inc. 1278 15 Network Circle 1279 Menlo Park, California, 94025 1280 USA 1282 Phone: 1-650-786-7733 1283 Fax: 1-650-786-6445 1284 E-mail: pcalhoun@eng.sun.com 1286 Glen Zorn 1287 Microsoft Corporation 1288 One Microsoft Way 1289 Redmond, WA 98052 1290 USA 1292 Phone: 1-425-703-1559 1293 E-Mail: glennz@microsoft.com 1295 Ping Pan 1296 Bell Laboratories 1297 Lucent Technologies 1298 101 Crawfords Corner Road 1299 Holmdel, NJ 07733 1300 USA 1302 Phone: 1-732-332-6744 1303 E-mail: pingpan@dnrc.bell-labs.com 1305 Haseeb Akhtar 1306 Wireless Technology Labs 1307 Nortel Networks 1308 2221 Lakeside Blvd. 1309 Richardson, TX 75082-4399 1310 USA 1312 Phone: 1-972-684-8850 1313 E-Mail: haseeb@nortelnetworks.com