idnits 2.17.1 draft-ietf-roamops-actng-07.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 11 instances of too long lines in the document, the longest one being 12 characters in excess of 72. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 80 has weird spacing: '...tion be measu...' == Line 436 has weird spacing: '...hanisms for S...' == Line 538 has weird spacing: '...>, and expir...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (25 April 2000) is 8767 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '7' is defined on line 420, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 427, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 443, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2194 (ref. '1') ** Downref: Normative reference to an Informational RFC: RFC 2477 (ref. '2') ** Obsolete normative reference: RFC 2138 (ref. '3') (Obsoleted by RFC 2865) ** Obsolete normative reference: RFC 2139 (ref. '4') (Obsoleted by RFC 2866) ** Obsolete normative reference: RFC 2234 (ref. '6') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 1700 (ref. '7') (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 1521 (ref. '11') (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) ** Obsolete normative reference: RFC 2401 (ref. '12') (Obsoleted by RFC 4301) ** Downref: Normative reference to an Informational RFC: RFC 1272 (ref. '13') ** Obsolete normative reference: RFC 2063 (ref. '14') (Obsoleted by RFC 2722) ** Obsolete normative reference: RFC 2064 (ref. '15') (Obsoleted by RFC 2720) Summary: 17 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 ROAMOPS Working Group Bernard Aboba 2 INTERNET-DRAFT Microsoft Corporation 3 Category: Standards Track Dave Lidyard 4 Telco Research Corporation 5 25 April 2000 7 The Accounting Data Interchange Format (ADIF) 9 This document is an Internet-Draft and is in full conformance with all 10 provisions of Section 10 of RFC2026. 12 Internet-Drafts are working documents of the Internet Engineering Task 13 Force (IETF), its areas, and its working groups. Note that other groups 14 may also distribute working documents as Internet- Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference material 19 or to cite them other than as "work in progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 1. Copyright Notice 29 Copyright (C) The Internet Society (2000). All Rights Reserved. 31 2. Abstract 33 This document describes an extensible human-readable accounting record 34 format, the Accounting Data Interchange Format (ADIF). Based on MIME, 35 ADIF is designed to compactly represent accounting data from any 36 protocol using attribute/value pairs or object identifiers. 38 While in many cases Accounting Servers will produce ADIF records based 39 on data from accounting protocols, it is also possible for devices to 40 store data in ADIF format and transfer ADIF records to the accounting 41 server. The latter approach has the advantage of offloading the 42 Accounting Server from the task of transcribing interim or session 43 records, thus improving scalability. This approach also enables the 44 transport of data from multiple sources within the same set of records. 45 Where a record format is employed that supports batching, the transport 46 of multiple records within the same accounting packet is enabled. 48 2.1. History 50 -06 draft: added to terminology section. Fixed ABNF issues with respect 51 to use of the space character. Added ability to support complex objects 52 via numbered sub-attributes. Still needed: examples for protocols other 53 than RADIUS, including SNMP, L2TP, LDAP and COPS. 55 3. Introduction 57 This document describes an extensible human-readable accounting record 58 format, the Accounting Data Interchange Format (ADIF). Based on MIME, 59 ADIF is designed to compactly represent accounting data from any 60 protocol using attribute/value pairs or object identifiers. 62 While in many cases Accounting Servers will produce ADIF records based 63 on data from accounting protocols, it is also possible for devices to 64 store data in ADIF format and transfer ADIF records to the accounting 65 server. The latter approach has the advantage of offloading the 66 Accounting Server from the task of transcribing interim or session 67 records, thus improving scalability. This approach also enables the 68 transport of data from multiple sources within the same set of records. 69 Where a record format is employed that supports batching, the transport 70 of multiple records within the same accounting packet is enabled. 72 3.1. Terminology 74 This document uses the following terms: 76 Accounting 77 The collection of resource consumption data for the purposes 78 of capacity and trend analysis, cost allocation, auditing, and 79 billing. Accounting management requires that resource 80 consumption be measured, rated, assigned, and communicated 81 between appropriate parties. 83 Rating The act of determining the price to be charged for use of a 84 resource. 86 Billing The act of preparing an invoice. 88 Archival accounting 89 In archival accounting, the goal is to collect all accounting 90 data, to reconstruct missing entries as best as possible in 91 the event of data loss, and to archive data for a mandated 92 time period. It is "usual and customary" for these systems to 93 be engineered to be very robust against accounting data loss. 94 Legal or financial requirements frequently mandate archival 95 accounting practices, and may often dictate that data be kept 96 confidential, regardless of whether it is to be used for 97 billing purposes or not. 99 Interim accounting 100 An interim accounting packet provides a snapshot of usage 101 during a user's session. This may be useful in the event of a 102 device reboot or other network problem that prevents the 103 reception or generation of a session summary packet or session 104 record. Interim accounting packets can always be summarized 105 without the loss of information. 107 Session record 108 A session record represents a summary of the resource 109 consumption of a user over the entire session. Accounting 110 gateways creating the session record may do so by processing 111 interim accounting events or accounting events from several 112 devices serving the same user. 114 Accounting Protocol 115 A protocol used to convey data for accounting purposes. 117 Accounting server 118 The accounting server receives accounting data from devices 119 and translates it into session records. The accounting server 120 may also take responsibility for the routing of session 121 records to interested parties. 123 4. Accounting record format requirements 125 As detailed in [2], solution of the accounting problem in roaming 126 requires a standardized accounting record format to enable exchange of 127 accounting data between members of a roaming consortium. Since 128 operational roaming services, described in [1], exhibit considerable 129 diversity in their accounting implementations it is desirable that the 130 chosen accounting record format be protocol-independent.Since accounting 131 implementations are continually adding new attributes, extensibility is 132 useful. 134 For accounting session records, compactness of representation is a 135 virtue. Session records can be stored within devices where memory or 136 non-volatile storage is at a premium. Thus the compactness of the 137 representation will determine how much data can be stored prior to 138 experiencing data loss. To satisfy legal and regulatory requirements it 139 has become customary to archive session records. Thus, the compactness 140 of the representation will determine how much warehouse space is 141 required to store the tapes or CD-ROMs of the archived data. In 142 addition, where session records are transferred over the wire the 143 compactness of representation will determine bandwidth consumption. For 144 all these reasons, smaller is better. 146 It is also desirable that an accounting session records be human 147 readable. Since the processing of accounting data may ultimately result 148 in the transfer of funds, it is important that the software producing 149 and handling session records be correct. Human readable accounting 150 formats are considerably easier to implement and debug than binary 151 formats and thus software based on them is more likely to be free of 152 defects. 154 In reviewing the current state of the art in accounting data 155 representation, it was determined that existing approaches could not 156 satisfy the requirements for generality, extensibility, compactness and 157 human readability. For example, protocol-specific solutions such as the 158 SNMP-oriented record format described in [10] do not offer sufficient 159 flexibility in representing data from other protocols. They also have 160 the disadvantage of not being human readable. Existing call detail 161 records based on fixed record formats, while being human readable, do 162 not offer the required extensibility. 164 While XML is human readable as well as being very extensible and 165 flexible, it is not compact. As a result, XML-based session records are 166 likely to consume many times more storage space than a MIME-based 167 approach. While compression techniques can be used to reduce the size of 168 XML-based session records, the resulting compressed records are still 169 larger than comparable compressed MIME-based records. As a result, it is 170 to be expected that XML-based session records will suffer in terms of 171 compactness. 173 As a result of these considerations, it was decided to base ADIF on 174 MIME, described in [11]. The use of MIME has enabled ADIF to represent 175 both printable and non-printable characters as well as to allow 176 representation of attributes of unlimited size. Through the use of 177 attribute numbers and protocol defaults, it has been possible to produce 178 an accounting record format that is simultaneously human readable, 179 general, extensible, and compact. 181 4.1. Requirements language 183 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 184 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 185 described in [5]. 187 5. Definition of the Accounting Data Interchange Format (ADIF) 189 ADIF is based on MIME, described in [11] and consists of a header 190 providing basic information about the records in the file, followed by a 191 series of records each separated by a separator. 193 The header includes the ADIF version number (1 for this document), 194 device name/description, and collection start date and time. A default 195 protocol type may be optionally included in the header. Note that it is 196 possible to use ADIF in a real-time accounting environment where 197 individual records are transmitted by the device to the Accounting 198 Server in ADIF format. In such a case it is up to the mechanism to 199 specify whether ADIF headers are included within each record or are 200 agreed to beforehand via some out-of-band mechanism. 202 Each record may consist of one or more lines, and as with MIME, 203 described in [11], lines may be continued by putting a space or tab 204 character on the succeeding line, allowing attributes to be of arbitrary 205 length. Lines beginning with the "#" character are taken as comments 206 and ignored. 208 Accounting records have traditionally been human-readable, so as to 209 allow them to be more easily debugged. ADIF attributes can be expressed 210 either in NVT ASCII (characters 32 through 126) or if non-printable 211 characters are required, in base64. 213 ADIF includes support for encoding of attributes for any protocol 214 utilizing attribute/value pairs or object identifiers. This includes 215 RADIUS, defined in [3] and [4], RTFM, defined in [14] and [15], L2TP, 216 defined in [8] as well as SNMP, TACACS+ and COPS, defined in [16]. The 217 protocol type is indicated by prepending the protocol keyword as defined 218 by IANA and a "//" to the attribute number, i.e. radius//46. 220 To improve compactness, when a default protocol is indicated in the 221 header, attributes of the default protocol do not need to include the 222 protocol type. For example, if defaultProtocol: rtfm is indicated in 223 the ADIF header, then 32 may be used instead of rtfm//32. 225 In order to allow for compact representation of object identifiers, the 226 ADIF header allows the definition of oid-names that can be used in place 227 of an object-identifier sub-tree. For example, the inclusion of a header 228 statement: 229 oid-define: mib-2=1.3.6.1.2.1; 231 would permit the string "mib-2" to substitute for the sub-tree 232 1.3.6.1.2.1 wherever this occurred within the accounting record file. 233 This would allow the OID 1.3.6.1.2.1.2 to be abbreviated as mib-2.2. 235 Protocols such as L2TP, defined in [8] include additional fields such as 236 Vendor ID and flags in their Attribute Value Pairs (AVPs). Protocols 237 such as COPS, defined in [16] include attribute numbers expressed as a 238 combination of C-Num and C-Type as well as supporting complex objects. 239 To encode such AVPs, ADIF includes support for attribute numbers 240 expressed in OID form, as well as sub-attributes. 242 Sub-attributes are included as additional fields, separated by a semi- 243 colon, and are of the form = . Sub-attributes used 244 in complex objects are numbered starting from 1; letters are used for 245 well-known sub-attributes. This document includes support for the 246 following well-known sub-attributes: VendorId, VendorType, Mandatory and 247 Hidden, which apply to all protocols. Other sub-attributes may be added 248 as needed. Use of the VendorId and VendorType sub-attribute may be used 249 for expression of vendor-specific attributes, such as those supported in 250 RADIUS. 252 As an example, the L2TP version number attribute (attribute 2) with the 253 Mandatory bit set would be expressed as "l2tp//2: 1; M=1". A COPS In- 254 Interface object (C-Num=3, C-Type=1, including an IPv4 address of 255 204.57.137.2 and an interface index of 1) would be expressed as 256 "cops//3.1: 1=204.57.137.2; 2=1" 258 5.1. ADIF Examples 260 Example 1: An ADIF file encoding RADIUS accounting data 262 version: 1 263 device: server3 264 description: Accounting Server 3 265 date: 02 Mar 1999 12:19:01 -0500 266 defaultProtocol: radius 268 rdate: 02 Mar 1999 12:20:17 -0500 269 #NAS-IP-Address 270 4: 204.45.34.12 271 #NAS-Port 272 5: 12 273 #NAS-Port-Type 274 61: 2 275 #User-Name 276 1: fred@bigco.com 277 #Acct-Status-Type 278 40: 2 279 #Acct-Delay-Time 280 41: 14 281 #Acct-Input-Octets 282 42: 234732 283 #Acct-Output-Octets 284 43: 15439 285 #Acct-Session-Id 286 44: 185 287 #Acct-Authentic 288 45: 1 289 #Acct-Session-Time 290 46: 1238 291 #Acct-Input-Packets 292 47: 153 293 #Acct-Output-Packets 294 48: 148 295 #Acct-Terminate-Cause 296 49: 11 297 #Acct-Multi-Session-Id 298 50: 73 299 #Acct-Link-Count 300 51: 2 302 Example 2: An ADIF file encoding RADIUS data with a vendor-specific 303 attribute 305 version: 1 306 device: server3 307 description: Accounting Server 3 308 date: 02 Mar 1998 12:19:01 -0500 309 defaultProtocol: radius 311 rdate: 02 Mar 1998 12:25:23 -0500 312 4: 204.45.34.12 313 5: 12 314 61: 2 315 1: fred@bigco.com 316 #Vendor-Specific 317 26: 2; VID=301; VT=22 318 40: 2 319 41: 14 320 42: 234732 321 43: 15439 322 44: 185 323 45: 1 324 46: 1238 325 47: 153 326 48: 148 327 49: 11 328 50: 73 329 51: 2 331 5.2. Grammar 333 The following definition uses the ABNF specified in [6]: 335 adif-file = header-spec *SEP 1*( SEP adif-record ) 336 header-spec = required-info SEP [optional-info SEP] 337 required-info = device-spec SEP start-spec SEP 338 optional-info = [version-spec SEP ] [description SEP] [def-protocol SEP] 339 [oid-def-spec SEP ] 340 device-spec = "device:" *SP value 341 description = "description:" *SP value 342 oid-def-spec = "oid-define:" *SP 1*(oid-name "=" oid-num ";") 343 def-protocol = "defaultProtocol:" *SP protocol 344 protocol = 345 version-spec = "version:" *SP number 346 number = 1*Digit ; number MUST be "1" for the 347 ; ADIF format described in this document 348 start-spec = "date:" *SP datetime 349 datetime = date SP time 350 date = Dd SP Mon SP YYYY 351 time = hh ":" mm ":" ss SP zone 352 Dd = 354 Mon = "JAN" / "FEB" / "MAR" / "APR" / "MAY" / "JUN" / 355 "JUL" / "AUG" / "SEP" / "OCT" / "NOV" / "DEC" 356 YYYY = 358 hh = 360 mm = 362 ss = 364 zone = 367 adif-record = 1*(attrval-series SEP) 368 attrval-series = [rdate-spec SEP] 1*(attrval-spec) 369 rdate-spec = "rdate:" *SP datetime 370 ; date at which accounting data was received 371 attrval-spec = attr ( (std-encoding / base-64-encoding) [sub-attr-encoding]) 372 comment = ("#" *safe) 373 std-encoding = (":" *SP value ) 374 base-64-encoding = ("::" *SP base64-value ) 375 base64-value = 376 sub-attr-encoding = *(";" sub-attr "=" ) 377 sub-attr = "M" / "H" / "VID" / "VT" / Digit 378 ; Mandatory, Hidden, Vendor ID, Vendor Type 379 ; well known sub-attributes or digit 380 attr = [protocol "//"] attribute-number 381 attribute-number = number / oid 382 oid = [ oid-name "." ] oid-num 383 oid-name = Alpha *(ldh-str) 384 oid-num = *(number "." ) number 385 value = 1*safe-initval *safe 386 safe = 394 LF = 395 ldh-str = *( Alpha / Digit / "-" ) let-dig 396 let-dig = Alpha / Digit 397 Alpha = %x41-5A / %x61-7A ; A-Z / a-z 398 Digit = %x30-39 ;0-9 400 6. References 402 [1] Aboba, B., Lu J., Alsop J.,Ding J., and W. Wang, "Review of Roaming 403 Implementations", RFC 2194, September 1997. 405 [2] Aboba, B., and G. Zorn, "Criteria for Evaluating Roaming 406 Protocols", RFC 2477, January 1999. 408 [3] Rigney C., Rubens A., Simpson W., and S. Willens, "Remote 409 Authentication Dial In User Service (RADIUS)", RFC 2138, April 410 1997. 412 [4] Rigney C., "RADIUS Accounting", RFC 2139, April 1997. 414 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 415 Levels", BCP 14, RFC 2119, March 1997. 417 [6] Crocker, D., and P. Overrell, "Augmented BNF for Syntax 418 Specifications: ABNF", RFC 2234, November 1997. 420 [7] Reynolds, J., Postel, J., "Assigned Numbers," RFC 1700, October 421 1994. 423 [8] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and 424 Palter, B., "Layer Two Tunneling Protocol L2TP", RFC 2661, August 425 1999. 427 [9] McCloghrie, K., Heinanen, J., Greene, W., Prasad, A., "Accounting 428 Information for ATM Networks", RFC 2512, February 1999. 430 [10] McCloghrie, K., Heinanen, J., Greene, W., Prasad, A., "Managed 431 Objects for Controlling the Collection and Storage of Accounting 432 Information for Connection-Oriented Networks", RFC 2513, February 433 1999. 435 [11] Borenstein, N., Freed, N. "MIME (Multipurpose Internet Mail 436 Extensions) Part One: Mechanisms for Specifying and Describing 437 the Format of Internet Message Bodies", RFC 1521, Bellcore, 438 Innosoft, December 1993. 440 [12] Atkinson, R., Kent, S., "Security Architecture for the Internet 441 Protocol", RFC 2401, November 1998. 443 [13] Mills, C., Hirsch, G. and Ruth, G., "Internet Accounting 444 Background", RFC 1272, November 1991. 446 [14] Brownlee, N., Mills, C., and Ruth, G., "Traffic Flow Measurement: 447 Architecture", RFC 2063, January 1997. 449 [15] Brownlee, N., "Traffic Flow Measurement: Meter MIB", Measurement: 450 Architecture", RFC 2064, January 1997. 452 [16] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R. and A. 453 Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, 454 January 2000. 456 7. Security Considerations 458 Since accounting data may include sensitive information, it may be 459 desirable for this information to be kept confidential during 460 transmission. Several mechanisms may be used to accomplish this, 461 including IPSEC, described in [12]. 463 8. IANA Considerations 465 This draft creates two new name spaces that will need to be administered 466 by IANA, namely the ADIF protocol name and attribute number spaces. In 467 order to avoid creating any new administrative procedures, 468 administration of the ADIF protocol name space will piggy-back on the 469 allocation of IP protocol and UDP/TCP port numbers. Administration of 470 the ADIF attribute number space will piggy-back on administration of the 471 attribute numbers or object identifiers for the protocol in question. 473 ADIF protocol names are required to be unique, and are created 474 coincident with allocation of an IP protocol number or UDP/TCP port 475 number. In applying for a protocol number or UDP/TCP port, a unique 476 keyword is assigned to the protocol, and this keyword is used as the 477 ADIF protocol name. 479 Those wishing to use an ADIF protocol name should first acquire the 480 rights to use the corresponding protocol or port number. Using an ADIF 481 protocol name without first obtaining rights to a protocol or port 482 number creates the possibility of conflict and therefore is to be 483 discouraged. 485 Similarly, ADIF attribute numbers are allocated coincident with IANA 486 allocation of attribute numbers or object identifiers for a given 487 protocol. 489 9. Acknowledgments 491 Thanks to Glen Zorn of Cisco Systems, Jari Arkko of Ericsson, David 492 Franscone and Pat Calhoun of Sun Microsystems, Thomas Narten of IBM, and 493 Ryan Moats of AT&T for useful discussions of this problem space. 495 10. Authors' Addresses 497 Bernard Aboba 498 Microsoft Corporation 499 One Microsoft Way 500 Redmond, WA 98052 502 Phone: 425-936-6605 503 EMail: bernarda@microsoft.com 505 Dave Lidyard 506 Telco Research Corporation 507 616 Marriott Drive 508 Nashville, TN 37214 510 Phone: 615-231-6110 511 EMail: dave@telcores.com 513 11. Full Copyright Statement 515 Copyright (C) The Internet Society (2000). All Rights Reserved. 516 This document and translations of it may be copied and furnished to 517 others, and derivative works that comment on or otherwise explain it or 518 assist in its implementation may be prepared, copied, published and 519 distributed, in whole or in part, without restriction of any kind, 520 provided that the above copyright notice and this paragraph are included 521 on all such copies and derivative works. However, this document itself 522 may not be modified in any way, such as by removing the copyright notice 523 or references to the Internet Society or other Internet organizations, 524 except as needed for the purpose of developing Internet standards in 525 which case the procedures for copyrights defined in the Internet 526 Standards process must be followed, or as required to translate it into 527 languages other than English. The limited permissions granted above are 528 perpetual and will not be revoked by the Internet Society or its 529 successors or assigns. This document and the information contained 530 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 531 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 532 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 533 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 534 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 536 12. Expiration Date 538 This memo is filed as , and expires 539 November 1, 2000.