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-01.txt < prev next >

Wrap

Text File | 1997-03-06 | 61KB | 1,450 lines

ROAMOPS Working Group Bernard Aboba INTERNET-DRAFT Microsoft Corporation <draft-ietf-roamops-actng-01.txt > 6 March 1997 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 <draft- ietf-roamops-actng-01.txt>, and expires September 15, 1997. Please send comments to the authors. 2. Abstract This document describes the accounting problems that arise in the pro- vision of inter-provider services, such as provision of 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 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. Aboba [Page 1] INTERNET-DRAFT 6 March 1997 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 users from outside the local ISP's domain. 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. 3.2. Roaming accounting requirements Given the growth of the Internet, it is likely that authentication and accounting servers involved in roaming will need to handle a large flow of events. For example, if a roaming association has 10 members, each of whom have 100,000 users, and 5 percent of all logins involve roaming, then if the users log in 20 times a month on average, each accounting server will need to handle approximately 2 million records/month and the accounting agent will need to handle 1 million records/month. For this reason, it is very important that the accounting record formats be compact and that the accounting transfer processes be efficient. Aboba [Page 2] INTERNET-DRAFT 6 March 1997 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. In order to address security concerns, it is desirable for an inter-organizational accounting transfer protocol to support "full service" functions such as 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. Since intra-organizational accounting events do not cross organiza- tional boundaries, "full service" accounting transfer features such as digital signing of accounting bundles and non-repudiation of receipt typically are not required, although it is highly desirable that both inter and intra-organizational accounting transfers exhibit the char- acteristics of high reliability transaction processing systems, such as atomicity, consistency, isolation and durability (ACID), as described in [5]. 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. It is desirable that accounting record formats be flexible. While the standard accounting record format must be able to encode metrics com- monly 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. 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. In this architecture, local ISPs operating accounting gateways in order to translate between the accounting protocols used by NAS devices and routers and the roaming standard accounting record format and transfer method. Local ISP accounting gateways are also responsi- ble for summarizing checkpoint events into session records, as well as routing accounting events. Accounting events originating on a local ISP fall into two categories: intra-organizational accounting events, which are events generated by local customers; and inter-organizational accounting events, which are Aboba [Page 3] INTERNET-DRAFT 6 March 1997 events generated by customers from other domains. 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 elminates translations that would oth- erwise 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, in addition to sending copies to the home ISP. Copies are pro- vided in order to enable the home ISP to audit accounting agent charges, as well to bill back to the originating domain. 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. | Aboba [Page 4] INTERNET-DRAFT 6 March 1997 | | | 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 | | | V +------------+ | | | | | Fred | | | | | +------------+ Aboba [Page 5] INTERNET-DRAFT 6 March 1997 5. 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], since both applications may transmit encrypted and signed entities, and request and receive 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 "full service" accounting record transfers. Since Secure MIME-enabled mail servers are expected to become widely available in the next year, use of this technology will enable a "full service" accounting transfer method to be made available in relatively short order. Since it is likely that this technology will become available sooner than it would be possible for the ROAMOPS group to develop a secure accounting transfer method based on alternative secu- rity techniques (such as shared secrets), it is recommended that the group focus on use of Secure MIME as an accounting record transfer mechanism. 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 MIME-based secure EDI is used to transfer accounting record bun- dles between organizations, it is recommended that the bundles be encrypted as well as signed, and that a signed receipt be requested. Either S/MIME or PGP/MIME may be used to accomplish this. 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 messages need only be sent between entities with a pre-existing business relation- ship. As a result, it is possible to statically configure accounting gateways with the required public keys. With MIME-based secure EDI, the accounting records are transferred using S/MIME or PGP/MIME over SMTP. Since SMTP server technology is mature, it is believed that this method can satisfy durability as well as security requirements. Aboba [Page 6] INTERNET-DRAFT 6 March 1997 5.1. 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, debits ISPA account, credits ISPB account ISPA: Accounting gateway routes the session record to the local billing server and to BIGCO ISPA: Billing server processes the session record, debits BIGCO account, debits ISPGROUP account BIGCO: Accounting gateway routes the session record to the local billing server BIGCO: Billing server processes the session record, debits Fred's account, debits ISPA account. Each of these events is discussed below. 5.2. 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 [Page 7] INTERNET-DRAFT 6 March 1997 5.3. 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. 5.4. 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 [Page 8] INTERNET-DRAFT 6 March 1997 5.5. 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. 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. 5.6. 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. 5.7. ISPGROUP accounting server processes the session record, debits ISPA account, credits ISPB account ISPGROUP's accounting server processes the session record, and as a result, ISPA's account is debited, and ISPB's account is credited. 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 bundle from its mailbox and process it, sending a receipt in response to the account- ing gateway's request. 5.8. 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. 5.9. ISPA billing server processes the session record, debits BIGCO account, debits ISPGROUP account ISPA's billing server processes the session record, and as a result, BIGCO's account is debited, and ISPGROUP's account is also debited. Aboba [Page 9] INTERNET-DRAFT 6 March 1997 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 accounting gateway's request. 5.10. 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. 5.11. BIGCO billing server processes the session record, debits Fred's account, debits ISPA account BIGCO's billing server processes the session record, and as a result, Fred's account is debited, as is ISPA's account. 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 gateway's request. 6. Location of the accounting agent In order to be able to upload an accounting record bundle to a accounting agent, it will typically be necessary for a relationship to exist between the local ISP and the accounting agent. As a result, it is expected that the ISP's accounting gateway will be statically con- figured 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 Aboba [Page 10] INTERNET-DRAFT 6 March 1997 record bundles to include the name of the accounting agent to whom the records are to be submitted. Where a DNS Roaming Relationship record is used, the accounting gate- way 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 filled in as DNS Roaming Relationship records are received. Ordinarily a Roaming Relationship resource record is kept in the cache until it times out. This implies that the cache will typically remain constant between the time that the authentication is processed and when the accounting records are generated. 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 Roaming Relationship record 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. 7. Accounting record formats 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 In the future it is likely that new accounting metrics will arise, or existing metrics will fall by the wayside. There- fore it is important that the accounting record format be extensible. In particular, it is highly desirable for ven- dors to be able to generate their own metrics without fear of colliding with each other. 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. 7.1. 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, Aboba [Page 11] INTERNET-DRAFT 6 March 1997 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.2. Example accounting metrics Examples of accounting metrics include: User Name (String; the user's ID, including prefix or suffix) NAS IP address (Integer; the IP address of the user's NAS) NAS Port (Integer; identifies the physical port on the NAS) Service Type (Integer; identifies the service provided to the user) NAS Identifier (Integer; unique identifier for the NAS) Delay Time (Integer; time client has been trying to send) Input Octets (Integer; in stop record, octets received from port) Output Octets (Integer; in stop record, octets sent to port) Session ID (Integer; unique ID identifying the session) Authentication (Integer; indicates how user was authenticated) Session Time (Integer; in stop record, seconds of received service) Aboba [Page 12] INTERNET-DRAFT 6 March 1997 Input Packets (Integer; in stop record, packets received from port) Output Packets (Integer; in stop record, packets sent to port) Termination Cause (Integer; in stop record, indicates termination cause) Multi-Session ID (String; for linking of multiple related sessions) Link Count (Integer; number of links up when record was generated) NAS Port Type (Integer; indicates async vs. sync ISDN, V.120, etc.) 7.3. Binary accounting format proposal 7.3.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. 7.3.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. 7.3.1.2. Vendor ID Vendor ID is the IANA assigned "SMI Network Management Private Enter- prise Codes" value, encoded in entwork 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 Aboba [Page 13] INTERNET-DRAFT 6 March 1997 extensions. 7.3.1.3. Attribute The attribute field, which is 16 bits in length, indicates the accounting metric encoded in the value field. 7.3.1.4. Value The value field encodes the value of the attribute indicate in the attribute field. 7.4. 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. 7.4.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. 7.4.1.1. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Aboba [Page 14] INTERNET-DRAFT 6 March 1997 | | | | / NTP Timestamp / | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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. 7.4.1.2. 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. 7.4.1.3. 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. 7.4.1.4. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Aboba [Page 15] INTERNET-DRAFT 6 March 1997 | Number of records | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Number of Records AVP provides the number of records included in the accounting record bundle. This attribute is optional. 7.4.1.5. 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. 7.4.1.6. 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. 7.4.1.7. 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 [Page 16] INTERNET-DRAFT 6 March 1997 7.4.1.8. 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. 7.4.1.9. 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. 7.4.1.10. 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. 7.4.2. Accounting record attributes The following attributes refer to the characteristics of a particular accounting record. Aboba [Page 17] INTERNET-DRAFT 6 March 1997 7.4.2.1. 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. 7.4.2.2. 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. 7.4.2.3. 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. 7.4.2.4. 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 [Page 18] INTERNET-DRAFT 6 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. 7.4.2.5. 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. 7.4.2.6. 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. 7.4.2.7. 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 [Page 19] INTERNET-DRAFT 6 March 1997 8. Security considerations In a pure RADIUS proxy-based scheme without access to public key authentication it is not possible to sign accounting record bundles or request signed receipts. As a result, without public key authentica- tion it is not possible to verify the origin of an accounting record bundle, or to prove that an accounting record bundle was received. Nevertheless, it is possible to request receipts and provide for non- signed receipts, and to provide some degree of protection for account- ing transfers via use of shared-secret authentication. However, even with public key authentication technology, roaming accounting remains vulnerable to fraud on the part of local ISPs. Since the local ISP must have access to any private keys used for signing by accounting gateways, it is possible for the local ISP to submit inaccurate accounting records to the accounting agent. All pub- lic key technology provides is the ability to verify the origin of those fraudulent accounting records. In this respect, it makes little difference whether the local ISP sub- mits 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 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, since the local ISP has access to all the NAS shared secrets or private keys, it has at its disposal all the information necessary to forge authentication and accounting packets. Note that an authentication proxy run by the accounting agent is not on the authentication route path, then the accounting agent will not be able to match a session record submitted for payment with a proxied authentication. When used in concert with public key authentication and a token-based scheme, such matching can protect against fictitious sessions created by the local ISP. As a result, accounting agents may require that all authentications pass through their proxies as the first hop, even where the authentication could be handled directly between the local ISP proxy and the home authentication server. Without public key authentication, this matching process does not pro- tect against fictitious sessions created by the local ISP, although it does require the local ISP to forge both the authentication and the subsequent accounting record. Aboba [Page 20] INTERNET-DRAFT 6 March 1997 9. Acknowledgements Thanks to Glen Zorn of Microsoft for useful discussions of this prob- lem space. 10. 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 [Page 21] INTERNET-DRAFT 6 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-02.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. 11. Authors' Addresses Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: 206-936-6605 EMail: bernarda@microsoft.com Aboba [Page 22]