INTERNET DRAFT Pat R. Calhoun (editor) Category: Informational Sun Microsystems, Inc. Title: draft-ietf-aaa-solutions-00.txt Date: November 2000 AAA Solutions Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html. This document is an individual contribution for consideration by the AAA Working Group of the Internet Engineering Task Force. Comments should be submitted to the diameter@diameter.org and aaa-wg@merit.edu mailing lists. Distribution of this memo is unlimited. Copyright (C) The Internet Society 2000. All Rights Reserved. Abstract The AAA Design Team has issued a document that lists issues with the DIAMETER protocol. This accompanying document is intended as an archive of proposed solutions. Once accepted, these solutions will find their way into the relevant DIAMETER specifications. Calhoun et al. expires May 2001 [Page 1]
INTERNET DRAFT November 2000 Table of Contents 1.0 Introduction 1.1 Requirements language 2.0 Error Codes and Messages 2.1 Result-Code AVP 2.2 Error-Message AVP 3.0 Accounting 4.0 IPv6 Support 5.0 Transports 6.0 Proxies 6.1 Realm-Based Message Routing 6.2 Behavior of Proxy and Redirect Servers 6.2.1 Proxy and Redirect Server handling of requests 6.3 Redirect Server 6.3.1 Redirect-Host AVP 6.3.2 Redirect-Host-Port AVP 6.4 Proxy Server 6.4.1 Proxying Requests 6.4.2 Proxying Responses 6.4.2.1 Route-Record AVP 6.4.2.2 Proxy-State AVP 6.4.2.3 Home-Realm AVP 6.5 Applying Local Policies 6.6 Hiding Network Topology 7.0 RADIUS Compatibility 8.0 End-to-End Security 9.0 Data Model 10.0 SNMP Support (DIAMETER MIB) 11.0 Re-Authentication & Authorization 12.0 Server/Resource Management State 13.0 Access Rules and Filters 14.0 AAA Server Discovery 15.0 Loop Detection 16.0 IANA Considerations 17.0 Security Considerations 18.0 Acknowledgments 19.0 References 20.0 Authors' Addresses 21.0 Full Copyright Statement Calhoun et al. expires May 2001 [Page 2]
INTERNET DRAFT November 2000 1.0 Introduction The AAA Design Team has issued a document that lists issues with the DIAMETER protocol [11]. This accompanying document is intended as an archive of proposed solutions. Once accepted, these solutions will find their way into the relevant DIAMETER specifications. Each main section should specify which DIAMETER documents its sub- sections are targetted at. Ideally, the section should also state whether the proposed text is intended to replace existing text, or added as new text. 2.0 Error Codes and Messages Section 2.1 below is intended to replace the current section 5.2 in the Base Protocol [1] specification. Section 2.2 is intended as a new section 5.3 in the Base Protocol [1]. The existing Base Protocol defines the Result-Code AVP to be of type Complex, while the following section defines the Result-Code AVP to be of type Integer, and a separate Error-Message AVP of type String. 2.1 Result-Code AVP The Result-Code AVP (AVP Code 268) is of type Integer and indicates whether a particular request was completed successfully or whether an error occurred. All DIAMETER messages of type *-Response or *-Answer MUST include one Result-Code AVP. The Result Code field contains an IANA-managed 32-bit address space representing errors (see section 8.4). The DIAMETER provides five different classes of errors, all identified by the thousands digit: - 1xxx (Informational) - 2xxx (Success) - 3xxx (Redirect Notification) - 4xxx (Transient Failures) - 5xxx (Permanent Failure) 2.1.1 Informational Errors that fall within the Informational category are used to inform a requestor that the request cannot be immediately satisfied and a further response will be issued in the near future. DIAMETER_BE_PATIENT 1001 Calhoun et al. expires May 2001 [Page 3]
INTERNET DRAFT November 2000 The DIAMETER server responsible for authentication and/or authorizing the user cannot satisfy the request at the moment, and will respond within the next 3 seconds. 2.1.2 Success Errors that fall within the Success category are used to inform a peer that a request has been successfully completed. DIAMETER_SUCCESS 2000 The Request was successfully completed. 2.1.3 Redirect Notification Errors that fall within the Redirect Notification category are used to inform a peer that the request cannot be satisfied locally and should instead be forwarded to another server. DIAMETER_REDIRECT_INDICATION 3001 A proxy or redirect server has determined that the request could not be satisfied locally and the initiator of the request should direct the request directly to the server, whose contact information has been added to the response. This error code MUST NOT be sent in a Message-Reject-Ind message. 2.1.4 Transient Failures Errors that fall within the transient failures category are used to inform a peer that the request could not be satified at the time it was received, but MAY be able to satisfy the request in the future. DIAMETER_TIME_INVALID 4001 This Result-Code value is return to inform a peer that the message received contained an invalid timestamp value (in Timestamp AVP). DIAMETER_AUTHENTICATION_REJECTED 4002 The authentication process for the user failed, most likely due to an invalid password used by the user. Further attempts MUST only be tried after prompting the user for a new password. DIAMETER_AUTHORIZATION_FAILED 4003 A request was received for which the user could not be authorized at this time. This error could occur when the user has already expended allowed resources, or is only permitted to Calhoun et al. expires May 2001 [Page 4]
INTERNET DRAFT November 2000 access services within a time period. DIAMETER_UNABLE_TO_DELIVER 4004 The request could not be delivered to a host that handles the realm requested at this time. DIAMETER_NO_END_2_END_SECURITY 4005 A proxy has detected that end-to-end security has been applied to portions of the DIAMETER message, and the proxy does not allow this security mode since it needs to alter the message by applying some local policies. DIAMETER_CONTRADICTING_AVPS 4006 The Home DIAMETER server has detected AVPs in the request that contradicted each other, and is not willing to provide service to the user. One or more Failed-AVP MUST be present, containing the AVPs that contradicted each other. 2.1.5 Permanent Failures Errors that fall within the permanent failures category are used to inform the peer that the request failed, and should not be attempted again. DIAMETER_USER_UNKNOWN 5001 A request was received for a user that is unknown, therefore authentication and/or authorization failed. DIAMETER_COMMAND_UNSUPPORTED 5002 The Request contained a Command-Code that the receiver did not recognize or support. The Message-Reject-Ind message MUST also contain a Unknown-Command-Code AVP containing the unrecognized Command-Code. DIAMETER_AVP_UNSUPPORTED 5003 The peer received a message that contained an AVP that is not recognized or supported and was marked with the Mandatory bit. A DIAMETER message with this error MUST contain one or more Failed-AVP AVP containing the AVPs that caused the failure. DIAMETER_REALM_NOT_SERVED 5004 A proxy or redirect server has determined that it is unable to forward the request or provide redirect information since the realm portion of the NAI requested is unknown. DIAMETER_UNSUPPORTED_TRANSFORM 5005 A message was received that included an Integrity-Check-Value Calhoun et al. expires May 2001 [Page 5]
INTERNET DRAFT November 2000 or CMS-Data AVP [11] that made use of an unsupported transform. DIAMETER_UNKNOWN_SESSION_ID 5006 The request or response contained an unknown Session-Id. DIAMETER_AUTHORIZATION_REJECTED 5007 A request was received for which the user could not be authorized. This error could occur if the service requested is not permitted to the user. DIAMETER_INVALID_AVP_VALUE 5008 The request contained an AVP with an invalid value in its data portion. A DIAMETER message with this result code MUST include the offending AVPs within a Failed-AVP AVP. DIAMETER_MISSING_AVP 5009 The request did not contain an AVP that is considered mandatory by the Command Code definition. If this value is sent in the Result-Code AVP, a Failed-AVP AVP SHOULD be included in the message. The data portion of the Failed-AVP MUST have its AVP Code set to the value of the missing AVP. DIAMETER_INVALID_AUTH 5010 The Request did not contain a valid Integrity-Check-Value or CMS-Data [11] AVP. DIAMETER_LOOP_DETECTED 5011 A Proxy or Redirect server detected a loop while trying to get the message to the Home DIAMETER server. Further attempts should not be attempted until the loop has been fixed. 2.2 Error-Message AVP The Error-Message AVP (AVP Code 281) is of type String and MAY be present if the message also contains a non-successful Result-Code AVP. The AVP MUST contain a human readable error message. The Error- Message AVP is not intended to be useful in real-time, and SHOULD NOT be expected to be parsed by network entities. 3.0 Accounting 4.0 IPv6 Support Calhoun et al. expires May 2001 [Page 6]
INTERNET DRAFT November 2000 5.0 Transports 6.0 Proxies This section contains text that is intended to replace all of section 6 in the DIAMETER Base protocol [1]. This section contains clarifications on the expected behavior of DIAMETER proxies and redirect servers, and also introduces new AVPs. 6.1 Realm-Based Message Routing DIAMETER Message routing is done through the use of the realm portion of the Network Access Identifier (NAI), and an associated realm routing table (see section 10.0). The NAI has a format of user@realm, and DIAMETER servers have a list of locally supported realms, and MAY have a list of externally supported realms. When a message is received that includes a realm that is not locally supported, the message is proxied to the DIAMETER entity configured in the "route" table. There are instances where the User-Name AVP is not present in authorization requests. This is typically true in networks where a request is sent to the network before the call was even answered. However, such requests MAY need to be proxied. In such cases, the first hop DIAMETER proxy MUST append the Home-Realm AVP to the DIAMETER message, by using a DNIS or ANI to Home-Realm association table. Figure 1 depicts an example where DIA1 receives a request to authenticate user "joe@abc.com". DIA1 looks up "abc.com" in its local realm route table and determines that the message must be proxied to DIA2. DIA2 does the same check, and proxies the message to DIA3. DIA3 checks its realm route table, and determines that the realm is locally supported, and processes the authentication request, and returns the response. How the response actually makes it back to the sender of the original request is described in the next section. Calhoun et al. expires May 2001 [Page 7]
INTERNET DRAFT November 2000 (Request) (Request) (User-Name=joe@abc.com) (User-Name=joe@abc.com) +------+ ------> +------+ ------> +------+ | | | | | | | DIA1 +-------------------+ DIA2 +-------------------+ DIA3 | | | | | | | +------+ <------ +------+ <------ +------+ (Response) (Response) (User-Name=joe@abc.com) (User-Name=joe@abc.com) mno.net xyz.com abc.com Figure 1: Realm-Based Routing 6.2 Behavior of Proxy and Redirect Servers This section describes the behavior of DIAMETER proxy and redirect servers in detail. In both cases, determining the next hop for a DIAMETER message is done via the Home-Realm or the User-Name AVP [1], whose syntax must comply with the Network Access Identifier (NAI) [12] specification. When present, the Home-Realm takes precedence over the User-Name AVP for routing decisions. The Home-Realm AVP, or the realm portion of the User-Name AVP is used to identify the next hop server the message must be forwarded to. Note the processing rules contained in this section are intended to be used as general guidelines to DIAMETER developers. Certain implementations MAY use different methods than the ones described here, and still be in compliance with the protocol specification. 6.2.1 Proxy and Redirect Server handling of requests Any request received by a DIAMETER server MUST perform a next hop lookup. Lookups are performed against what is commonly known as the Domain Routing Table (see section 10.0). A Domain Routing Table Entry contains the following fields: - Domain Name. The Domain Name is analogous to the realm portion of the NAI. This is the field that is typically used as a primary key in the routing table lookups. Note that some implementations perform their lookups based on longest-match- from-the-right on the realm rather than requiring an exact match. - Extension Id. It is possible for a routing entry to have a different destination based on the extension identifier of the message. This field is typically used as a secondary key field in routing table lookups. - Local Action. The Local Action field is used to identify how a Calhoun et al. expires May 2001 [Page 8]
INTERNET DRAFT November 2000 message should be treated. The following actions are supported: 1. LOCAL - DIAMETER messages that resolve to a routing entry with the Local Action set to Local can be satisfied locally, and do not need to be forwarded to another server. 2. PROXY - All DIAMETER messages that fall within this category MUST be forwarded to a next hop server. The local server MAY apply its local policies to the message by including new AVPs to the message prior to forwarding. See section 6.4 for more information. 3. REDIRECT - DIAMETER messages that fall within this category MUST have the identity of the home DIAMETER server(s) appended, and returned to the sender of the message. See section 6.3 for more information. 4. OTHER - If anyone has any ideas, please let me know what an "other" really is. - Server Identifier - One or more servers the message is to be forwarded to. When the Local Action is set to PROXY, this field contains the identities of the server the message must be forwarded to. When the Local Action field is set to REDIRECT, this field contains the Home DIAMETER server(s) for the realm. It is important to note that DIAMETER servers MUST support at least one of the PROXY, REDIRECT, or LOCAL modes of operation. Servers do not need to support all modes of operation in order to conform with the protocol specification. Server MUST NOT reorder AVPs with the same AVP Code. 6.3 Redirect Server A Redirect Server is one that provides NAI Realm to DIAMETER Home Server address resolution. When a message is received by a peer, the Home-Realm or the realm portion of the User-Name AVP is extracted from the message, and the realm portion is used to perform a lookup in the domain routing table. Implementations SHOULD also use the Extension Id as a secondary key in the domain routing table lookup. Successful routing table lookups will return one or more home DIAMETER server that could satisfy the message. The home servers are encoded in one or more Redirected-Host, and optional Redirect-Host- Port AVPs [1]. In the event that more than one such home server is returned, each AVP pair MUST be encapsulated within a Grouped-AVP. Calhoun et al. expires May 2001 [Page 9]
INTERNET DRAFT November 2000 +------------------+ | DIAMETER | | Redirect Server | +------------------+ ^ | Request | | Response + joe@xyz.com | | Result Code = | | Redirect | v +----------+ Request +----------+ | abc.net |------------->| xyz.net | | DIAMETER | | DIAMETER | | Server |<-------------| Server | +----------+ Response +----------+ Figure 4: DIAMETER Redirect Server Lastly, the Result-Code AVP is added with the value of the AVP set to DIAMETER_REDIRECT_INDICATION [1], and the message is returned to the sender of the request. Redirect servers MAY also include the certificate of the Home server(s). These certificates are encapsulated in a CMS-Data AVP [11]. When this occurs, the server forwarding the request directly to the Home DIAMETER server SHOULD include its own certificate in the message. 6.3.1 Redirect-Host AVP The Redirect-Host AVP (AVP Code 278) is of type Address and is returned in a response that has the Result-Code AVP set to DIAMETER_REDIRECT_REQUEST. This AVP includes the IP address of the DIAMETER host to which the request MUST be redirected. The presence of multiple Redirect-Host AVPs within the same Grouped-AVP, implies that all of the addresses MAY be used to contact the same host. When multiple AVPs are found that are un-grouped, or grouped with different Grouped-AVPs, they represent separate hosts. Upon receipt of such a Result-Code, and this AVP, a DIAMETER host SHOULD send the request directly to one of the hosts. 6.3.2 Redirect-Host-Port AVP The Redirect-Host-Port AVP (AVP Code 277) is of type Integer32 and MAY be present when the Redirect-Host AVP is present. The absence of this AVP implies that the reserved port MUST be used. 6.4 Proxy Server Calhoun et al. expires May 2001 [Page 10]
INTERNET DRAFT November 2000 This section outlines the processing rules for DIAMETER proxy servers. A proxy server can either be stateful or stateless. A Proxy server MAY act in a stateful manner for some requests, and be stateless for others. There are two types of states that servers MAY wish to maintain; transaction and session. Maintaining transaction state implies that a server keeps a copy of a request, which is then used when the corresponding response is received. This could be done to apply local policies to the message, or simply for auditing purposes. Maintaining session state implies that a server keeps track of all "active" users. An active user is one that has been authorized for a particular service, and the server has not received any indication that the user has relinquished access. A stateless proxy is one that does not maintain transaction, nor session state. It frees the messages sent once acknowledgements are received by the transport layer. A stateful proxy can be viewed as a DIAMETER Server upon receiving a request, and as a Client when forwarding the message. For all intensive purposes, stateful servers terminate an upstream "session", and initiates a downstream "session" (see figure x), and MAY provide the following features: - Protocol translation (e.g. RADIUS <-> DIAMETER) - Limiting resources authorized to a particular user - Per user or transaction auditing +--------+ +-----------------+ +--------+ | Client | --------> | Server | Client | -------> | Server | +--------+ +-----------------+ +--------+ Figure x - Example of Stateful Proxy A stateful proxy that maintains transaction state SHOULD release transaction information after a request's corresponding response has been forwarded towards the recipient, and has been acknowledged by the underlying transport. A stateful proxy that maintains session state SHOULD release the session state once it is informed that a user and/or device is has relinquished access. Home servers processing requests that include the Route-Record and/or the Proxy-State AVPs MUST return these AVPs in the same order in the corresponding response. 6.4.1 Proxying Requests Calhoun et al. expires May 2001 [Page 11]
INTERNET DRAFT November 2000 A proxy server MUST check for forwarding loops before proxying a request. A request has been looped if the server finds its own address in a Route-Record AVP (see [1] for more information on loop detection). A DIAMETER server that proxies a request MUST append a Route-Record AVP, which includes its identity. DIAMETER Servers that receive messages MUST validate the last Route-Record AVP in the message and ensure that the host identified in the AVP is the same as the sender of the message. A Proxy Server MAY also include the Proxy-State AVP, which is used to encode local state information. The Proxy-State AVP is guaranteed to be present in the corresponding response. If the Proxy-State AVP is present, both the Route-Record and the Proxy-State AVPs MUST be encapsulated within the Grouped-AVP AVP. The message is then forwarded to the downstream DIAMETER server, as identified in the Domain Routing Table. 6.4.2 Proxying Responses A proxy server MUST only process responses whose last Route-Record AVP matches one of its addresses. Any responses that do not conform to this rule MUST be dropped. The last Route-Record AVP MUST be removed from the message before it is forwarded to the next hop, which is identified by the second to last Route-Record AVP. 6.4.2.1 Route-Record AVP The Route-Record AVP (AVP Code 282) is of type String, and contains the Fully Qualified Domain Name of the Proxy appending the AVP to a DIAMETER message. 6.4.2.2 Proxy-State AVP The Proxy-State AVP (AVP Code 33) [1] is used by proxy servers when forwarding requests and contains opaque data that is used by the proxy to further process the response. Such data may include AVPs that are to be added to the response, information about the downstream peer, etc. 6.4.2.3 Home-Realm AVP Calhoun et al. expires May 2001 [Page 12]
INTERNET DRAFT November 2000 The Home-Realm AVP (AVP Code 283) is of type String and contains the realm portion of the Network Access Identifier. When present, the Home-Realm AVP MUST be used to perform any message routing decisions. 6.5 Applying Local Policies Proxies MAY apply local access policies to DIAMETER requests, or responses, by adding, changing or deleting AVPs in the messages. Proxies that apply local policies MUST NOT allow end-to-end security on any messages that traverse through it, unless security is terminated locally. A proxy wishing to modify a DIAMETER message to enforce some local policy that detects that end-to-end security has been applied to the message MUST return a reponse to the originator with the Result-Code set to DIAMETER_NO_END_2_END_SECURITY. The originator of the request MAY re-issue the request with no end-to-end security if it falls within its local policy. In the event that the Home DIAMETER server receives a request with contradictory information (possibly due to some proxy adding a local policy), it MAY accept the latest AVP, or MAY return the response with the Result Code AVP set to DIAMETER_CONTRADICTING_AVPS. However, a NAS receiving a response that contains contradictory information SHOULD reject service to the user. 6.6 Hiding Network Topology Stateful proxies forwarding requests to servers outside of their administrative domain MAY hide the internal network topology. Servers perform this by removing all Route-Record AVPs in the message, and maintains the Route-Record AVPs to add to the corresponding response. Such stateful servers MUST still add their own Route-Record AVP to the request prior to forwarding. 7.0 RADIUS Compatibility 8.0 End-to-End Security 9.0 Data Model Calhoun et al. expires May 2001 [Page 13]
INTERNET DRAFT November 2000 10.0 SNMP Support (DIAMETER MIB) 11.0 Re-Authentication & Authorization 12.0 Server/Resource Management State 13.0 Access Rules and Filters 14.0 AAA Server Discovery 15.0 Loop Detection This section describes how proxies detect messages that are looping through the same set of entities. This section is targetted to be numbered 6.7 in the DIAMETER Base protocol [1]. 15.1 Loop Detection When a DIAMETER Proxy or Redirect server receives a request, it MUST examine all Route-Record AVPs in the message to determine whether such an AVP already exists with the local server's identity. If an AVP with the local host's identity is found in the request, it is an indication that the message is being looped through the same set of proxies. When such an event occurs, the DIAMETER server that detects the loop returns a response with the Result-Code AVP set to DIAMETER_LOOP_DETECTED. 16.0 IANA Considerations DIAMETER makes extensive use of IDs (command codes, extensions, result codes, AVP attributes, Integrity-Check-Value AVP Transform code). These are collected in the base protocol specification, but defined in the DIAMETER extension docs. 17.0 Security Considerations Calhoun et al. expires May 2001 [Page 14]
INTERNET DRAFT November 2000 DIAMETER [1] is a framework providing authentication and authorization services for network access. Section 11 and 13 concern how these features could be refined or improved in subsequent work. DIAMETER itself contains a number of security features. Section 8 discusses how these could be redesigned for less reliance on public key cryptography. 18.0 Acknowledgments At this time, the authors have themselves to thank :) 19.0 References [1] P. Calhoun, A. Rubens, H. Akhtar, E. Guttman. "DIAMETER Base Protocol", draft-calhoun-diameter-17.txt, IETF work in progress, September 2000. [2] P. Calhoun, W. Bulley, A. Rubens, J. Haag, "DIAMETER NASREQ Extension", draft-calhoun-diameter-nasreq-05.txt, IETF work in progress, September 2000. [3] Calhoun, Zorn, Pan, Akhtar, "DIAMETER Framework", draft- calhoun-diameter-framework-08.txt, IETF work in progress, June 2000. [4] P. Calhoun, C. Perkins, "DIAMETER Mobile IP Extensions", draft- calhoun-diameter-mobileip-11.txt, IETF work in progress, Sep- tember 2000. [5] P. Calhoun, W. Bulley, S. Farrell, "DIAMETER Strong Security Extension", draft-calhoun-diameter-strong-crypto-05.txt (work in progress), September 2000. [6] Arkko, Calhoun, Patel, Zorn, "DIAMETER Accounting Extension", draft-calhoun-diameter-accounting-08.txt, IETF work in progress, September 2000. [7] P. Calhoun, A. Rubens, H. Akhtar, E. Guttman, W. Bulley, J. Haag, "DIAMETER Implementation Guidelines", draft-calhoun- diameter-impl-guide-03.txt, IETF work in progress, June 2000. [8] P. Calhoun, N. Greene, "DIAMETER Resource Management", draft- calhoun-diameter-res-mgmt-05.txt, IETF Work in Progress, Sep- tember 2000. Calhoun et al. expires May 2001 [Page 15]
INTERNET DRAFT November 2000 [9] Aboba et al, "Network Access AAA Evaluation Criteria", IETF work in progress, draft-ietf-aaa-na-reqts-07.txt, August 2000. [10] Mitton et al, "Authentication, Authorization, and Accounting: Protocol Evaluation", IETF work in progress, draft-ietf-aaa- proto-eval-00.txt, July 2000. [11] Calhoun et al., "AAA Problem Statements", IETF work in progress, draft-ietf-aaa-issues-01.txt, October 2000. [12] Aboba, Beadles "The Network Access Identifier." RFC 2486. Janu- ary 1999. 20.0 Authors' Addresses Questions about this memo can be directed to: Pat R. Calhoun Network and Security Research Center, Sun Labs Sun Microsystems, Inc. 15 Network Circle Menlo Park, California, 94025 USA Phone: +1 650-786-7733 Fax: +1 650-786-6445 E-mail: pcalhoun@eng.sun.com Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA Phone: +1 425 936-6605 Fax: +1 425 936-7329 E-mail: bernarda@microsoft.com Erik Guttman Network and Security Research Center, Sun Laboratories Sun Microsystems, Inc. Eichhoelzelstr. 7 74915 Waibstadt Germany Calhoun et al. expires May 2001 [Page 16]
INTERNET DRAFT November 2000 Phone: +49-7263-911-701 E-mail: erik.guttman@germany.sun.com David Mitton Nortel Networks 880 Technology Park Drive Billerica, MA 01821 USA Phone: +1 978 288 4570 E-mail: dmitton@nortelnetworks.com David B. Nelson Enterasys Networks, Inc. (a Cabletron Systems company) 50 Minuteman Road Andover, MA 01810-1008 USA Phone: +1 978 684 1330 E-Mail: dnelson@enterasys.com Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Bueltenweg 74/75, 38106 Braunschweig, Germany Phone: +49 531 391 3289 Fax: +49 531 391 5936 E-Mail: schoenw@ibr.cs.tu-bs.de Barney Wolff, Pres. Databus Inc. 15 Victor Drive Irvington, NY 10533-1919 USA USA Phone: +1 914 591 5677 E-mail: barney@databus.com Lixia Zhang UCLA Computer Science Department 4531G Boelter Hall Calhoun et al. expires May 2001 [Page 17]
INTERNET DRAFT November 2000 Los Angeles, CA 90095-1596 USA Phone: +1 310 825 2695 E-Mail: lixia@cs.ucla.edu 21.0 Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this docu- ment itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of develop- ing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The lim- ited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS- CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Calhoun et al. expires May 2001 [Page 18]
