idnits 2.17.1 draft-ietf-aaa-issues-05.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 25 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 28 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 369: '...ach RADIUS proxy MUST remove any exist...' RFC 2119 keyword, line 436: '...atory attributes MUST cause the operat...' RFC 2119 keyword, line 624: '... Session-Id AVPs SHOULD appear first, ...' RFC 2119 keyword, line 839: '... type of service MAY be robust in natu...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 269 has weird spacing: '...rate on issue...' == Line 781 has weird spacing: '...rmation is al...' == Line 919 has weird spacing: '...he case that ...' -- 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: Informational ---------------------------------------------------------------------------- == Missing Reference: '13' is mentioned on line 828, but not defined == Unused Reference: '7' is defined on line 1031, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 1039, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 1042, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-calhoun-diameter-17 == Outdated reference: A later version (-06) exists of draft-calhoun-diameter-nasreq-05 == Outdated reference: A later version (-09) exists of draft-calhoun-diameter-framework-08 == Outdated reference: A later version (-12) exists of draft-calhoun-diameter-mobileip-11 == Outdated reference: A later version (-07) exists of draft-calhoun-diameter-strong-crypto-05 == Outdated reference: A later version (-09) exists of draft-calhoun-diameter-accounting-08 == Outdated reference: A later version (-05) exists of draft-calhoun-diameter-impl-guide-03 == Outdated reference: A later version (-08) exists of draft-calhoun-diameter-res-mgmt-05 == Outdated reference: A later version (-02) exists of draft-ietf-aaa-proto-eval-00 ** Obsolete normative reference: RFC 2138 (ref. '11') (Obsoleted by RFC 2865) -- Duplicate reference: draft-ietf-aaa-na-reqts, mentioned in '14', was also mentioned in '9'. == Outdated reference: A later version (-08) exists of draft-ietf-roamops-actng-07 ** Obsolete normative reference: RFC 1409 (ref. '16') (Obsoleted by RFC 1416) ** Obsolete normative reference: RFC 2618 (ref. '17') (Obsoleted by RFC 4668) ** Obsolete normative reference: RFC 2619 (ref. '18') (Obsoleted by RFC 4669) ** Obsolete normative reference: RFC 2620 (ref. '19') (Obsoleted by RFC 4670) ** Obsolete normative reference: RFC 2621 (ref. '20') (Obsoleted by RFC 4671) ** Obsolete normative reference: RFC 1510 (ref. '21') (Obsoleted by RFC 4120, RFC 6649) == Outdated reference: A later version (-04) exists of draft-ietf-smime-rcek-00 Summary: 13 errors (**), 0 flaws (~~), 21 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Pat R. Calhoun (editor) 3 Category: Informational Sun Microsystems, Inc. 4 Title: draft-ietf-aaa-issues-05.txt Bernard Aboba 5 Date: January 2002 Microsoft 6 Erik Guttman 7 Sun Microsystems, Inc. 8 Dave Mitton 9 Nortel Networks 10 Dave Nelson 11 Enterasys Networks, Inc. 12 Juergen Schoenwaelder 13 Technical University Braunschweig 14 Barney Wolff 15 Databus Inc. 16 Lixia Zhang 17 UCLA 19 AAA Problem Statements 21 Status of this Memo 23 This document is an Internet-Draft and is in full conformance with 24 all provisions of Section 10 of RFC2026. Internet-Drafts are working 25 documents of the Internet Engineering Task Force (IETF), its areas, 26 and its working groups. Note that other groups may also distribute 27 working documents as Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at 31 any time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at: 36 http://www.ietf.org/ietf/1id-abstracts.txt 38 The list of Internet-Draft Shadow Directories can be accessed at: 40 http://www.ietf.org/shadow.html. 42 This document is an individual contribution for consideration by the 43 AAA Working Group of the Internet Engineering Task Force. Comments 44 should be submitted to the diameter@diameter.org and aaa-wg@merit.edu 45 mailing lists. 47 Distribution of this memo is unlimited. 49 Copyright (C) The Internet Society 2000. All Rights Reserved. 51 Abstract 53 The AAA Evaluation Team's recommendation document raised some issues 54 with the DIAMETER protocol. The AAA WG has created a design team to 55 address these issues. This document is an attempt to describe the 56 problems, which the WG can then concentrate on solving. 58 Table of Contents 60 1.0 Introduction 61 1.1 Requirements language 62 2.0 Error Codes and Messages 63 2.1 Error Messages Action Item List 64 3.0 Accounting 65 3.1 The Universal Approach 66 3.2 Batch Accounting Issues 67 3.3 Proxy Accounting Issues 68 3.4 Semantic Issues 69 3.5 Accounting Message "Bloat" Issues 70 3.6 Accounting Message Format Issues 71 3.7 Accounting Action Item List 72 4.0 IPv6 Support 73 5.0 Transports 74 5.1 Failover & Recovery Sending 75 5.1.1 Failover Action Item List 76 6.0 Proxies 77 6.1 Proxy Behavior 78 6.2 State/Path Retention 79 6.3 Proxy Action Item List 80 7.0 RADIUS Compatibility 81 8.0 End-to-End Security 82 8.1 End-to-End Security Action Item List 83 9.0 Data Model 84 9.1 Separability of DIAMETER Header and Message 85 9.2 Data Types supported in DIAMETER 86 9.3 Formal notation for application specific data types 87 9.3.1 Goals for formal notation 88 9.3.2 How to evaluate proposals for formal data 89 type languages 90 9.4 Ordering of Data 91 9.5 Mandatory AVPs 92 9.6 BNF Notation 93 9.7 Data Model Action Item List 94 10.0 SNMP Support (DIAMETER MIB) 95 10.1 Configuration of Sensitive Parameters 96 10.2 Modular MIB(s) 97 10.3 Traps and Informs 98 10.4 SNMP Action Item List 99 11.0 Re-Authentication & Authorization 100 12.0 Server/Resource Management State 101 13.0 Access Rules and Filters 102 13.1 Access Rules and Filters Action Item List 103 14.0 AAA Server Discovery 104 14.1 Server Discovery Action Item List 105 15.0 Loop Detection 106 15.1 Loop Detection Action Item List 107 16.0 Issues identified in the Mailing List 108 16.1 DIAMETER Identifier Field 109 16.2 DIAMETER State Machine 110 17.0 IANA Considerations 111 18.0 Security Considerations 112 19.0 Acknowledgments 113 20.0 References 114 21.0 Authors' Addresses 115 22.0 Full Copyright Statement 117 1.0 Introduction 119 The AAA Evaluation Team's recommentation document raised some issues 120 with the DIAMETER protocol. The AAA WG has created a design team to 121 address these issues. This document is an attempt to describe the 122 problems, which the WG can then concentrate on solving. 124 2.0 Error Codes and Messages 126 Given the extensibility nature of the DIAMETER protocol, future 127 extensions will most likely need to allocate error codes to handle 128 error conditions specific to the extension. This extensibility leads 129 to an interoperability problem with implementations that do not 130 support new extensions, since it becomes difficult to recognize how 131 the error should be treated. 133 The HTTP protocol has solved this problem by creating classes of 134 errors. Implementations only need to understand the error class in 135 order to properly process the error code. 137 One of the major issues with RADIUS [11] was the lack of error 138 messages. In RADIUS there was no way for the Accounting server to 139 indicate conditions such as "too busy" or "out of disk space", so the 140 only choice for an Accounting server experiencing difficulties is to 141 not respond to an Accounting-Request, thereby causing re- 142 transmissions that could exacerbate the problem. In addition, since 143 there is no status message equivalent of "OK" or "Processing" in 144 RADIUS there is no way for an accounting server to explicitly 145 indicate that an accounting record has been written to stable 146 storage. These issues preclude interpretation of a RADIUS 147 Accounting-Response as an application-layer ACK. 149 In addition to addressing these problems, DIAMETER also needs to 150 define the interaction of error messages and security. For example, 151 allowing error messages from an intermediate node to affect end-to- 152 end communications may enable denial of service attacks. 154 2.1 Error Messages Action Item List 156 The action items identified in this section are summarized as 157 follows: 159 1.) Define how the DIAMETER protocol could represent classes of 160 errors. 161 2.) Investigate how intermediate proxies inserting error codes in 162 DIAMETER messages breaks end-to-end security, and find a 163 solution. 164 3.) Determine whether error messages should be used, or whether 165 error codes are sufficient. 166 4.) Ensure that the error codes defined have the necessary 167 richness required for servers to return specific error 168 conditions (e.g. out of disk space), which should cause the 169 NAS (or downstream proxy) to try another accounting server. 171 3.0 Accounting 173 3.1 The Universal Approach 175 One problem with the current DIAMETER Accounting draft [6] is that 176 accounting is handled in a single protocol extension document. The 177 features of accounting include support for distinct environments, 178 such as roaming, that may not be needed in other applications. It may 179 be useful to consider accounting subsets for each of the supported 180 application areas. 182 3.2 Batch Accounting Issues 184 Section 1.2 of the DIAMETER Accounting draft [6] says "Each 185 Accounting-Delivery-Max-Batch / Accounting-Delivery-Max-Delay AVP 186 pair with different values forms one pool of accounting data in the 187 DIAMETER node acting as a client." It seems that some more explicit 188 and restricted form of pool creation may be desirable given the 189 potentially large number of possible different "value pairs" for 190 these AVPs. 192 It has been suggested by some that FTP is a more appropriate protocol 193 for batch accounting, depending of course, on what the ultimate batch 194 size might be. 196 3.3 Proxy Accounting Issues 198 Sections 1.3, 1.6 and 2.2 of the DIAMETER Accounting draft [6] deal 199 with how accounting messages are handled for routing or broker proxy 200 applications. The producer of a co-mingled-destination Accounting- 201 Request record (e.g. a NAS) is required to handle a series of partial 202 Accounting-Answer records from various home Accounting Servers. It 203 would appear to be desirable for proxies to handle this extra work 204 and complexity on behalf of the DIAMETER client. Complexity arises 205 out of partially acknowledged accounting data, potentially requiring 206 the DIAMETER client to distinguish and communicate with individual 207 home Accounting Servers that it would otherwise have no knowledge of. 209 The issues of multi-party trust, counter-signatures and distributed 210 non- repudiation capabilities are not as clearly explained in the 211 draft as they might be. This is a complex area, and perhaps one in 212 which accounting extensions specific to broker proxy operations might 213 be warranted. 215 3.4 Semantic Issues 217 The semantics of a successful Accounting-Answer message need to be 218 further defined. Does this mean that the corresponding accounting 219 data has been reliably written to stable storage (to disk, for 220 example) at the ultimate destination (the home Accounting Server, for 221 example)? Should there be error codes to indicate certain classes of 222 failure, such as "out of disk space"? It might well be that the retry 223 policy for a "no space" error would be different from that of a 224 transient network outage. 226 The use of the Accounting-Delivery-Max-Batch AVP should be clarified 227 in the case of proxy chains. Will this AVP be modified by each proxy 228 in the chain? How else would the aggregation of accounting data for 229 multiple destinations be handled? The draft implies that the ultimate 230 destination is uniquely and unambiguously defined by the NAI. Is this 231 always the case? 233 The use of the Accounting-State AVP and Accounting-Status-Ind AVP 234 should be clarified in the case of proxy chains. Do proxies send 235 these messages both upstream and downstream? Do all DIAMETER peers 236 send them (e.g. Servers to NASes)? Are both AVPS really required? 238 3.5 Accounting Message "Bloat" Issues 240 Accounting-Answer messages include the same ADIF-Record AVPs as were 241 contained in the Accounting-Request messages, often with additional 242 signatures. This is clearly to obtain distributed non-repudiation in 243 proxy applications, especially brokering environments. This does lead 244 to SNMP-style response "bloat" however, and it is not needed in all 245 environments. 247 3.6 Accounting Message Format Issues 249 The DIAMETER Accounting draft indicates that ADIF [15] is the only 250 supported data format for accounting. There has been some indication 251 that an applicability statement may be required for how ADIF is used 252 within DIAMETER. 254 3.7 Accounting Action Item List 256 The action items identified in this section are summarized as 257 follows: 259 1.) Investigate feature-specific subsets of the DIAMETER 260 Accounting protocol, to mirror the DIAMETER Extension drafts 261 [2,4,5,6,8]. 262 2.) Evaluate recommendation for "pools" created by distinct 263 Accounting-Delivery-Max-Batch / Accounting-Delivery-Max-Delay 264 AVP pairs. 265 3.) Consider definition of batch size, and time intervals for 266 batch accounting, and the use of other protocols, such as FTP. 267 4.) Reconsider partial packet ACKs of accounting responses via 268 proxy chains. 269 5.) Elaborate on issues of multi-party trust, counter-signatures 270 and distributed non- repudiation capabilities. 271 6.) The semantics of a successful Accounting-Answer message need 272 to be further defined. 273 7.) The use of the Accounting-Delivery-Max-Batch AVP should be 274 clarified in the case of proxy chains. 275 8.) The use of the Accounting-State AVP and Accounting-Status-Ind 276 AVP should be clarified in the case of proxy chains. Are 277 both AVPs really needed? 278 9.) Address the accounting response message "bloat" issue. 279 10.) An applicability statement may be required for how ADIF is 280 used within DIAMETER. 282 4.0 IPv6 Support 284 Compatibility with IPv6 requires both the ability for DIAMETER to be 285 transported over IPv6, as well as the ability to carry attributes 286 required to configure IPv6 network access. Since hosts requiring 287 network access may be dual stack, and the AAA server may not know 288 this a-priori, a AAA server may need to return both IPv4 and IPv6 289 attributes and allow the NAS and host to decide which ones to use. 291 A first pass at determining the IPv6 attributes required for dialup 292 access is available at: http://www.ietf.org/internet-drafts/draft- 293 aboba-radius-ipv6-02.txt In order to come up with a list of IPv6 294 attributes for DIAMETER, it is expected that a similar review will be 295 needed for other types of network access. 297 5.0 Transports 299 AAA protocols typically are application driven, which means that the 300 time between requests is typically larger than the round-trip time 301 (RTT). This results in interactions between AAA protocols and 302 reliable transport mechanisms including Nagle algorithm, RTT 303 estimation, delayed ACKs, congestion control, fast re-transmit and 304 fast recovery. 306 In addition, AAA systems frequently include proxies. As a result, 307 the implementation details of such proxies significantly impact end- 308 to-end behavior. For example, a proxy not implementing "back 309 pressure" can prevent end-to-end self-clocking even if the AAA 310 protocol is running over a transport (such as TCP or SCTP) which 311 supports congestion control. 313 As a result of these issues, it is necessary to develop a detailed 314 understanding of how DIAMETER will behave when run over transports 315 such as UDP, TCP and SCTP in the presence of proxies. 317 5.1 Failover & Recovery Sending 319 SCTP gives an indication of peer failure, but nothing in any DIAMETER 320 or SCTP document the evaluator was able to find even mentions how or 321 when to switch back to a primary server to which communication was 322 lost. After a failure, the state machines end in a CLOSED state and 323 nothing seems to trigger exit from that state. It was not clear 324 whether a server, on rebooting, would initiate an SCTP connection to 325 all its configured clients. If not, and in any case when the 326 communication failure was in the network rather than in the server, 327 the client must itself, after some interval, attempt to re-establish 328 communication. But no such guidance is given. 330 5.1.1 failover Action Item List 332 The action items identified in this section are summarized as 333 follows: 335 1.) Add a clear statement of the need for application-level 336 failure detection and failover. 337 2.) Add a clear statement of the need for restart of the transport 338 protocol by one side or the other, to detect recovery of the 339 partner. 340 3.) Evaluate whether the algorithms for 1 & 2 need to be commonly 341 agreed, or can be left to implementors. For example, is a 342 fixed rate of restart attempts (say once per minute) 343 acceptable? Or must there be exponential backoff of this too? 344 Is success of transport protocol establishment sufficient to 345 indicate application availability, or must an application- 346 level probe be sent? 347 4.) If the algorithm needs to be universal, design & document it. 349 6.0 Proxies 351 6.1 Proxy Behavior 353 There two known types of servers, redirect and proxies. The DIAMETER 354 specification describes these types of servers as brokers and 355 proxies. The use of the term broker is problematic, since this term 356 is mostly business-driven, and not necessarily technical. The 357 specification should make use of the terminology redirect servers and 358 proxies, and defined the functionality of each type of server. 360 6.2 State/Path Retention 362 The DIAMETER specification makes use of two different types of 363 mechanism to determine the path of the messages; Proxy-State and 364 Destination-NAI. The former mechanism is based on the RADIUS 365 protocol, while the latter was added to allow the reverse path the be 366 different from the forwarding path. However, very little interest has 367 been shown for the latter feature. 369 In the RADIUS protocol, each RADIUS proxy MUST remove any existing 370 Proxy-State attribute, and replace it with a new version. The Proxy- 371 State attribute can contain state information that is generally 372 useful to the sending server. This requires that each proxy maintain 373 the source of the message, in order to forward the response back to 374 the same peer. 376 The SIP RFC supports this functionality through its Via header field, 377 which allows intermediate nodes to add their information to the 378 message. This effectively builds a "source-route" of the message, and 379 ensures that the reverse path is the same as the forwarding path. A 380 Via-like AVP could also be used to encode state information, which 381 would be used in the reverse (response) message. 383 There are instances where a server would not wish to disclose the 384 original server (or set of servers) of a message. This server should 385 be allowed to remove the necessary portion of the Via-like AVP, and 386 replace it with its own. This would ensure that it would receive the 387 corresponding response, and add the list of Via-like AVPs that had 388 been truncated. 390 6.3 Proxy Action Item List 391 The action items identified in this section are summarized as 392 follows: 394 1.) Properly define the terms proxy, broker, redirect server, 395 transparent and non-transparent proxy in the DIAMETER 396 specifications, and how each type of device should function. 397 2.) Investigate whether the current Proxy-State and Destination- 398 NAI AVPs provide the functionality required. Determine whether 399 a SIP-like approach would be more advantageous. The SIP-like 400 approach should allow for state information to also be encoded 401 within the AVP. 402 3.) If a SIP-like approach is used, investigate how end-to-end 403 security is affected by entities adding their local 404 information to messages. 406 7.0 RADIUS Compatibility 408 RADIUS compatibility is a requirement for a new AAA protocol, as to 409 be able to transition existing RADIUS environments to the new 410 infrastructure over time. It is clear that there will be features of 411 the new protocol that will not be completely expressible in RADIUS. 412 Those features should not be used in such a configuration, but all 413 attempts should be made to design the protocol so that typical and 414 common RADIUS operations of today can be easily supported by future 415 AAA servers. 417 Since AAA servers are typically implemented on host systems as 418 software, they are more easily upgraded than NAS systems which often 419 have embedded software constraints. The likely situation in the 420 future is that new AAA server systems will be deployed to provide new 421 enhanced services, but also support legacy NAS servers which will 422 either be eventually upgraded or replaced. 424 The most desirable compatibility functions would be: 426 a) An AAA server that can speak both RADIUS and DIAMETER, using a 427 common system. (not just two separate servers) 428 b) An AAA proxy server that can support a number of RADIUS 429 speaking NASes, but communicates with a DIAMETER server or 430 infrastructure. 432 There should be a core correspondence between RADIUS messages and 433 DIAMETER operations which is straight forward to implement and covers 434 all typical RADIUS operations. Returned attributes/AVPs that cannot 435 be translated can be discarded if not mandatory. Incompatible 436 mandatory attributes MUST cause the operation to fail with an 437 appropriate error return. Solving this type of problem would have to 438 be done by reconfiguring the gateway or the user return profile. It 439 may be possible (but not mandatory) that the gateway implements 440 configurable translation rules for vendor or site specific features. 441 It may also be possible that the server gets hints from the gateway 442 about RADIUS translation, and knows not to return problem attributes. 444 It is NOT a goal to provide the ability to gateway all new DIAMETER 445 functions into RADIUS messages. Particularly features such as new 446 Vendor specific attributes, or security encodings cannot be expected 447 to be supported. Peer-to-peer features have no standard equivalents. 449 8.0 End-to-End Security 451 The existing DIAMETER protocol provides security between the NAS (or 452 Mobility Agent) and the Home DIAMETER server through the use of the 453 Cryptographic Message Syntax (CMS) protocol. Typically, this security 454 is used to detect fraudulent DIAMETER proxies, which could attempt to 455 modify critical data within messages (e.g. session lifetime). There 456 has been concern that the use of CMS may be too processor intensive, 457 given that it makes exclusive use of public cryptography. 459 Although the DIAMETER protocol does mention that in many cases, CMS 460 would not be invoked by the NAS itself, but rather by the first hop 461 DIAMETER, it is possible that this point needs to be strengthened. 462 Furthermore, there is still concern that public key crypto on the 463 servers may also be too intensive, and not always necessary. 465 One possible solution is to look at the new work underway in the 466 S/MIME group, which is defining support for symmetric key transforms 467 within CMS [22]. This would require an additional round trip to 468 exchange the keys, but this would only be done when keys are not 469 available. Another possible solution is to look at another 470 cryptographic protocol. 472 8.1 End-to-End Security Action Item List 474 The action items identified in this section are summarized as 475 follows: 477 1.) Discuss and justify the threat model under which NAS (or 478 remote ISP) to home-server security is any improvement over 479 hop-by-hop. 480 2.) Stop the misuse of "end-to-end" to mean "NAS-to-home-server". 481 3.) Clarify the separate concerns of disclosure of user 482 information and cheating on billable accounting attributes. 483 Which is the real concern? Does one solution work for both? 485 4.) Coordinate work on establishing a shared symmetric key with 486 the server-discovery work. 488 9.0 Data Model 490 9.1 Separability of DIAMETER Header and Message 492 The current DIAMETER protocol specification does not distinguish 493 between the base protocol (with its set of base data types) and the 494 application specific commands and the data structures communicated by 495 the protocol. Experience with other protocols shows that it is 496 valuable to logically separate the application specific data 497 definitions carried by a protocol from the core services provided by 498 a protocol. It is often useful to be able to interpret a message 499 using high-level functional parameters (for instance, in the header), 500 even if the complete message can not be parsed (for example, if a 501 particular AVP code is not supported by an AAA proxy). 503 To this end, it may be useful to specify in the DIAMETER header 504 whether a particular message is an Request, an Answer, a Query, a 505 Response, or an Indication. 507 9.2 Data Types supported in DIAMETER 509 The base data types in the current DIAMETER specification include 510 Data, String, Address, Integer32, Integer64, Time and Complex. It is 511 in general desirable to reduce the base types shipped by a protocol 512 to a small orthogonal set which is sufficient to support the 513 application specific data carried by the protocol, especially since 514 it is difficult to add new base data types in the future. 516 The Integer32 and Integer64 types are used for signed and sometimes 517 for unsigned AVPs. It may make sense to introduce Unsigned32 and 518 Unsigned64 as base types so avoid any ambiguities. 520 The Time type is an Unsigned32 number reporting the number of seconds 521 since January 1st 1900. There are several issues with this. First, 522 the introduction of an Unsigned32 time implies that Time with its 523 additional semantics as a base type is not needed anymore since the 524 data definition can just define the special Time semantics on top of 525 Unsigned32. Second, the 32 bit unsigned number will wrap in 2038 and 526 it is desirable to prevent a "year 2038 problem" in DIAMETER, e.g. by 527 starting the epoch at January 1st 2000 or by using the Unsigned64 528 base type with the January 1st 1900 epoch. 530 The Data, String and Address types are closely related as they are 531 all application specific interpretations of strings of octets. So 532 rather than having the specific semantics for addresses or printable 533 strings in the base data types, it seems desirable to collapse these 534 three types into a single OctetString or Data type and to let the 535 (extension specific) AVPs define the special semantics. 537 There is a RADIUS AVP which uses 32 bit IEEE floating point values. 538 It should be considered whether there is a need to provide support 539 for 32, 64 and 128 bit IEEE floating point numbers. (Note again that 540 the addition of new base types later on is extremely costly.) 542 The Complex data type should be avoided as it usually requires code 543 changes when it is being used. It is suggested that the 'Grouped' 544 type should replace 'Complex' and that Grouped be composed of a well 545 known sequence of base data types. 547 It has also been suggested that an additional data type could be 548 added: List. Lists would include items of identical type, whose 549 length is only known at the time the list is generated or 550 interpreted. 552 9.3 Formal notation for application specific data types 554 The use of a formal notation for the definition of (potentially 555 complex) application specific data types has proven to be valuable, 556 especially if a protocol is designed the be extensible. A formal 557 notation enables tools that can (a) verify the correctness of data 558 definitions, (b) automate some of the implementation process, (c) 559 help in debugging scenarios, and (d) enable implementations that can 560 be easily adapted to vendor specific extensions. Furthermore, the 561 separation of the data definitions from the core protocol 562 specification allows extension writers to re-use existing data 563 definitions (e.g. for addressing types) and it thus promotes 564 consistency across a variety of management protocols. 566 The formal notation will serve the extensibility of AAA 567 implementations in terms of their data storage, interpretation, 568 validation, display, etc. Support for the formal notation is in this 569 sense an implementation option to enhance support ease the 570 integration of extensions, but not required for compliance. 572 The formal notation is not intended to define the transfer encoding 573 (the on-the-wire byte formatting). The DIAMETER specifications of the 574 base types include these definitions and rules. 576 9.3.1 Goals for formal notation 577 The goals for developing a formal notation would be to facilitate the 578 implementation of various functions, such as a data dictionary, a 579 packet filter or an extensible administrative console. Such 580 facilities have been shown to be useful in RADIUS implementations. 582 The facilities based on formal notation for supported AVP would: 584 - make it possible to add new AVP storage, type checking, etc. 585 support without changing code. 586 - make it easier to extend functionality to sniffers, debuggers 587 management tools and DIAMETER implementations (potentially 588 without adding code). 590 Non-goals are to define a formal notation which can express any 591 possible (i.e., non-DIAMETER) message. We only need to express 592 DIAMETER messages which have been currently defined and those 593 messages which are likely to be defined, given experience with 594 RADIUS. It is thought that support for extensible functions would be 595 a useful but not mandatory feature for DIAMETER implementations. 597 9.3.2 How to evaluate proposals for formal data type languages 599 The 'metrics' by which proposals for a formal notation and additional 600 data types for DIAMETER data will be assessed are: 602 - Is it possible to specify the existing DIAMETER messages? 603 - Is the formal specification language tied to standards which are 604 expected to remain stable (that is, not expected to change in 605 the near to medium term)? 606 - It is clear that using groups or lists of primitive data types 607 will be less efficient than a complex data type (which could 608 include byte by byte data fields, for example, and would not 609 require AVP headers for each element in the data group/ data 610 table. Still, it is reasonable to sacrifice some efficiency for 611 the sake of simplifying protocol implementation and facilitating 612 formalization of data types as described above. If messages 613 are, for example, 20% larger that would be more acceptable than 614 if they became 50% larger. If messages became 100% larger, it 615 would be difficult to accept the alternative to the current 616 "Complex" data type in DIAMETER. 618 9.4 Ordering of Data 620 The current DIAMETER specification says that AVPs can be added 621 arbitrarily as long as the required AVPs are included and AVPs which 622 are explicitly excluded are not included. Some specific AVPs however 623 introduce special requirements and even dependencies between AVPs. 624 (The Session-Id AVPs SHOULD appear first, Integrity-Check-Value AVPs 625 must follow the data to be protected, the Nonce AVP must appear 626 before an Integrity-Check-Value AVP, the last Nonce AVP before an 627 Encrypted-Payload AVP is significant for MD5 payload hiding and so 628 on.) 630 It seems useful to formally define the ordering constraints, 631 potentially restricting the "AVPs can be added arbitrarily" rule to 632 simplify the validation of messages. Note that it is necessary to 633 provide for optional AVPs within a message so that the optional AVPs 634 can be protected by an Integrity-Check-Value AVP. 636 9.5 Mandatory AVPs 638 The current DIAMETER protocol specification defines a mandatory bit 639 ('M') in the AVP header. It basically requires that receivers of 640 messages discard any DIAMETER messages which contain AVPs with the 641 text is silent how a sender of a DIAMETER message decides which AVPs 642 are tagged as mandatory. 644 There seem to be different opinions about the purpose and the precise 645 usage of the 'M' bit. It is necessary to figure out what the purpose 646 of the 'M' is and whether it is a static or dynamic property of an 647 AVP. If it is static for e.g. each AVP of a certain type in a given 648 command, then the question arises whether the 'M' must be carried in 649 the protocol at all. 651 9.6 BNF Notation 653 The DIAMETER documents frequently use a BNF style notation to describe 654 message formats. It needs to be clarified whether the BNF has any 655 semantic relevance. If yes, the document needs to say somewhere 656 precisely what the notation means or to replace it with some other 657 mechanism. It should be noted that it is possible to make the BNF 658 notation more powerful by indicating multiplicity constraints in the BNF 659 itself, rather than having it plain text. 661 9.7 Data Model Action Item List 663 The action items identified in this section are summarized as 664 follows: 666 1.) How could the DIAMETER message header be made to easily 667 distinguish between Request, Answer, Query, Response and 668 Indication messages? 669 2.) What basic data types specifically should be included? We 670 would need to look at all RADIUS extensions to see if we've 671 missed any types. 672 3.) How would List and Grouped data types be transmitted over the 673 wire? 674 4.) What formal notation could be used for DIAMETER messages? 675 Assess these according to the goals and metrics described in 676 Section 9. 678 10.0 SNMP Support (DIAMETER MIB) 680 10.1 Configuration of Sensitive Parameters 682 A decision needs to be reached as to whether the DIAMETER MIB(s) 683 should include "sensitive" parameters. Sensitive parameters include 684 shared secrets, certificates, keys, security policies, and any other 685 information that would facilitate an attack on any DIAMETER peer. 686 The first step would be to create a list of all DIAMETER management 687 parameters. The DIAMETER draft [1] already includes much of this 688 information. These parameters should then be classified by level of 689 sensitivity. 691 It may be possible to take advantage of the security features of 692 SNMPv3 [ref] to allow for complete remote configuration of DIAMETER 693 peers (clients, servers proxies). The level of security available 694 within SNMPv3 should be evaluated against the level of sensitivity of 695 the DIAMETER management parameters. 697 It has been pointed out that security may be compromised when key 698 material from one protocol is carried in a second protocol, 699 especially when the second protocol has weaker cryptographic 700 protections or is not a key distribution protocol that has been 701 thoroughly analyzed in the published cryptographic literature so that 702 there is high confidence that it is sound. Many in the security 703 community consider it strongly undesirable to have cascading 704 vulnerabilities, whereby a compromise or implementation problem in 705 one protocol necessarily leads to a compromise of a second protocol. 707 The RADIUS MIB [17,18,19,20] was written when SNMPv1 and SNMPv2C were 708 all we had, and thus avoided any sensitive configuration parameters 709 that would have posed a security risk for remote access. There are 710 interesting problems to be solved to obtain remote plug-'n-play 711 configuration of DIAMETER peers using SNMP and/or some other suitable 712 protocol, such as IKE [16] or Kerberos [21], but this is a desirable 713 design goal. 715 10.2 Modular MIB(s) 717 DIAMETER should probably have a series of MIBs covering the base 718 protocol in its various roles: client, server and proxy, as well as 719 each of its functional extensions. Counters, such as provided in the 720 RADIUS MIB, should be included, as well as metrics and policy 721 information that might aid in remote problem resolution of specific 722 areas, such as proxy operations. 724 The list of DIAMETER management parameters should also be categorized 725 by the peer role(s) to which each parameter applies. The goal is to 726 permit modular MIB deployment description to match the modular 727 feature deployment. As an alternative, a single MIB could be written, 728 together with Module Compliance Statements, indicating which subset 729 of objects must be implemented in a given peer, by optional function 730 and by optional role. 732 10.3 Traps and Informs 734 A list of significant events occurring within DIAMETER peers needs to 735 be compiled. From this list of events, recommendations for Traps 736 and/or Informs for use within the DIAMETER MIB(s) should be 737 presented. 739 10.4 SNMP Action Item List 741 The action items identified in this section are summarized as 742 follows: 744 1.) List all DIAMETER peer managed objects. 745 2.) Categorize the list of managed objects by optional role and 746 optional function. 747 3.) Categorize the list of managed objects by security 748 sensitivity. 749 4.) Analyze SNMPv3, IKE, Kerberos and any other suitable protocols 750 as to applicability, from a security perspective, for carrying 751 the managed objects that are deemed sensitive. 752 5.) Analyze the proposed MIB for remote plug-'n-play configuration 753 capabilities. 754 6.) Investigate both a single MIB with appropriate (conditional) 755 Module Compliance Statements, as well as multiple MIBs, for 756 modularity mirroring the DIAMETER Extension drafts. 757 7.) Compile a list of significant DIAMETER peer events. 758 8.) Recommend Traps and Informs for inclusion in the MIB(s). 760 11.0 Re-Authentication & Authorization 762 The AAA protocol must be able to support dynamic re-Authentication 763 [1,3] initiated by either the NAS or the Server. 765 Typical uses are periodic CHAP re-authentication, or server re- 766 authentication probes. 768 There should be a clear description of the messages and commands used 769 to initiate a re-authentication from the NAS or server end. 771 What is there: 772 - Mentioned in Base in the section 1.0 wrt to unsolicited 773 messages. 774 - Mentioned in NASreq in the context of EAP auth. 776 What is missing: 777 - How such an unsolicited message would be recognized as a re-auth 778 by the server vs a new request 779 - What message for a server to use to request re-auth and how a 780 NAS correlates that with an existing session 781 - What information is allowable in each message (AVP list) 783 The AAA protocol must be able to support dynamic re-Authorization 784 [2,4] initiated by either the NAS or the Server. 786 Typical uses are the changing of service parameters (e.g. Packet 787 filters or Session expiration timers). 789 There should be a clear description of the messages and commands used 790 to initiate a re-authentication from the NAS or server end. 792 What is there: anything?? 794 What is missing: 795 - How would a NAS request a re-authorization? 796 - How would a Server indicate a re-authorization? Specify 797 messages, commands, AVP datum 798 - How are these messages distinguished from new requests, and 799 correlated with existing sessions? 801 Note that a related but different topic, termination of session 802 service is already covered by the Base document, section 3.4, and 803 three messages are described there: 805 - Session-Termination-Request (STR) NAS->Server, 806 - Session-Termination-Indication (STI) Server->NAS, and 807 - Session-Termination-Answer(STA) acknowledgement 809 12.0 Server/Resource Management State 811 Some implementations of RADIUS supported explicit resource management 812 between the NAS and a server for authorized and active sessions [12]. 813 They implemented a simple resource request/response protocol, where 814 the NAS requested and freed resources managed by the server, with 815 distinct messages. Typical resources managed this way would be IP 816 addresses, concurrent login counts, tunnel session limits, or 817 resource usage based authorization limits. 819 That this happens after authentication, allows the NAS to only 820 request the resources actually needed to provide the service. 821 Whereas authorization parameters in an Access-Accept may anticipate 822 resources not actually needed (like additional addresses for a 823 multi-link sessions, where the multi-link status could not be 824 determined until after authentication). Likewise, some network 825 requirements cannot be determined until PPP NCP negotiation. 827 The DIAMETER protocol should be able to provide similar functions 828 [13,14]. An extensible set of resources should be able to be 829 allocated and deallocated by the NAS, upon request by the server. 830 The server then serves as a management point of the resource for all 831 clients of the server. This service would be optional to the 832 implementation. 834 Additional capability should be provided, where the server or client 835 may interrogate identified resource's status, and the server can 836 revoke or modify the resource status [14]. This is similar to the 837 ability to re-authorize NAS services from the Server. 839 This type of service MAY be robust in nature, in that the server may 840 use a permanent store, or a state distribution protocol to 841 synchronize backup servers between outages. The reliability of such a 842 service will be implementation and configuration dependent. The 843 design of high availability state protocol is beyond the scope of 844 what we wish to attempt at this time. Only an interface would be 845 specified. 847 Such a service must scale reasonably in the presence of proxy 848 systems. Broadcast or wildcard queries will not be allowed. It is 849 highly likely that resources may be managed in different locations. 850 For example, IP addresses may be managed locally, while user login 851 concurrency checking could be done remotely. 853 Maintenance of a consistent image of resources in use is a genuinely 854 hard problem in the face of server, NAS and network failures and PDU 855 reordering. The protocol support should give clear guidance to 856 implementors of the known implementation techniques, such as upstream 857 querying by a recovering server, periodic reconfirm (aka interim 858 accting) by the NAS, & inter-server replication. And on the danger 859 of self-inflicted DoS if the model is not somehow self-correcting. 861 13.0 Access Rules and Filters 863 The AAA protocol must support powerful semantics for setting 864 constraints on what an authenticated user may do. That is, it should 865 lean toward being able to invoke any capability that any NAS can 866 provide in this area, rather than restrict itself to being able to 867 express things that every NAS can provide - because the latter is 868 completely inadequate to protect the Internet against malicious 869 users. 871 Examples of specific expressive power that must be provided: 872 - source address assurance 873 - prevention of IP options 874 - prevention of specific IP options, such as source routing 875 - prevention of malicious fragmentation, such as offset=1 876 - restriction of SMTP connections to the home server only 877 and so on. 879 This implies of course that the action of the NAS when it cannot 880 support a particular filter capability must be specified. (Here 881 'NAS' might really be a proxy that translates the AAA syntax to 882 vendor-specific syntax for the particular NAS.) 884 13.1 Access Rules and Filters Action Item List 886 The action items identified in this section are summarized as 887 follows: 889 1.) Design a syntax for access rules and filters that has 890 sufficient expressive power use in current and clearly 891 foreseeable networks. Extensibility and ability to 892 incorporate vendor-specific capabilities are highly desirable. 893 2.) Specify NAS behavior when it is unable to implement a 894 particular rule. 896 14.0 AAA Server Discovery 898 In some cases, AAA servers may be dynamically discovered. This 899 allows for more robust deployments of network access services, for 900 example. If a primary AAA server fails, for which an AAA client is 901 configured, the AAA client can discover another suitable AAA server. 903 In order to promote interoperable implementations, a definite 'search 904 order' should be recommended, if dynamic service discovery is 905 employed. For example, the search order could be: 906 1. Use static (manual) configuration if it exists. 907 2. Use DNS SRV RR for DIAMETER services, if it exists. 908 3. Use SLP to discover administratively DIAMETER services. 910 Dynamic discovery of AAA servers will only be secure if previous 911 configuration provided AAA clients with the security parameters which 912 can be used to authenticate the discovered AAA server. This is 913 possible, for instance, using DNS security, SLPv2 authentication, 914 etc. 916 In some respects configuring hosts to enable them to do dynamic 917 configuration seems at cross purposes. Here the goal is not zero 918 administration but rather robust deployment (so clients can 919 automatically find servers, for instance, in the case that a server 920 fails or is swapped out). 922 14.1 Server Discovery Action Item List 924 The action items identified in this section are summarized as 925 follows: 927 1.) Specific worked out solutions for how to discover AAA servers 928 both locally (in the same administrative domain) or across the 929 internet. 930 2.) For each of the above solutions, describe how the mechanism 931 could be made secure, so that AAA clients could verify that 932 the AAA server they discover is 'trustworthy' according to 933 some policy. What preconfiguration is needed? What policy 934 (with respect to trust) is implied by possesion of a key? 936 15.0 Loop Detection 938 In current RADIUS networks, it is possible for an improperly 939 configured domain routing table to cause messages to be stuck in a 940 loop. The DIAMETER protocol does not provide any loop detection, and 941 therefore is subjected to the same problem. 943 The Mobile IP extension does have a requirement that some messages 944 destined for the home DIAMETER server be sent back to the visited 945 DIAMETER server for Home Agent allocation. Therefore, the loop 946 detection must be designed to in such a way that the Mobile IP 947 extension can still be used as specified. 949 15.1 Loop Detection Action Item List 951 The action items identified in this section are summarized as 952 follows: 954 1.) Determine how the protocol can be enhanced to detect loops, 955 without breaking end-to-end security. 956 2.) Ensure that the mechanism does allow for certain messages to 957 loop back to the requestor, when it is intended to do so. 959 16.0 Issues identified in the Mailing List 961 The following issues have been raised in the AAA Mailing list, and 962 are included in this document for completeness. 964 16.1 DIAMETER Identifier Field 966 The DIAMETER base protocol does not properly describe the function of 967 the identifier field in the protocol header. The original intent of 968 the field was to facilitate the originator of a request's task of 969 matching up the corresponding response. This field was NOT intended 970 to be mutable (meaning it cannot be changed by intermediate proxies). 972 The issue at hand is whether this field actually provides useful 973 functionality in the protocol, or whether it should be removed. 975 16.2 DIAMETER State Machine 977 A buf in the DIAMETER state machine was raised on the mailing list. 978 The state machine states that once a transport level connection is 979 established, and a DRI is received, the state should move to the open 980 state. This should be changed to reflect a new state called the 981 Wait-DRI state. The connection stays in this state until the peer's 982 DRI is received. 984 17.0 IANA Considerations 986 DIAMETER makes extensive use of IDs (command codes, extensions, 987 result codes, AVP attributes, Integrity-Check-Value AVP Transform 988 code). These are collected in the base protocol specification, but 989 defined in the DIAMETER extension docs. 991 18.0 Security Considerations 992 DIAMETER [1] is a framework providing authentication and 993 authorization services for network access. Section 11 and 13 concern 994 how these features could be refined or improved in subsequent work. 996 DIAMETER itself contains a number of security features. Section 8 997 discusses how these could be redesigned for less reliance on public 998 key cryptography. 1000 19.0 Acknowledgments 1002 The authors would like to thanks Ran Atkinson and William Bulley for 1003 their valuable comments. 1005 20.0 References 1007 [1] P. Calhoun, A. Rubens, H. Akhtar, E. Guttman. "DIAMETER Base 1008 Protocol", draft-calhoun-diameter-17.txt, IETF work in progress, 1009 September 2000. 1011 [2] P. Calhoun, W. Bulley, A. Rubens, J. Haag, "DIAMETER NASREQ 1012 Extension", draft-calhoun-diameter-nasreq-05.txt, IETF work in 1013 progress, September 2000. 1015 [3] Calhoun, Zorn, Pan, Akhtar, "DIAMETER Framework", draft- 1016 calhoun-diameter-framework-08.txt, IETF work in progress, June 1017 2000. 1019 [4] P. Calhoun, C. Perkins, "DIAMETER Mobile IP Extensions", draft- 1020 calhoun-diameter-mobileip-11.txt, IETF work in progress, Sep- 1021 tember 2000. 1023 [5] P. Calhoun, W. Bulley, S. Farrell, "DIAMETER Strong Security 1024 Extension", draft-calhoun-diameter-strong-crypto-05.txt (work in 1025 progress), September 2000. 1027 [6] Arkko, Calhoun, Patel, Zorn, "DIAMETER Accounting Extension", 1028 draft-calhoun-diameter-accounting-08.txt, IETF work in progress, 1029 September 2000. 1031 [7] P. Calhoun, A. Rubens, H. Akhtar, E. Guttman, W. Bulley, J. 1032 Haag, "DIAMETER Implementation Guidelines", draft-calhoun- 1033 diameter-impl-guide-03.txt, IETF work in progress, June 2000. 1035 [8] P. Calhoun, N. Greene, "DIAMETER Resource Management", draft- 1036 calhoun-diameter-res-mgmt-05.txt, IETF Work in Progress, 1037 September 2000. 1039 [9] Aboba et al, "Network Access AAA Evaluation Criteria", IETF work 1040 in progress, draft-ietf-aaa-na-reqts-07.txt, August 2000. 1042 [10] Mitton et al, "Authentication, Authorization, and Accounting: 1043 Protocol Evaluation", IETF work in progress, draft-ietf-aaa- 1044 proto-eval-00.txt, July 2000. 1046 [11] Rigney, et alia, "RADIUS", RFC-2138, April 1997 1048 [12] RFC 2882 "NASReq Extended RADIUS Practices", Sect 6, page 9-10 1050 [14] draft-ietf-aaa-na-reqts-07.txt, Sect 4.4.3.3 Authorization 1051 Requirements, State Reconciliation, Note f 1053 [15] B. Aboba, D. Lidyard, "The Accounting Data Interchange Format 1054 (ADIF)", draft-ietf-roamops-actng-07.txt, IETF work in progress, 1055 April 2000. 1057 [16] D. Harkins, D. Carrell, "The Internet Key Exchange (IKE)", RFC 1058 1409, November 1998. 1060 [17] B. Aboba, G. Zorn, "RADIUS Authentication Client MIB", RFC 2618, 1061 June 1999. 1063 [18] G. Zorn, B. Aboba, "RADIUS Authentication Server MIB", RFC 2619, 1064 June 1999. 1066 [19] B. Aboba, G. Zorn, "RADIUS Accounting Client MIB", RFC 2620, 1067 June 1999. 1069 [20] G. Zorn, B. Aboba, "RADIUS Accounting Server MIB", RFC 2621, 1070 June 1999. 1072 [21] J. Kohl, C. Neuman, "The Kerberos Network Authentication Service 1073 (V5)", RFC 1510, September 1993. 1075 [22] S. Farrell, S. Turner, "Reuse of CMS Content Encryption Keys", 1076 draft-ietf-smime-rcek-00.txt, IETF work in progress, September 1077 2000. 1079 21.0 Authors' Addresses 1081 Questions about this memo can be directed to: 1083 Pat R. Calhoun 1084 Network and Security Research Center, Sun Labs 1085 Sun Microsystems, Inc. 1086 15 Network Circle 1087 Menlo Park, California, 94025 1088 USA 1090 Phone: +1 650-786-7733 1091 Fax: +1 650-786-6445 1092 E-mail: pcalhoun@eng.sun.com 1094 Bernard Aboba 1095 Microsoft Corporation 1096 One Microsoft Way 1097 Redmond, WA 98052 1098 USA 1100 Phone: +1 425 936-6605 1101 Fax: +1 425 936-7329 1102 E-mail: bernarda@microsoft.com 1104 Erik Guttman 1105 Network and Security Research Center, Sun Laboratories 1106 Sun Microsystems, Inc. 1107 Eichhoelzelstr. 7 1108 74915 Waibstadt 1109 Germany 1111 Phone: +49-7263-911-701 1112 E-mail: erik.guttman@germany.sun.com 1114 David Mitton 1115 Nortel Networks 1116 880 Technology Park Drive 1117 Billerica, MA 01821 1118 USA 1120 Phone: +1 978 288 4570 1121 E-mail: dmitton@nortelnetworks.com 1123 David B. Nelson 1124 Enterasys Networks, Inc. (a Cabletron Systems company) 1125 50 Minuteman Road 1126 Andover, MA 01810-1008 1127 USA 1129 Phone: +1 978 684 1330 1130 E-Mail: dnelson@enterasys.com 1132 Juergen Schoenwaelder 1133 Technical University Braunschweig 1134 Dept. Operating Systems & Computer Networks 1135 Bueltenweg 74/75, 38106 Braunschweig, 1136 Germany 1138 Phone: +49 531 391 3289 1139 Fax: +49 531 391 5936 1140 E-Mail: schoenw@ibr.cs.tu-bs.de 1142 Barney Wolff, Pres. 1143 Databus Inc. 1144 15 Victor Drive 1145 Irvington, NY 10533-1919 USA 1146 USA 1148 Phone: +1 914 591 5677 1149 E-mail: barney@databus.com 1151 Lixia Zhang 1152 UCLA Computer Science Department 1153 4531G Boelter Hall 1154 Los Angeles, CA 90095-1596 1155 USA 1157 Phone: +1 310 825 2695 1158 E-Mail: lixia@cs.ucla.edu 1160 22.0 Full Copyright Statement 1162 Copyright (C) The Internet Society (2000). All Rights Reserved. 1164 This document and translations of it may be copied and furnished to 1165 others, and derivative works that comment on or otherwise explain it 1166 or assist in its implementation may be prepared, copied, published 1167 and distributed, in whole or in part, without restriction of any 1168 kind, provided that the above copyright notice and this paragraph are 1169 included on all such copies and derivative works. However, this docu- 1170 ment itself may not be modified in any way, such as by removing the 1171 copyright notice or references to the Internet Society or other 1172 Internet organizations, except as needed for the purpose of develop- 1173 ing Internet standards in which case the procedures for copyrights 1174 defined in the Internet Standards process must be followed, or as 1175 required to translate it into languages other than English. The lim- 1176 ited permissions granted above are perpetual and will not be revoked 1177 by the Internet Society or its successors or assigns. This document 1178 and the information contained herein is provided on an "AS IS" basis 1179 and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS- 1180 CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 1181 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1182 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1183 FITNESS FOR A PARTICULAR PURPOSE.