Internet Info 1997 December

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_q_t / draft-ietf-roamops-actng-03.txt < prev next >

Wrap

Text File | 1997-08-26 | 53KB | 1,251 lines

ROAMOPS Working Group Bernard Aboba INTERNET-DRAFT Microsoft Corporation Category: Standards Track Dave Lidyard <draft-ietf-roamops-actng-03.txt> Telco Research Corporation 28 July 1997 John R. Vollbrecht Merit Network, Inc. Session Record Accounting 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 <draft- ietf-roamops-actng-03.txt>, and expires February 1, 1998. Please send comments to the authors. 2. Abstract This document describes the problems arising in session record accounting in roaming systems, and proposes a standard accounting record format. 3. Introduction As detailed in [2], solution of the accounting problem in roaming requires several elements to be put in place: 1. Mechanisms for real-time accounting should be provided in order to support those ISPs who use these mechanisms for simultaneous session control, fraud detection, and risk management. 2. A standardized accounting record format must be provided in order to allow ISPs to communicate session accounting information to the roaming consortia as well as to each other. Mechanisms for real-time accounting are addressed in [24]. This Aboba, Lidyard & Vollbrecht [Page 1] INTERNET-DRAFT 28 July 1997 document concentrates on issues relating to session record 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. Interim accounting An interim accounting packet provides a snapshot of usage during a user's session. It is typically implemented in order to provide for partial accounting of a user's session in the event of a NAS reboot or other network problem that prevents the reception of a session summary packet or ses- sion record. 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 interim accounting events. Accounting Protocol A protocol used for the communication of accounting events. Intra-organizational accounting event An intra-organizational accounting event is one which is generated by the local ISP's customers. Inter-organizational accounting event An inter-organizational accounting event is one which is generated by customers of other ISPs. Accounting Gateway The accounting gateway is a server which receives accounting protocol packets from network devices such as a NASes and routers and produces session records. In the case where accounting packets describe an intra-organizational account- ing event, accounting gateways handle the transmission of accounting data to other accounting gateways or billing servers. In the case where accounting data describes an inter-organizational accounting event, accounting gateways transmit session records to the organizational billing server. Accounting Gateways providing real-time accounting services proxy inter-organizational accounting packets to other accounting gateways. Accounting gateways providing Aboba, Lidyard & Vollbrecht [Page 2] INTERNET-DRAFT 28 July 1997 session record accounting services transmit inter-organiza- tional session records to other accounting gateways. Billing Server The Billing Server is a server which receives accounting data from accounting gateways, and translates this informa- tion into bills. Accounting Agent 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 possible for ISPs to settle among themselves. 4. Overview The goal of accounting in roaming is to enable ISPs to be compensated for use of their network infrastructure by roaming users, as well as to control fraud and audit usage. The roaming accounting architecture supports both real-time account- ing, and session record accounting. It is expected that real-time and session record accounting will be simultaneously deployed in some roaming implementations, and therefore these accounting methods are not mutually exclusive. Real-time accounting is a practical necessity in many roaming systems, since it provides for simultaneous session control and real-time moni- toring of funds balances, allowing roaming consortia participants to better manage risk. The real-time accounting architecture requires use of the RADIUS accounting protocol, described in [4]. As described in [24], when real-time accounting is used, RADIUS accounting packets are proxied between the local ISP's NAS and the home RADIUS accounting server, on the same path as RADIUS authentication packets. This path is known as the roaming relationship path. However, real-time accounting does not satisfy all accounting require- ments in roaming systems. Currently, there is no standards-track accounting protocol. In situations where ISPs within a roaming consor- tium do not support RADIUS, it may be desirable to exchange accounting information via use of a standard accounting record format. Due to the limitations of RADIUS accounting, real-time accounting cannot provide end-to-end security. As a result, it may be desirable to deploy a ses- sion-record accounting mechanism in concert with a secure accounting record transfer method so as to provide end-to-end security for accounting information. When session record accounting is used, session records are submitted by the local ISP to the accounting agent, and subsequently copied to the other entities on the roaming relationship path, typically being transferred in batches. This reduces the overhead of providing improved security, making it possible to digitally sign accounting record bundles, and transmit them in encrypted form. The subject of Aboba, Lidyard & Vollbrecht [Page 3] INTERNET-DRAFT 28 July 1997 signed and encrypted transfers, while outside the scope of this docu- ment, is addressed in references [6]-[12]. 4.1. Session record accounting The session record accounting architecture involves interactions between network devices such as NASes and routers, accounting gate- ways, billing servers, and accounting servers. Accounting data received by the accounting gateway fall into two cate- gories: intra-organizational accounting events, which are events gen- erated 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 appro- priately. 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 accounting gateways operating at other organizations. While it is not required that session record formats used in inter and intra-organiza- tional accounting transfers be the same, this is highly desirable, since this eliminates translations that would otherwise be required. When the accounting agent's accounting gateway receives inter-organi- zational events from a local ISP's accounting gateway, it routes the events to the billing 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 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. The purpose of a billing server is to provide billing and auditing services. In order to provide this services, billing servers import session records provided to them by the accounting gateway. In order to provide accounting capabilities, accounting gateways must support session record accounting and may support real-time account- ing. Accounting gateways supporting real-time accounting must support the RADIUS accounting protocol, described in [4]. Accounting gateways supporting session record accounting must send and receive accounting records in a standardized format, described in this document. Required support for session record accounting allows ISPs not using RADIUS accounting to participate in roaming. Today there is no accounting protocol on the standards track, and as a result, a variety of accounting protocols have been deployed, including SNMP, TACACS+, RADIUS, and SYSLOG. Aboba, Lidyard & Vollbrecht [Page 4] INTERNET-DRAFT 28 July 1997 The diagram below illustrates the architecture for session-record accounting: +------------+ +------------+ +------------+ | | | | | | | 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 | | Billing | | | | Server | | Server | | | | | | | +------------+ +------------+ +------------+ ^ PPP | Protocol | | V +------------+ | | | Fred | | | +------------+ Aboba, Lidyard & Vollbrecht [Page 5] INTERNET-DRAFT 28 July 1997 4.2. Example 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. 4.3. 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 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. Aboba, Lidyard & Vollbrecht [Page 6] INTERNET-DRAFT 28 July 1997 4.4. 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. 4.5. 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. 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. Aboba, Lidyard & Vollbrecht [Page 7] INTERNET-DRAFT 28 July 1997 4.6. 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 ISPGROU 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. 4.7. 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. 4.8. ISPGROUP accounting server processes the session record, credits 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. 4.9. 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 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. 4.10. 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 Aboba, Lidyard & Vollbrecht [Page 8] INTERNET-DRAFT 28 July 1997 accounting gateway's request. 4.11. 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. 4.12. 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. 4.13. Accounting transfer protocols In order for session records to be transmitted between accounting gateways, a transfer protocol is required. While the discussion of transfer protocols is outside the scope of this document, roaming con- sortia concerned about securing the transport of accounting data are advised to consult the documents under development within the EDIINT Working Group. As described in [12], Internet Electronic Document Interchange (EDI) provides for 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]. 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. 4.14. 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 Aboba, Lidyard & Vollbrecht [Page 9] INTERNET-DRAFT 28 July 1997 accounting 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. 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 Aboba, Lidyard & Vollbrecht [Page 10] INTERNET-DRAFT 28 July 1997 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 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..NH 2 4.15. 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: 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. 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. Traditionally, session records have used fixed record formats, which while being compact, have limited extensibility. In this application, the accounting data to be exchanged may be interim accounting information or session records; it may represent standard metrics or vendor-specific information; it may need to express attributes of arbitrary size; it may be called upon to rep- resent data from any of the commonly used accounting proto- cols including RADIUS, TACACS+, SNMP or SYSLOG. 4.16. Definition of the Accounting Data Interchange Format (ADIF) ADIF, which is similar to the LDAP Data Interchange Format (LDIF) specified in [23], is extensible as well as compact. While ADIF is Aboba, Lidyard & Vollbrecht [Page 11] INTERNET-DRAFT 28 July 1997 capable of expressing a wide variety of accounting data, most appli- cations are expected to use only a small subset of capabilities. Therefore, prior to exchanging accounting data, it is expected that ISPs will consult with the accounting agent so as to understand which metrics are required in a given situation. For example, an accounting agent may require a small set of RADIUS attributes, with all other attributes ignored. In this case, participating ISPs will need to pro- vide ADIF records with these required attributes in order to have their accounting data processed correctly. Since the decision on required versus optional accounting data is typ- ically made by the accounting agent rather than the submitting ISP, ADIF does not provide the ability to mark accounting data as "manda- tory", as is done in L2TP, described in [19]. It is felt that provid- ing this capability would result in increased complexity without adding much in the way of error detection. However, requirements from a given accounting protocol do carry over to ADIF. For example, in RADIUS accounting as described in [4] it is required that a RADIUS Accounting-Request contain an Acct-Status-Type attribute, and these same requirements would apply to an ADIF accounting record expressing information obtained from RADIUS accounting packets. Accounting records have traditionally been human-readable, so as to allow them to be more easily debugged. ADIF permits attributes to be expressed either in NVT ASCII (characters 32 through 126) or if non- printable characters are required, in base64. An ADIF file consists of a series of records separated by a separator, and each record may consist of one or more lines. As with MIME, described in [20], lines may be continued by putting a space or tab character on the succeeding line, and thus attributes may be of arbi- trary length. A version number (1 for this document), and a default attribute type may be optionally included at the beginning of the ADIF file. Lines beginning with the "#" character are taken as comments and ignored. In order to allow ADIF to be used to communicate accounting data from a variety of sources, ADIF includes support for attribute types. This specification includes support for RADIUS, SNMP, and TACACS+ attributes, and other types may be added as needed. Attribute types may be indicated by prepending the attribute type, and a "//" to the attribute name, i.e. RADIUS//Acct-Session-Time. In order to provide the maximum degree of compactness, ADIF permits attribute numbers to be used instead of names. For example, RADIUS//46: may be used instead of RADIUS//Acct-Session-Time. Since it is expected that most accounting record batches will use attributes of a single type, a default attribute type may be indicated at the beginning of an ADIF file. When a default attribute type is used, attributes of the default type do not need to include their type along with the attribute name. For example, if defaultType: RADIUS is indicated at the beginning of the ADIF file, then Acct-Session-Time: or 46: may be used instead of RADIUS//Acct-Session-Time: or Aboba, Lidyard & Vollbrecht [Page 12] INTERNET-DRAFT 28 July 1997 RADIUS//46:. 4.16.1. Vendor-specific attributes ADIF supports vendor-specific metrics in several ways. It is possible for a vendor to define their own attribute type (i.e. BIGCO//). How- ever, this should only be done in cases where there are limited inter- operability requirements. In most cases, vendor-specific attributes can be accommodated within existing attribute types, such as RADIUS or SNMP, through the encoding of vendor-specific attributes. In RADIUS, this is typically accom- plished using the Vendor-Specific attribute; in SNMP it is accom- plished by definition of a MIB variable within the vendor area. In both RADIUS and SNMP, vendors are identified using the SMI Network Management Private Enterprise Code, as given in [22]. In the case of RADIUS as described in [3], servers not equipped to support vendor- specific attributes MUST ignore them. Since vendor-specific attributes may be expressed in a variety of for- mats, it is not possible to specify how they are to be represented in general. However, in order to make vendor-specific attributes easier to debug, it is recommended that RADIUS Vendor-Specific attributes be encoded so as to break out the Vendor-Id and Vendor-Type from the attribute-specific data. This may be accomplished by using a semi- colon as a separator, as follows: Vendor-Specific: Vendor-Id: <SMI Network Management Private Enterprise Code>; <Type>: <Value> 4.16.2. ADIF Examples Example 1: An ADIF file encoding RADIUS accounting data, using attribute names: version: 1 defaultType: RADIUS NAS-IP-Address: 204.45.34.12 NAS-Port: 12 NAS-Port-Type: 2 User-Name: fred@bigco.com Acct-Status-Type: 2 Acct-Delay-Time: 2 Acct-Input-Octets: 234732 Acct-Output-Octets: 15439 Acct-Session-Id: 185 Acct-Authentic: 1 Acct-Session-Time: 1238 Acct-Input-Packets: 153 Acct-Output-Packets: 148 Acct-Terminate-Cause: 11 Aboba, Lidyard & Vollbrecht [Page 13] INTERNET-DRAFT 28 July 1997 Acct-Multi-Session-Id: 73 Acct-Link-Count: 2 Example 2: An ADIF file encoding RADIUS accounting data, using attribute numbers: version: 1 defaultType: RADIUS 4: 204.45.34.12 5: 12 61: 2 1: fred@bigco.com 40: 2 41: 2 42: 234732 43: 15439 44: 185 45: 1 46: 1238 47: 153 48: 148 49: 11 50: 73 51: 2 Example 3: An ADIF file with vendor-specific data: version: 1 defaultType: RADIUS 4: 204.45.34.12 5: 12 61: 2 26: Vendor-Id: 311; dialClass: 1 1: fred@bigco.com 40: 2 41: 2 42: 234732 43: 15439 44: 185 45: 1 46: 1238 47: 153 48: 148 49: 11 50: 73 51: 2 Aboba, Lidyard & Vollbrecht [Page 14] INTERNET-DRAFT 28 July 1997 4.16.3. Grammar The following definition uses the augmented Backus-Naur Form specified in [13]. adif-file = [version-spec SEP] [type-spec SEP] adif-record *(SEP adif-record) version-spec = "version:" *SPACE version-number version-number = 1*DIGIT type-spec = "defaultType:" *SPACE attr-type attr-type = "RADIUS" | "SNMP" | "TACACS+" adif-record = 1*(attrval-series SEP) attrval-series = 1*(attrval-spec) attrval-spec = attr ( (":" *SPACE value) | ("::" *SPACE base64-value) ) attr = radattr | snmpattr | tacacsplusattr radattr = ["RADIUS//"] radattrname radattrname = <a RADIUS attribute name, as defined in [3],[4],[7]> | <a RADIUS attribute number, as defined in [3],[4],[7]> snmpattr = ["SNMP//"] snmpattrname snmpattrname = <an SNMP object ID> | <an SNMP attribute name> tacacsplusattr = ["TACACS+//"] tacacsplusattrname tacacsplusattrname = <a TACACS+ attribute name, as defined in [11]> value = 1*safe-initval *safe safe = <ASCII values 040 - 0176 octal (32 - 126 decimal) safe-initval = <ASCII values 040 - 0176 octal (32 - 126 decimal), excluding colon (":", ASCII 58 decimal), SPACE, and semi-colon (";", ASCII 59 decimal) base64-value = <base-64-encoded value, defined in [10]> SPACE = <ASCII SP, space> SEP = (CR LF) | LF CR = <ASCII CR, carriage return> LF = <ASCII LF, line feed> DIGIT = <any ASCII decimal digit (60 - 71 decimal) > 5. Security issues When session record accounting is employed, protection must be pro- vided against the following attacks: Theft of accounting data Submission of fraudulent accounting records 5.1. Theft of accounting data Since RADIUS accounting does not provide for encryption of accounting data, when real-time accounting is used, it is possible for an inter- mediate system to gain access to accounting information passing over the wire. Such access may or may not be possible when session record accounting is used, depending on whether encryption is used in the accounting record transfer. Aboba, Lidyard & Vollbrecht [Page 15] INTERNET-DRAFT 28 July 1997 5.2. Submission of fraudulent accounting records When session record accounting is used, it is possible for a local ISP to submit a fraudulent accounting record to the accounting agent. This includes submission of records for non-existent sessions, or submis- sion of exaggerated session times for actual sessions. 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. In order to detect changes in behavior by the local ISP, where real- time accounting is used the accounting agent SHOULD carefully monitor the balance of each local ISP so as to ensure that it remains within normal limits. Where hierarchical authentication 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 provides for a limited degree of auditing. To enable the matching of authentication and accounting packets, the Class attribute SHOULD be included in the RADIUS Access-Reply. 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. 6. Acknowledgements Thanks to Pat Calhoun of 3Com for useful discussions of this problem space. Aboba, Lidyard & Vollbrecht [Page 16] INTERNET-DRAFT 28 July 1997 7. References [1] B. Aboba, J. Lu, J. Alsop, J. Ding, W. Wang. "Review of Roaming Implementations." Internet draft (work in progress), draft-ietf- roamops-imprev-04.txt, Microsoft, Aimnet, i-Pass Alliance, Asiainfo, Merit Network, June, 1997. [2] B. Aboba, G. Zorn. "Dialup Roaming Requirements." Internet draft (work in progress), draft-ietf-roamops-roamreq-05.txt, Microsoft, June, 1997. [3] C. Rigney, A. Rubens, W. Simpson, S. Willens. "Remote Authenti- cation Dial In User Service (RADIUS)." RFC 2138, Livingston, Merit, Daydreamer, April, 1997. [4] C. Rigney. "RADIUS Accounting." RFC 2139, Livingston, April, 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." Internet draft (work in progress), 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: Multi- part/Signed and Multipart/Encrypted." RFC 1847, Trusted Information Systems, October, 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." Internet draft (work in progress), 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." Internet draft (work in progress), draft-ietf-ediint-req-01.txt, Actra, LiNK, Drummond Group, May, 1995. [13] R. Fielding, et al. "Hypertext Transfer Protocol - HTTP/1.1." RFC 2068, UC Irvine, January, 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. Aboba, Lidyard & Vollbrecht [Page 17] INTERNET-DRAFT 28 July 1997 [15] D. Eastlake, 3rd, C. W. Kaufman. "Domain Name System Security Extensions." Internet draft (work in progress), draft-ietf-dnnsec- secext-10.txt, CyberCash, Iris, August, 1996. [16] C. Rigney, W. Willats. "RADIUS Extensions." Internet draft (work in progress), draft-ietf-radius-ext-00.txt, Livingston, January, 1997. [17] R. Rivest, S. Dusse. "The MD5 Message-Digest Algorithm", RFC 1321, MIT Laboratory for Computer Science, RSA Data Security Inc., April 1992. [18] S. Bradner. "Key words for use in RFCs to Indicate Requirement Levels." RFC 2119, Harvard University, March, 1997. [19] K. Hamzeh, T. Kolar, M. Littlewood, G. S. Pall, J. Taarud, A. J. Valencia, W. Verthein. "Layer Two Tunneling Protocol -- L2TP." Work in progress, Internet draft (work in progress), draft-ietf- pppext-l2tp-03.txt, Ascend Communications, Microsoft, Copper Moun- tain Networks, U.S. Robotics, March, 1997. [20] Borenstein, N., Freed, N. "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft, December 1993. [21] D. Carrel, L. Grant. "The TACACS+ Protocol Version 1.75." Work in progress, draft-grant-tacacs-00.txt, Cisco Systems, October, 1996. [22] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340, USC/Information Sciences Institute, July 1992. [23] G. Good. "The LDAP Data Interchange Format (LDIF)." Internet draft (work in progress), draft-ietf-asid-ldif-00.txt, Netscape, November, 1996. [24] B. Aboba, J.R. Vollbrecht, and G. Zorn. "Guidelines for the Secure Operation of RADIUS Proxies in Roaming." Internet draft (work in progress), draft-ietf-roamops-auth-02.txt, Microsoft, Merit, July, 1997. 8. Authors' Addresses Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: 425-936-6605 EMail: bernarda@microsoft.com Dave Lidyard Telco Research Corporation 616 Marriott Drive Aboba, Lidyard & Vollbrecht [Page 18] INTERNET-DRAFT 28 July 1997 Nashville, TN 37214 Phone: 615-231-6110 EMail: dave@telcores.com John R. Vollbrecht Merit Network, Inc. 4251 Plymouth Rd. Ann Arbor, MI 48105-2785 Phone: 313-763-1206 EMail: jrv@merit.edu Aboba, Lidyard & Vollbrecht [Page 19]