ROAMOPS Working Group Bernard Aboba INTERNET-DRAFT Microsoft Corporation Category: Standards Track Dave Lidyard Telco Research Corporation 17 November 1998 The Accounting Data Interchange Format (ADIF) 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 ftp.ietf.org (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 June 1, 1999. Please send comments to the authors. 2. Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. 3. Abstract This document proposes a standard accounting record format, the Accounting Data Interchange Format (ADIF), which is designed to com- pactly represent accounting data in a protocol-independent manner. As a result, ADIF may be used to represent accounting data from any pro- tocol using attribute value pairs (AVPs) or variable bindings. 4. Introduction As detailed in [2], solution of the accounting problem in roaming requires a standardized accounting record format. Since there is no standards-track accounting protocol, the operational roaming services described in [1] exhibit considerable diversity in their accounting Aboba & Lidyard Standards Track [Page 1] INTERNET-DRAFT The Accounting Data Interchange Format17 November 1998 implementations. In order to be able to cope with this diversity, it is desirable that a standardized accounting record format be protocol-independent. As a result, protocol-specific solutions such as the SNMP-oriented record format described in [10] do not offer sufficient flexibility. This document proposes a standard accounting record format, resembling the LDAP Data Interchange Format (LDIF), described in [7]. ADIF may be used to represent accounting data from any protocol using attribute value pairs (AVPs) or variable bindings. 4.1. Terminology This document uses the following terms: Accounting The act of collecting information on resource usage for the purpose of trend analysis, auditing, billing, or cost allo- cation. Interim accounting Interim accounting processes provide a snapshot ofresource consumption. This is typically implemented so as to provide for partial accounting in the event of a device reboot, accounting server failure or network problem. Session record A session record represents a summary of resource consump- tion. In the event that that a session summary is not received, accounting gateways may need to reconstruct the session record by processing interim accounting events. Accounting Protocol A protocol used to convey information collected for account- ing purposes. 4.2. Requirements language In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [5]. 5. Definition of the Accounting Data Interchange Format (ADIF) ADIF is based on MIME, described in [11], and resembles the LDAP Data Interchange Format (LDIF) specified in [7]. An ADIF file consists of a header providing basic information about the records in the file, followed by a series of records separated by a separator. The header includes the version number (1 for this document), device name/description, and collection start date and time. A default Aboba & Lidyard Standards Track [Page 2] INTERNET-DRAFT The Accounting Data Interchange Format17 November 1998 protocol type may be optionally included in the header. Each record may consist of one or more lines, and as with MIME, described in [11], lines may be continued by putting a space or tab character on the succeeding line, allowing attributes to be of arbi- trary length. Lines beginning with the "#" character are taken as comments and ignored. Accounting records have traditionally been human-readable, so as to allow them to be more easily debugged. ADIF attributes can be expressed either in NVT ASCII (characters 32 through 126) or if non- printable characters are required, in base64. ADIF includes support for encoding of attributes for any protocol uti- lizing attribute value pairs or variable bindings. This includes RADIUS, defined in [3] and [4], SNMP, L2TP, defined in [8], and TACACS+, defined in [9]. The protocol type is indicated by prepending the protocol keyword as defined by IANA and a "//" to the attribute number, i.e. radius//46. To improve compactness, when a default protocol is indicated in the header, attributes of the default protocol do not need to include the protocol type. For example, if defaultProtocol: radius is indicated in the ADIF header, then 46 may be used instead of radius//46. Protocols such as L2TP, defined in [8] include additional fields such as Vendor ID and flags in their AVPs. To encode such AVPs, ADIF includes support for sub-attributes. These are included as additional fields, separated by a semi-colon, and are of the form = . For example, the L2TP version number attribute (attribute 2) with the Mandatory bit set would be expressed as "l2tp//2: 1; M=1". This document includes support for VendorId, VendorType, Mandatory and Hidden sub-attributes; other sub-attributes may be added as needed. Use of the VendorId and VendorType subattribute may be used for expression of vendor-specific attributes, such as those supported in RADIUS. 5.1. ADIF Examples Example 1: An ADIF file encoding RADIUS accounting data version: 1 device: server3 descripton: Accounting Server 3 date: 02 Mar 1998 12:19:01 -0500 defaultProtocol: radius #NAS-IP-Address 4: 204.45.34.12 #NAS-Port 5: 12 #NAS-Port-Type 61: 2 Aboba & Lidyard Standards Track [Page 3] INTERNET-DRAFT The Accounting Data Interchange Format17 November 1998 #User-Name 1: fred@bigco.com #Acct-Status-Type 40: 2 #Acct-Delay-Time 41: 14 #Acct-Input-Octets 42: 234732 #Acct-Output-Octets 43: 15439 #Acct-Session-Id 44: 185 #Acct-Authentic 45: 1 #Acct-Session-Time 46: 1238 #Acct-Input-Packets 47: 153 #Acct-Output-Packets 48: 148 #Acct-Terminate-Cause 49: 11 #Acct-Multi-Session-Id 50: 73 #Acct-Link-Count 51: 2 Example 2: An ADIF file with a vendor-specific attribute version: 1 device: server3 descripton: Accounting Server 3 date: 02 Mar 1998 12:19:01 -0500 defaultProtocol: radius 4: 204.45.34.12 5: 12 61: 2 1: fred@bigco.com #Vendor-Specific 26: 2; VID=301; VT=22 40: 2 41: 14 42: 234732 43: 15439 44: 185 45: 1 46: 1238 47: 153 48: 148 49: 11 50: 73 51: 2 Aboba & Lidyard Standards Track [Page 4] INTERNET-DRAFT The Accounting Data Interchange Format17 November 1998 5.2. Grammar The following definition uses the ABNF specified in [6]: adif-file = header-spec *SEP 1*( SEP adif-record ) header-spec = required-info SEP [optional-info SEP] required-info = device-spec SEP start-spec SEP optional-info = [version-spec SEP ] [description SEP] [def-protocol SEP] device-spec = "device:" *SP value description = "description:" *SPACE value def-protocol = "defaultProtocol:" *SPACE protocol protocol = version-spec = "version:" *SPACE version-number version-number = 1*DIGIT ; version-number MUST be "1" for the ; ADIF format described in this document start-spec = "date:" *SP datetime datetime = date SP time date = Dd SP Mon SP YYYY time = hh ":" mm ":" ss SP zone Dd = Mon = "JAN" / "FEB" / "MAR" / "APR" / "MAY" / "JUN" / "JUL" / "AUG" / "SEP" / "OCT" / "NOV" / "DEC" YYYY = hh = mm = ss = zone = adif-record = 1*(attrval-series SEP) attrval-series = 1*(attrval-spec) attrval-spec = attr ( (std-encoding / base-64-encoding) [sub-attr-encoding]) comment = ("#" *safe) std-encoding = (":" *SP value ) base-64-encoding = ("::" *SP base64-value ) base64-value = sub-attr-enoding = *(";" sub-attr "=" ) sub-attr = "M" / "H" / "VID" / "VT" ; Mandatory, Hidden, Vendor ID, Vendor Type sub-attributes attr = [protocol "//"] attribute-number attribute-number = value = 1*safe-initval *safe safe = LF = Alpha = %x41-5A / %x61-7A ; A-Z / a-z Digit = %x30-39 ;0-9 6. References [1] Aboba, B., Lu J., Alsop J.,Ding J., and W. Wang, "Review of Roam- ing Implementations", RFC 2194, September 1997. [2] Aboba, B., and G. Zorn, "Criteria for Evaluating Roaming Proto- cols", Internet draft (work in progress), draft-ietf-roamops-roam- req-10.txt, November 1998. [3] Rigney C., Rubens A., Simpson W., and S. Willens, "Remote Authen- tication Dial In User Service (RADIUS)", RFC 2138, April 1997. [4] Rigney C., "RADIUS Accounting", RFC 2139, April 1997. [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [6] Crocker, D., and P. Overrell, "Augmented BNF for Syntax Specifica- tions: ABNF", RFC 2234, November 1997. [7] Good, G., "The LDAP Data Interchange Format (LDIF) - Technical Specification", Internet draft (work in progress), draft-ietf-asid- ldif-02.txt, July 1997. [8] K. Hamzeh, T. Kolar, M. Littlewood, G. S. Pall, J. Taarud, A. J. Valencia, W. Verthein. "Layer Two Tunneling Protocol -- L2TP." Internet draft (work in progress), draft-ietf-pppext-l2tp-12.txt, August 1998. [9] Carrel, D., and L. Grant, "The TACACS+ Protocol Version 1.78", Work in progress, draft-grant-tacacs-02.txt, March 1998. [10] McCloghrie, K., Heinanen, J., Greene, W., A. Prasad, "Managed Objects for Controlling the Collection and Storage of Accounting Information for Connection-Oriented Networks", Internet draft (work in progress), draft-ietf-atommib-acct-04.txt, November 1996. [11] 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. [12] Atkinson, R., "Security Architecture for the Internet Protocol", RFC 1825, August 1995. Aboba & Lidyard Standards Track [Page 6] INTERNET-DRAFT The Accounting Data Interchange Format17 November 1998 7. Security Considerations Since accounting data may include sensitive information, it it may be desirable for this information to be kept confidential during trans- mission. Several mechanisms may be used to accomplish this, including IPSEC, described in [12]. 8. IANA Considerations This draft creates two new name spaces that will need to be adminis- tered by IANA, namely the ADIF protocol and attribute number spaces. In order to to avoid creating any new administrative procedures, administration of the ADIF protocol namespace will piggyback on the administration of IP protocol and TCP and UDP port numbers. Adminis- tration of the ADIF attribute number space will piggyback on adminis- tration of the attribute numbers or object identifiers for the proto- col in question. ADIF protocol names are required to be unique and the rights to use a given ADIF protocol name are obtained coincident with allocation of an IP protocol number or UDP/TCP port number. In applying for a protocol number or UDP/TCP port, a unique keyword is assigned to the protocol, and this keyword is then used as the ADIF protocol name. Those wishing to use an ADIF protocol name should first acquire the rights to use the corresponding protocol or port number. Using an ADIF protocol name without first obtaining rights to a protocol or port number creates the possibility of conflict and therefore is to be dis- couraged. 9. Acknowledgements Thanks to Glen Zorn of Microsoft and Pat Calhoun of Sun Microsystems for useful discussions of this problem space. 10. 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 Nashville, TN 37214 Phone: 615-231-6110 Aboba & Lidyard Standards Track [Page 7] INTERNET-DRAFT The Accounting Data Interchange Format17 November 1998 EMail: dave@telcores.com 11. Full Copyright Statement Copyright (C) The Internet Society (1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this docu- ment itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Inter- net organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permis- sions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WAR- RANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 12. Expiration Date This memo is filed as , and expires June 1, 1999. Aboba & Lidyard Standards Track [Page 8]