ROAMOPS Working Group Bernard Aboba INTERNET-DRAFT Microsoft Corporation Dave Lidyard 26 March 1997 Telco Research Corporation The Accounting Problem in Roaming 1. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working docu- ments of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute work- ing 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 mate- rial or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). The distribution of this memo is unlimited. It is filed as , and expires October 1, 1997. Please send comments to the authors. 2. Abstract This document describes the accounting problems that arise in provid- ing dialup roaming capabilities. These include issues relating to standardization of accounting record formats, and inter-provider transfers of accounting record bundles. Work relevant to the solution of these problems are reviewed, and recommendations are made on the direction of future standardization work. 3. Introduction As detailed in [2], solution of the accounting problem in roaming requires several elements to be put in place: 1. A standardized accounting record format must be provided in order to allow ISPs to communicate accounting information to the roaming consortia as well as to each other. 2. A mechanism must be provided in order for these accounting records to be securely transferred to an accounting agent. 3. A mechanisms must be employed to deter fraud and allow for auditing. This document describes a proposed architecture for roaming Aboba & Lidyard [Page 1] INTERNET-DRAFT 26 March 1997 accounting, as well as proposing a method for the secure transfer of accounting records. Issues relevant to accounting record formats are discussed, as are security issues relevant to roaming accounting. 3.1. Terminology This document frequently uses the following terms: Network Access Server The Network Access Server (NAS) is the device that clients contact in order to get access to the network. Accounting The goal of network accounting is to accurately measure and record metrics relevant to the analysis of usage and the billing of users and organizations. Checkpoint event A checkpoint event is an accounting event that presents a snapshot of resource usage during a user's session. Session record A session record represents a summary of the resource con- sumption of a user over the entire session. Accounting gate- ways creating the session record may do so by processing checkpoint events. Accounting Protocol A protocol used for the communication of accounting events. Full Service Accounting Protocol An accounting protocol that in addition to communicating accounting events provides for encryption and signing of accounting data, as well as signed receipts. Full service accounting protocols are desirable for use in inter-organi- zational accounting. Intra-organizational accounting event An intra-organizational accounting event is one which is generated by the local ISP's users. Inter-organizational accounting event An inter-organizational accounting event is one which is generated by customers of other ISP's. Accounting Gateway The Accounting Gateway is a server which receives accounting data from network devices such as a NASes and routers, translates this data into session records, and routes the session records to intra and inter-organizational billing servers. Aboba & Lidyard [Page 2] INTERNET-DRAFT 26 March 1997 4. Overview of the roaming accounting architecture The goal of the roaming accounting architecture is to enable ISPs to be compensated for use of the their network infrastructure by roaming users. The accounting architecture, which is shown below, involves interactions between network devices such as NASes and routers, accounting gateways, billing servers, and accounting servers. Rather than merely proxying RADIUS accounting packets, it is envisaged that roaming consortia members will employ accounting gateways in order to translate between the accounting protocols used by their NAS devices and routers and a standard accounting record format used within the roaming consortia. It is also the duty of the accounting gateway to arrange for the transfer of accounting record bundles to the accounting agent. The use of accounting gateways allows ISPs not using RADIUS accounting to participate in the consortia. Today there is NAS accounting proto- col on the standards track, and as a result, the diversity of solu- tions employed in accounting (which include SNMP, TACACS+, RADIUS, and SYSLOG) is greater than that for authentication/authorization where RADIUS has reached proposed standard status and is supported by the majority of equipment vendors. In addition, use of RADIUS accounting proxies cannot provide for encryption and digital signing of Account- ing-requests, or signed Accounting-Responses. Since encryption and digital signing, as well as signed receipts are roaming requirements as described in [2], an alternative approach had to be taken. This was to define a standard accounting record format and transfer protocol. In addition to serving the translation function, local ISP accounting gateways are also responsible for summarizing checkpoint events into session records, as well as routing accounting events. Local ISP accounting events fall into two categories: intra-organizational accounting events, which are events generated by local customers; and inter-organizational accounting events, which are events generated by customers from other members of the roaming consortia. One of the functions of the accounting gateway is to distinguish between the two types of events and route them appropriately. For accounting events originating on a local ISP, intra-organizational accounting events are routed to the local billing server, while inter-organizational accounting events will be routed to the accounting agent. While it is not required that the accounting record formats used in inter and intra-organizational accounting transfers be the same, this is highly desirable, since this eliminates translations that would otherwise be required. In the roaming accounting architecture, the function of the accounting agent is to compute charges owed by member organizations. While a roaming consortium may act as the accounting agent, it is also possi- ble for ISPs to settle among themselves. When the accounting agent's accounting gateway receives inter-organizational events from a local ISP's accounting gateway, it routes the events to the accounting server, and in addition may send copies to the home ISP. Copies are provided in order to enable the home ISP to audit accounting agent Aboba & Lidyard [Page 3] INTERNET-DRAFT 26 March 1997 charges, as well to bill back to the originating domain. It should be noted that it is also possible for local ISPs to send copies directly, rather than relying on the accounting agent for this function. Once received by the home ISP, the copied accounting records will be processed by the home ISP's billing server, and will also typically be copied to the originating organization. +------------+ +------------+ +------------+ | | | | | | | ISPB | | ISPA | | ISPA | | Router | | Billing |<---------| Acctg. | | | | Server | | Gateway | | | | | | | +------------+ +------------+ +------------+ | ^ Accounting | | Protocol | Inter-organizational | (RADIUS, | Accounting Events | SNMP, | | Syslog, | | TACACS+, | | etc.) | | | | V V +------------+ +------------+ | | | | | ISPB | Inter-organizational | ISPGROUP | | Acctg. |<----------------------------->| Acctg. | | Gateway |\ Accounting Events | Gateway | | | \ | | | | \ | | +------------+ \ +------------+ ^ \ | | \ Intra-organizational | Accounting | \ Accounting Events | Protocol | \ | (RADIUS, | \ | SNMP, | \ | Syslog, | \ | TACACS+, | \ | etc.) | \ | | \ V +------------+ +------------+ +------------+ | | | | | | | ISPB | | ISPB | | ISPGROUP | | NAS | | Billing | | Accounting | | | | Server | | Server | | | | | | | +------------+ +------------+ +------------+ ^ PPP | Protocol | | Aboba & Lidyard [Page 4] INTERNET-DRAFT 26 March 1997 V +------------+ | | | | | Fred | | | | | +------------+ 5. Location of the accounting agent In order for the local ISP's accounting gateway to be able to upload an accounting record bundle to the accounting agent, it will typically be necessary for there to be a prexisting relationship between the local ISP and the accounting agent. As a result, it is expected that the ISP's accounting gateway will be statically configured with the domain names and addresses of its accounting agents. The configuration files might appear as follows: ispc.com accounting-agent=acct.ispc.com port=25 ispgroup1.com accounting-agent=acct.ispgroup1.com port=25 ispgroup2.com accounting-agent=www.ispgroup2.com port=1649 These configuration files imply that ISPB belongs to the roaming con- sortia ISPGROUP1 and ISPGROUP2, and that accounting records bound for these roaming consortia should be sent to the accounting agents oper- ated within these domains. On the other hand, ISPB sends accounting bundles to the ISPC accounting agent directly. In this case, the configuration file indicates that accounting bundles for ISPC should be sent to the machine acct.ispc.com on port 25; that accounting bundles for ISPGROUP1 should be sent to acct.ispgroup1.com on port 25, and that accounting bundles for ISPGROUP2 should be sent to www.ispgroup2.com on port 1649. In order to provide information on the transaction endpoints as well as all the intermediate participants, it is desirable for accounting records to include the roaming relationship path, and for accounting record bundles to include the name of the accounting agent to whom the records are to be submitted. Where DNS REL RRs are used, the accounting gateway needs to maintain a cache mapping domains to roaming relationship paths and accounting agents. When the accounting gateway receives a RADIUS Accounting- Request message (START or STOP), it will find the roaming relationship path and accounting agent corresponding to the NAI in the cache, and will insert this in the accounting record for the session. The cache is filled in as DNS REL RRs are received. Ordinarily a REL RR is kept in the cache until it times out. This implies that the cache will typically remain constant between the time that the authen- tication is processed and when the accounting records are generated. Aboba & Lidyard [Page 5] INTERNET-DRAFT 26 March 1997 The possible exceptions to this behavior are when the TTL expires in mid-session or if the accounting gateway is restarted, resulting in a flushing of the cache. In these cases if the REL RR has changed it is possible that the existing sessions may be accounted for incorrectly. To avoid this, the accounting gateway MUST NOT modify the cache entry for a domain with a session in progress. 6. Accounting transfer protocol issues 6.1. Accounting transfer protocol requirements Given that large sums of money may change hands as a result of roaming accounting transfers, it is highly desirable that the accounting records be transferred securely and robustly. Requirements include: Security In order to address security concerns, it is desirable for an inter-organizational accounting transfer protocol to sup- port mutual authentication; signing of accounting record bundles; signed receipts for accounting record transfers; and encryption of accounting record bundles. Accounting gateways will also need to be able to reliably route accounting record bundles to the appropriate destinations. Durability Durability implies that an inter or intra-organizational accounting transfer protocol must be able to recover from a variety of faults, including partially completed transfers and non-supported metrics. 6.2. Accounting transfer protocol recommendation The requirements for roaming accounting record transfers closely resemble the requirements for interoperable Internet Electronic Docu- ment Interchange (EDI). As described in [12], both applications may make use of encryption and digital signatures as well as requests for signed receipts. Since these features are also of interest in a wide variety of EDI and Electronic Commerce (EC) applications, the EDIINT working group has been chartered to standardize their use over the Internet. For further information on the mechanisms proposed for secure EDI over the Internet, please consult references [6] - [12]. Given the close correspondence between the work of the EDIINT working group and the requirements for roaming accounting record transfer, it is proposed that the ROAMOPS working group consider adoption of MIME- based Secure EDI, as described in [11], for accounting record trans- fers. With MIME-based secure EDI, accounting record bundles are trans- ferred using S/MIME or PGP/MIME over SMTP. Since SMTP server technol- ogy is mature, it is believed that this method can satisfy durability as well as security requirements. Since Secure MIME-enabled mail servers are expected to become widely available, use of this technology will enable rapid deployment of technology for secure accounting record transfers. Given the likely widespread availability of Secure MIME-enabled mail technology, it is Aboba & Lidyard [Page 6] INTERNET-DRAFT 26 March 1997 recommended that the ROAMOPS working group not consider less secure alternatives. It should be noted that in order to make use of the techniques pro- posed in [11], it is not required that accounting record formats con- form to EDI standards such as UN/EDIFACT or EDI X.12, although this may be desirable in some circumstances. What is required is that a MIME type be defined for the accounting record format. When used to implement secure inter-organizational accounting record transfers in roaming, it is recommended that accounting record bundles be encrypted as well as signed, and that a signed receipt be requested. It is recommended that S/MIME be used for this purpose. Since MIME-based secure EDI requires public key authentication tech- nology, a mechanism must be provided for acquiring the public key of the participants in an exchange. While DNS Security can be used for this purpose, this is not required, since in roaming, accounting record bundles need only be transferred between entities with a pre- existing relationship. As a result, it is possible to statically con- figure accounting gateways with the required public keys. 7. Accounting record format issues 7.1. Accounting record format requirements In order to allow for accounting record bundles between organizations, it is necessary to provide for a standard accounting record format. Desirable qualities for an accounting record format include: Extensibility While the standard accounting record format must be able to encode metrics commonly used by ISPs in determining a user's bill, it must also be extensible so that other metrics can be added in the future. These metrics may either be IETF- standard metrics, or they may be vendor-specific metrics. Since it is possible that the accounting record format will itself evolve over time, or that multiple formats will be in common use, it is necessary that the type and version of the accounting record be communicated as part of the accounting record transfer. Compactness Given the growth of the Internet, today's ISPs process a large number of accounting records every day. Not only does processing of the records require many CPU cycles, but transmitting the records can consume considerable bandwidth. Therefore it is desirable for the accounting record format to be as compact as possible, and to contribute to efficient processing. Aboba & Lidyard [Page 7] INTERNET-DRAFT 26 March 1997 7.2. ASCII vs. BINARY formats Today most accounting records are in NVT ASCII, often with a fixed record format. This has the advantage of being easy to read and debug, as well as being easy to parse. However, the use of a fixed format is a substantial liability, since new accounting metrics are continually emerging. In order to provide for extensibility, it is possible to specify a fixed format for the initial portion of the accounting record, while allowing additional metrics to be added via use of appropriate tags. In order to allow a record to extend over multiple lines, it is possi- ble to specify that lines beginning with one or more spaces should be considered a continuation of the previous line. Most NVT ASCII accounting formats now in use consume between 60 and 140 octets per record. However, these records are highly compressible, often exhibiting compression ratios of 3:1 or greater, so that when compressed accounting bundles are transmitted, space consumption of 50 octets/record is frequently achievable. Via use of Attribute Value Pairs (AVPs), binary accounting record for- mats are easily engineered for extensibility, and as a result, they are popular for use in accounting protocols such as RADIUS and TACACS+. Via use of a vendor field, it is possible to ensure that ven- dor-specific metrics will not conflict with IETF-defined accounting metrics, and assuming that suitable space is left for length and attribute fields, it is possible to allow for representation of a large number and variety of accounting metrics. Since NAS devices and routers typically provide accounting data in binary format, binary accounting records can typically be generated more easily than NVT ASCII records. Similarly, billing servers can process these records more efficiently, since less parsing and conver- sion is required. Binary accounting records are also typically more compact than NVT ASCII formats, although this advantage is reduced when compression is employed. Although binary accounting records are typically compress- ible, they are typically much less compressible than equivalent NVT ASCII formats. 7.3. Accounting metrics Accounting in a roaming environment requires adherence to standards which allow access to be measured, rated, assigned, and communicated between appropriate service providers. In this inter-provider envi- ronment, there is a need for a set of controls that can be used to audit billing practices and to mediate billing disputes. The founda- tion for satisfying these requirements is the content of the account- ing record. The goal of the accounting record is to identify who is accessing the network, who is providing the access service, from what location is access being provided, and when the accesses occur. Aboba & Lidyard [Page 8] INTERNET-DRAFT 26 March 1997 The identity of the user, their home ISP, and service privileges are the key elements for authenticating, authorizing, and assigning cost. These components allow the local service provider to authorize service and understand to whom accounting information should be sent. These same components provide the home authenticating party with the infor- mation to identify the originating user, their roaming consortium, and the applicable service level agreements. The local ISP provides access. Since the home ISP presents the bill to the customer, in most cases they will be responsible for sales taxes, but this may not universally be the case. It is possible that there will be taxes or other charges mandated by local governing bodies which need to be absorbed and rebilled. As a result, it is necessary for the identity of both the local and home ISP to be included, as well as the location of the called POP to be included in the account- ing record. Including this information also allows roaming consortia to evaluate access patterns and trends in an effort to leverage high service areas for better rates and/or service. It is also useful for the accounting record to include the date and time of access, in order to make it possible to analyze diurnal curves and devise programs oriented toward load leveling. Including session duration is useful as an input to the rating process as well as for capacity planning and fraud detection. The type of access and access speed may also be relevant in rating. Suggested accounting metrics include: Session ID Unique ID identifying the session Multi-Session ID For linking of multiple related sessions NAI Network Access Identifier (NAI), the userID that is presented during the authentication process. Peer Network Address The IP address assigned to the user Home ISP Identity of the home ISP. Local ISP The local ISP providing access. NAS Host Name The name of the NAS providing access. NAS IP address The IP address of the NAS providing access. NAS Port The physical port of the NAS providing access. Call Type Indicates type of call, i.e. async vs. Sync ISDN, V.120, etc. Service Type Type of service provided to the user Call Direction Indicates inbound or outbound call B Channel interface name Indicates name of B channel interface Link Count Number of links up when record was generated Local Time Zone Time zone where access was provided. Start Date & Time Session starting date and time (at source) Disconnect Date & Time Session ending date and time (at source) Elapsed Duration Seconds of received service Method of Access Disconnect Cause Code The reason the call was disconnected Originating Number Enables the computation of access charges in a toll area. Access Number The phone number dialed to reach the local ISP. Packets Transmitted Packets sent to port Packets Received Packets received from port Aboba & Lidyard [Page 9] INTERNET-DRAFT 26 March 1997 OCTETS Transmitted Octets sent to port OCTETS Received Octets received from port Summary Charge Aggregated charge of this accounting record. Charge detail Entries for each type of charge and the amount used to compute the summary charge. This includes access service fees, usage related charges, and taxes. Other charge detail may be applicable. Currency code Currency in which the charges are expressed. Memo Data General area for ISPs to communicate additional information related to each accounting record. Authorization Code Digitally signed token included to ensure legitimacy. Form TBD. Roaming Rel. Path The path of roaming relationships connecting the local ISP to the home authentication server. 7.4. Case study Let us assume that we have a roaming user Fred, who works at BIGCO. BIGCO has established a relationship with ISPA, who has joined the roaming consortia ISPGROUP. Fred now travels to another part of the world and wishes to dial in to the network provided by ISPB. ISPB will account for Fred's resource usage, and will submit a session record to ISPGROUP for compensation. ISPGROUP will in turn bill ISPA, who will bill BIGCO. Eventually BIGCO will pay ISPA, ISPA will pay ISPGROUP, and ISPGROUP will pay ISPB. In order for all parties to verify that they have been properly charged or compensated for Fred's session, the following events must occur: ISPB: Network devices generate accounting data for Fred ISPB: Accounting gateway generates a session record for Fred ISPB: Accounting gateway routes the session record to ISPGROUP and to the local billing server ISPB: Billing server processes the session record, credits ISPGROUP account ISPGROUP: Accounting gateway routes the session record to the accounting server and to ISPA ISPGROUP: Accounting server processes the session record, credits ISPA account, debits ISPB account ISPA: Accounting gateway routes the session record to the local billing server and to BIGCO ISPA: Billing server processes the session record, credits BIGCO account, debits ISPGROUP account BIGCO: Accounting gateway routes the session record to the local billing server BIGCO: Billing server processes the session record, credits Fred's account, credits ISPA account. Each of these events is discussed below. 7.5. ISPB network devices generate accounting data for Fred In order to keep track of network resources consumed by Fred, ISPB's accounting gateway will collect accounting data produced by network Aboba & Lidyard [Page 10] INTERNET-DRAFT 26 March 1997 devices such as routers and NASes. This data may be produced in many forms, and may be communicated via a variety of protocols, including RADIUS, TACACS+, SNMP, and SYSLOG. The accounting data may be trans- mitted from network devices to the accounting gateway (as in RADIUS, TACACS+, SYSLOG, or SNMP traps), or the accounting gateway may poll for the data (via SNMP GETs). Accounting data may refer to resources consumed over the life of a session, or it may be a checkpoint event. Checkpoint events refer to resource consumption at a specific point in time, rather than repre- senting a summary of resources consumed over a session. Prior to transfer to a billing server or accounting agent, checkpoint events are typically summarized into a session record. 7.6. ISPB accounting gateway generates a session record for Fred Since there is currently no standards-track network accounting proto- col, ISP accounting practices vary more widely than authentication practices, where RADIUS authentication is very widely deployed. As a result, it appears difficult to standardize on an accounting protocol that can be used for communication between ISPs and a accounting agent. Therefore, the roaming accounting architecture anticipates that while ISPs will use an accounting protocol of their choice to communi- cate accounting information between network devices and the accounting gateway, a standardized accounting record format and transfer method will be used for communication between accounting gateways. In order to allow for transmission of accounting information to the accounting agent, ISPB will summarize the accounting information relating to Fred's session in a standard session record format. 7.7. ISPB accounting gateway routes the session record to ISPGROUP and to the local billing server ISPB's accounting gateway examines Fred's session record, and routes it to the appropriate destinations. It does this based on whether the accounting records refer to transactions occurring within the ISP's organization, or whether they refer to transactions occurring between organizations. In this case, since Fred is a roaming user, this is an inter-organizational accounting event, and the accounting gateway will send session record to the accounting agent, as well as to the local biling server. In this example, the accounting agent is run by ISP- GROUP, but it could just as easily be run by ISPA, in which case the two ISPs would settle directly. When routing accounting record bundles, ISPB's accounting gateway machine will operate as an S/MIME or PGP/MIME-enabled SMTP server. In order to improve efficiency, the accounting gateway will sort account- ing records into bundles prior to mailing them to their destination. When a suitable bundle of accounting records has been accumulated, the accounting gateway will initiate the transfer. In this case, Fred's accounting record will be sent to multiple destinations. Aboba & Lidyard [Page 11] INTERNET-DRAFT 26 March 1997 While intra-organizational accounting transfers typically will not require signed accounting bundles or signed receipts, it still may prove useful to request that a receipt be generated in order to be able to confirm the success of the transfer. Use of receipts will allow an accounting gateway to keep track of discrepancies between the number of accounting record bundles it believes were successfully sent to the local billing server, and the number of receipts collected. These discrepancies can be used to detect partially completed account- ing record transfers and to retransmit them. When used to transfer an accounting record bundle to the accounting agent, ISPB will encrypt the bundle, as well as signing it, and will request a signed receipt. 7.8. ISPB billing server processes the session record, credits ISP- GROUP account In order to allow itself to audit the charges and/or compensation offered by ISPGROUP, ISPB's billing server will process Fred's session record and credit the ISPGROUP account (an asset). If SMTP is used to transmit the session record between the accounting gateway and billing server, then the billing server will need to retrieve the accounting record bundle from its mailbox and process it, sending a receipt in response to the accounting gateway's request. 7.9. ISPGROUP accounting gateway routes the session record to the accounting server and to ISPA Once ISPGROUP receives the signed and encrypted accounting record bun- dle from ISPB, it will send back a signed receipt as requested, and in addition will verify the signature, decrypt the bundle, and then send copies to the accounting server as well as to ISPA. This is done in order to enable ISPA to audit the bill received from ISPGROUP, as well as to bill back BIGCO for the charges. In transferring the accounting record bundle to ISPA, ISPGROUP will encrypt it, and sign it, in addi- tion to requesting a receipt. 7.10. ISPGROUP accounting server processes the session record, cred- its ISPA account, debits ISPB account ISPGROUP's accounting server processes the session record, and as a result, ISPA's account (an asset) is credited, and ISPB's account (an asset) is debited. If SMTP is used to transmit the session record between ISPGROUP's accounting gateway and the accounting server, then the accounting server will need to retrieve the accounting record bun- dle from its mailbox and process it, sending a receipt in response to the accounting gateway's request. 7.11. ISPA accounting gateway routes the session record to the local billing server and to BIGCO Once ISPA has received the signed accounting record bundle from ISP- GROUP, it will send back a signed receipt as requested, and in addi- tion will verify the signature, decrypt the bundle, and then send Aboba & Lidyard [Page 12] INTERNET-DRAFT 26 March 1997 copies to the local billing server as well as to BIGCO. This is done in order to enable BIGCO to audit the bill for Fred's usage.In trans- ferring the accounting record bundle to BIGCO, ISPA will encrypt it, and sign it, in addition to requesting a receipt. 7.12. ISPA billing server processes the session record, credits BIGCO account, debits ISPGROUP account ISPA's billing server processes the session record, and as a result, BIGCO's account (an asset) is credited, and ISPGROUP's account (an asset) is debited. If SMTP is used to send the session record between ISPA's accounting gateway and the billing server, then the billing server will need to retrieve the accounting record bundle from its mailbox and process it, sending a receipt in response to the account- ing gateway's request. 7.13. BIGCO accounting gateway routes the session record to the local billing server Once BIGCO has received the signed accounting record bundle from ISPA, it will send back a signed receipt as requested, and in addition will verify the signature, decrypt the bundle, and then forward the message to the local billing server. 7.14. BIGCO billing server processes the session record, credits Fred's account, credits ISPA account BIGCO's billing server processes the session record, and as a result, Fred's account (an asset) is credited, as is ISPA's account (a liabil- ity). If SMTP is used to transit the session record between BIGCO's accounting gateway and the billing server, then the billing server will need to retrieve the accounting record bundle from its mailbox and process it, sending a receipt in response to the accounting gate- way's request. 8. Security considerations The Secure MIME-based accounting record transfer method proposed in this draft provides for mutual authentication and encryption of accounting record bundles, as well as for signed receipts. As a result, the roaming consortia may be assured that an accounting record bundle originated with the local ISP, and the local ISP may be assured that the roaming consortia has received the bundle as sent. In addition, since this document provides for accounting records to be provided to all parties along the roaming relationship path, some degree of auditing is available. For example, in the case study an accounting record was generated by ISPB, and provided to the roaming consortia, as well as to ISPA, and BIGCO. Where hierarchical authenti- cation routing is used, the parties on the roaming relationship path will also typically have proxied the RADIUS Access-Request and Access- Accept packets resulting in authentication and authorization. As a result, each of the parties will be able to match up the received accounting records with an event in their authentication logs. This Aboba & Lidyard [Page 13] INTERNET-DRAFT 26 March 1997 provides for a limited degree of auditing. Where hierarchical authentication routing is employed, having the accounting agent on the authentication route as the first hop is highly desirable, since this makes it more difficult for the local ISP to submit accounting records for fictitious sessions. If the authenti- cation and accounting routes are aligned, this type of fraud requires cooperation of one of the intermediate proxies. In order to close off this possibility, it is necessary to support non-repudiation of the home authentication server's Access-Accept, possibly via use of a signed message digest. However, it should be noted that considerable leeway still exists for other fraudulent behavior by the local ISP. Since the local ISP must have access to any private keys used for signing by accounting gate- ways, as well as to shared secrets used by NAS devices, it is possible for a local ISP to submit inaccurate accounting records to the accounting agent. Such behavior will only be easily detectable in the event that roaming users are making use of voluntary or compulsory tunneling, in which case the tunnel server (presumed to exist at BIGCO) will generate its own accounting record, which may be compared to that generated by the local ISP. However, tunneling is expected to represent only a small percentage of roaming use. With respect to submission of inaccurate accounting records, it makes little difference whether the local ISP submits accounting records, or proxies accounting protocol packets to the accounting agent. Either accounting records or accounting protocol packets may be forged by the local ISP; for example, an accounting gateway could hold incoming RADIUS accounting packets and retransmit them later, making it appear that the session was longer than it actually was. Requiring the NAS to communicate directly with the accounting agent provides little extra security. Aside from the scalability problems that would result from this when a shared-secret authentication scheme is used, the local ISP has access to all the NAS shared secrets or private keys, and therefore has at its disposal all the information necessary to forge authentication and accounting packets. It should also be noted that this document does not provide a mecha- nism for resolving of disputes between BIGCO and the local ISP regard- ing the type of service provided. This is because we currently have not specified a mechanism by which the local ISP can determine whether BIGCO's Access-Accept has arrived without being modified by an inter- mediate proxy. As a result, it is possible that important security attributes (such as specification of compulsory tunneling or use of EAP) will be discarded by intermediate proxies. In this case, BIGCO's tunnel or EAP server logs will reflect the missing service attributes, and BIGCO may refuse to pay the local ISP for the services provided. Without support for non-repudiation in Access-Accepts, such disputes are not easily resolved. Aboba & Lidyard [Page 14] INTERNET-DRAFT 26 March 1997 9. Appendix - A Binary Accounting Format Proposal In order to stimulate working group discussion of the binary vs. ASCII accounting record format issue, a preliminary proposal for a binary accounting record format is included below. The proposed format offers backwards compatiblity with RADIUS attributes while offering an extended metric space, and providing for error messages as well as mandatory and optional attributes. 9.1. Attribute Value Pair format The Binary Accounting Format represents accounting records as a series of Attribute Value Pairs (AVPs), similar to those described in [20]. The AVP format is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M 0 0| Overall Length | Vendor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute | Value... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ M = Mandatory. This bit is used to provide an accounting agent with guidance as to how it should respond when encountering attributes that it does not understand. M = 0 indicates that the accounting agent may ignore the attribute. M = 1 indicates that the accounting agent not supporting this attribute must not process the record, and should return an error. 9.1.1. Length The length field, indicates the number of octets in the AVP, including the Flags, Length, Vendor ID, Attribute, and Value fields. Given that the length field is 13 bits long, AVPs may have a maximum length of 8192 octets. 9.1.2. Vendor ID Vendor ID is the IANA assigned "SMI Network Management Private Enter- prise Codes" value, encoded in network byte order. The value 0, reserved in this table, corresponds to IETF adopted attribute values, defined within this document. Vendors looking to implement EAF exten- sions can use their own Vendor ID along with private attribute values in order to guarantee that they will not collide with another vendor's extensions. Aboba & Lidyard [Page 15] INTERNET-DRAFT 26 March 1997 9.1.3. Attribute The attribute field, which is 16 bits in length, indicates the accounting metric encoded in the value field. 9.1.4. Value The value field encodes the value of the attribute indicate in the attribute field. 9.2. Attributes The IETF attribute space is subdivided into the following regions: Attributes Purpose ---------- ------- 0 - 255 RADIUS attributes 256 - 1023 Reserved In order to provide for the efficient operation of accounting gate- ways, the first 256 attributes in EAF are reserved for use by RADIUS attributes. Only RADIUS attributes described in [4], [5], and [9] are allowed to use Vendor ID 0. Vendor-specific attributes MUST NOT use the RADIUS Vendor-specific attribute along with EAF Vendor ID 0, but instead MUST set the vendor ID field appropriately. 9.2.1. Global attributes The following attributes refer not to the characteristics of a partic- ular accounting record, but to the entire set of records being pre- sented. These attributes MUST be included first in the accounting record stream, prior to the inclusion of any accounting records. The global attributes are separated from the accounting records by an End of Global Attributes AVP. 9.2.2. Timestamp 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0| 14 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1024 | NTP Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | / NTP Timestamp / Aboba & Lidyard [Page 16] INTERNET-DRAFT 26 March 1997 | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Timestamp AVP is a 64-bit NTP timestamp used to identify the time at which the packet was first sent. It is used as a unique identifier for the packet, so that if the transmission is aborted, a subsequent retransmission will use the same timestamp field. 9.2.3. Source 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0 0| >=7 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1025 | Source... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Source AVP is a string indicating the fully qualified domain name of the ISP from which the accounting data is being sent. This attribute MUST be included in every accounting record bundle. 9.2.4. Destination 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0 0| >=7 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1026 | Destination... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Destination AVP is a string indicating the fully qualified domain name of the accounting agent to whom the accounting data is being sent. This attribute MUST be included in every accounting record bundle. 9.2.5. Number of Records 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0| 12 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1027 | Number of records | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of records | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Aboba & Lidyard [Page 17] INTERNET-DRAFT 26 March 1997 The Number of Records AVP provides the number of records included in the accounting record bundle. This attribute is optional. 9.2.6. Error Reporting Email Address 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0| >=7 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1028 | Admin Email Address... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Error Reporting Email Address AVP provides the e-mail address to which error messages should be sent in the event of problems with the accounting record bundle. This attribute MUST be included in every accounting record bundle. 9.2.7. Administrative Contact 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0| >=7 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1029 | Admin Contact... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Administrative Contact AVP denotes the E-mail address, phone number, address, etc. of the person who should be contacted in the event of problems with the accounting record stream. This attribute MUST be included in every accounting record bundle. 9.2.8. Accounting Gateway FQDN 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0 0| >=7 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1030 | Accounting Gateway FQDN... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Accounting Gateway FQDN AVP provides the fully qualified domain name of the accounting gateway sending the accounting record bun- dle. This AVP is optional. Aboba & Lidyard [Page 18] INTERNET-DRAFT 26 March 1997 9.2.9. Accounting Gateway IP Address 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0 0| 12 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1031 | Accounting Gateway IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Accounting Gateway IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Accounting Gateway IP Address AVP provides the IP address of the accounting gateway sending the accounting record bundle. This AVP is optional. 9.2.10. Attribute List 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0| >=10 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1032 | Attributes... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Attribute List AVP is used to provide the accounting agent with a list of all the Vendor ID/attributes included in the accounting record bundle. This provides a quick way for the accounting agent to determine whether it is capable of processing the bundle. Use of the Attribute List AVP is optional. 9.2.11. End of Global Attributes 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0| 6 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2047 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The End of Global Attributes AVP is included in order to separate the global attributes from the accounting records. It MUST be included at the end of the global attributes. 9.2.12. Accounting record attributes The following attributes refer to the characteristics of a particular accounting record. Aboba & Lidyard [Page 19] INTERNET-DRAFT 26 March 1997 9.2.13. Accounting Record Separator 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0 0| 6 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2048 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Accounting Record Separator AVP is used to denote the end of an accounting record. This attribute MUST be included for every accounting record. 9.2.14. Roaming relationship path 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0 0| >=7 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2049 | Roaming Relationship path... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The roaming relationship path AVP is a string indicating the roam- ing relationship path by which the user was granted access to the network. This AVP MUST be included for roaming accounting records. 9.2.15. Time zone 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0 0| 9 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2050 | Time Zone | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time Zone | +-+-+-+-+-+-+-+-+ The Time Zone AVP is a string indicating the timezone abbreviation for the timestamps included in this accounting record. 9.2.16. Elapsed Time 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0 0| 10 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2051 | Elapsed Time | Aboba & Lidyard [Page 20] INTERNET-DRAFT 26 March 1997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Elapsed Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Elapsed Time AVP is binary value encoding the elapsed time in seconds for the accounting event. This can be ued when start and stop times are not available. 9.2.17. Reason 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0 0| >=7 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2052 | Reason... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Reason AVP is a string providing information on why the event occurred. 9.2.18. Pages 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0 0| 12 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2053 | Pages | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pages | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Pages AVP is a binary number indicating the number of pages of text associated with the event. 9.2.19. Bandwidth reserved 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0 0| 12 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2054 | Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Bandwidth reserved AVP is a binary number indicating the of bandwidth reserved during the event. Aboba & Lidyard [Page 21] INTERNET-DRAFT 26 March 1997 10. Acknowledgements Thanks to Glen Zorn of Microsoft for useful discussions of this prob- lem space. 11. References [1] B. Aboba, J. Lu, J. Alsop, J. Ding. "Review of Roaming Implemen- tations." draft-ietf-roamops-imprev-01.txt, Microsoft, Aimnet, i-Pass Alliance, Asiainfo, January, 1997. [2] B. Aboba, G. Zorn. "Dialing Roaming Requirements." draft-ietf- roamops-roamreq-02.txt, Microsoft, January, 1997. [3] C. Rigney, A. Rubens, W. Simpson, S. Willens. "Remote Authenti- cation Dial In User Service (RADIUS)." RFC 2058, Livingston, Merit, Daydreamer, January, 1997. [4] C. Rigney. "RADIUS Accounting." RFC 2059, Livingston, January, 1997. [5] J. Gray, A. Reuter. Transaction Processing: Concepts and Tech- niques, Morgan Kaufmann Publishers, San Francisco, California, 1993. [6] R. Fajman. "An Extensible Message Format for Message Disposition Notifications." draft-ietf-receipt-mdn-02.txt, National Institute of Health, November, 1996. [7] M. Elkins. "MIME Security with Pretty Good Privacy (PGP)." RFC 2015, The Aerospace Corporation, October, 1996. [8] G. Vaudreuil. "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages." RFC 1892, Octel Network Ser- vices, January, 1996. [9] J. Galvin., et al. "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted." RFC 1847, Trusted Information Systems, Octo- ber, 1995. [10] D. Crocker. "MIME Encapsulation of EDI Objects." RFC 1767, Bran- denburg Consulting, March, 1995. [11] M. Jansson, C. Shih, N. Turaj, R. Drummond. "MIME-based Secure EDI." draft-ietf-ediint-as1-02.txt, LiNK, Actra, Mitre Corp, Drummond Group, November, 1996. [12] C. Shih, M. Jansson, R. Drummond, L. Yarbrough. "Requirements for Inter-operable Internet EDI." draft-ietf-ediint-req-01.txt, Actra, LiNK, Drummond Group, May, 1995. [13] R. Fielding, et al. "Hypertext Transfer Protocol - HTTP/1.1." draft-ietf-http-v11-spec-07, UC Irvine, August, 1996. Aboba & Lidyard [Page 22] INTERNET-DRAFT 26 March 1997 [14] A. Gulbrandsen, P. Vixie. "A DNS RR for specifying the location of services (DNS SRV)." RFC 2052, Troll Technologies, Vixie Enter- prises, October 1996. [15] D. Eastlake, 3rd, C. W. Kaufman. "Domain Name System Security Extensions." Draft-ietf-dnnsec-secext-10.txt, CyberCash, Iris, August, 1996. [16] B. Aboba. "The Roaming Relationships (REL) Resource Record in the DNS. " draft-ietf-roamops-dnsrr-03.txt, Microsoft, March, 1997. [17] C. Rigney, W. Willats. "RADIUS Extensions." draft-ietf-radius- ext-00.txt, Livingston, January, 1997. [18] R. Rivest, S. Dusse. "The MD5 Message-Digest Algorithm", RFC 1321, MIT Laboratory for Computer Science, RSA Data Security Inc., April 1992. [19] S. Bradner. "Key words for use in RFCs to Indicate Requirement Levels." draft-bradner-key-words-02.txt, Harvard University, August, 1996. [20] K. Hamzeh, T. Kolar, M. Littlewood, G. S. Pall, J. Taarud, A. J. Valencia, W. Verthein. "Layer Two Tunneling Protocol -- L2TP." draft- ietf-pppext-l2tp-01.txt, Ascend Communications, December, 1996. 12. Authors' Addresses Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: 206-936-6605 EMail: bernarda@microsoft.com Dave Lidyard Telco Research Corporation 616 Marriott Drive Nashville, TN 37214 Phone: 615-231-6110 EMail: dave@telcores.com Aboba & Lidyard [Page 23]