Criteria for Evaluating Roaming Protocols
What a dial-up roaming protocol has to do before it can be called standard
Aboba, B. and G. Zorn, "Criteria for Evaluating Roaming Protocols", RFC 2477, DOI 10.17487/RFC2477, January 1999, <https://www.rfc-editor.org/info/rfc2477>.
@misc{rfc2477,
series = {Request for Comments},
number = 2477,
howpublished = {RFC 2477},
publisher = {RFC Editor},
doi = {10.17487/RFC2477},
url = {https://www.rfc-editor.org/info/rfc2477},
author = {B. Aboba and G. Zorn},
title = {{Criteria for Evaluating Roaming Protocols}},
pagetotal = 12,
year = 1999,
month = jan,
} RFC text
Contents
Network Working Group B. Aboba
Request for Comments: 2477 G. Zorn
Category: Informational Microsoft Corporation
January 1999
Criteria for Evaluating Roaming Protocols
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
1. Abstract
This document describes requirements for the provisioning of "roaming
capability" for dialup Internet users. "Roaming capability" is
defined as the ability to use multiple Internet service providers
(ISPs), while maintaining a formal, customer-vendor relationship with
only one.
2. Introduction
Operational roaming services are currently providing worldwide
roaming capabilities, and these services continue to grow in
popularity [1]. Interested parties have included:
Regional Internet Service Providers (ISPs) operating within a
particular state or province, looking to combine their efforts
with those of other regional providers to offer services over a
wider area.
National ISPs wishing to combine their operations with those of
one or more ISPs in another nation to provide greater coverage in
a group of countries or on a continent.
Businesses desiring to offer their employees a comprehensive
package of dialup services on a global basis. Those services can
include Internet access as well as secure access to corporate
intranets via a Virtual Private Network (VPN).
This document provides an architectural framework for the
provisioning of roaming capabilities, as well as describing the
requirements that must be met by elements of the architecture.
2.1. 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 [4].
Please note that the requirements specified in this document are to
be used in evaluating protocol submissions. As such, the
requirements language refers to capabilities of these protocols; the
protocol documents will specify whether these features are required,
recommended, or optional for use in roaming. For example, requiring
that a protocol support confidentiality is NOT the same thing as
requiring that all protocol traffic be encrypted.
A protocol submission is not compliant if it fails to satisfy one or
more of the must or must not requirements for the capabilities that
it implements. A protocol submission that satisfies all the must,
must not, should and should not requirements for its capabilities is
said to be "unconditionally compliant"; one that satisfies all the
must and must not requirements but not all the should or should not
requirements for its protocols is said to be "conditionally
compliant."
2.2. Terminology
This document frequently uses the following terms:
phone book
This is a database or document containing data pertaining to
dialup access, including phone numbers and any associated
attributes.
phone book server
This is a server that maintains the latest version of the phone
book. Clients communicate with phone book servers in order to
keep their phone books up to date.
Network Access Server
The Network Access Server (NAS) is the device that clients dial in
order to get access to the network.
Authentication server
This is a server which provides for authentication/authorization
within the roaming architecture.
Accounting server
This is a server which provides for accounting within the roaming
architecture.
Authentication proxy
Authentication proxies may be deployed within the roaming
architecture for several purposes, including authentication
forwarding, policy implementation, shared secret management, and
attribute editing. To the NAS, the authentication proxy appears
to act as an authentication server; to the authentication server,
the proxy appears to act as an authentication client.
Accounting proxy
Accounting proxies may be deployed within the roaming architecture
for several purposes, including accounting forwarding, reliability
improvement, auditing, and "pseudo-transactional" capability. To
the NAS, the accounting proxy appears to act as an accounting
server; to the accounting server, the proxy appears to act as an
accounting client.
Network Access Identifier
In order to provide for the routing of authentication and
accounting packets, user name MAY contain structure. This
structure provides a means by which the authentication or
accounting proxies will locate the authentication or accounting
server that is to receive the request.
3. Architectural framework
The roaming architecture consists of three major subsystems:
Phone book Subsystem
Authentication Subsystem
Accounting Subsystem
The phone book subsystem is concerned with the maintenance and
updating of the user phone book. The phone book provides the user
with information on the location and phone numbers of Points of
Presence (POPs) that are roaming enabled. The function of the
authentication subsystem is to provide authorized users with access
to the POPs in the phonebook, and to deny access to unauthorized
users. The goal of the accounting subsystem is to provide
information on the resources utilized during the user's session.
3.1. Phone Book Subsystem
The phone book subsystem provides for the following:
Phone number presentation
Phone number exchange
Phone book compilation
Phone book update
Phone number presentation
Phone number presentation involves the display of available phone
numbers to the user, and culminates in the choosing of a number.
Since the user interface and sequence of events involved in phone
number presentation is a function of the connection management
software being used, it is likely that individual vendors will
take different approaches to the problem. These differences can
include variances in the format of the client phone books, varying
approaches to presentation, etc. There is no inherent problem
with this. As a result, phone number presentation need not be
standardized.
Phone number exchange
Phone number exchange involves propagation of phone number changes
between providers in a roaming association. Current roaming
implementations do not provide for complete automation of the
phone number exchange process [1]. As a result, phone number
exchange need not be standardized at this time.
Phone book compilation
Once an ISP's phone book server has received its updates it needs
to compile a new phone book and propagate this phone book to all
the phone book servers operated by that ISP. Given that the
compilation process does not affect protocol interoperability, it
need not be standardized.
Phone book update
Once the phone book is compiled, it needs to be propagated to
users. Standardization of the phone book update process allows
for providers to update user phone books, independent of their
client software or operating system.
3.2. Authentication Subsystem
The authentication subsystem provides for the following:
Connection management
Authentication
NAS Configuration/Authorization
Address Assignment/Routing
Security
Connection management
In order to be able to use the POPs of the local provider, it is
first necessary to bring up a connection.
Identification
Authentication consists of two parts: the claim of identity (or
identification) and the proof of the claim (or verification). As
part of the authentication process, users identify themselves to
the Network Access Server (NAS) in a manner that allows the
authentication request to be routed its home destination.
Authentication
Authentication is typically required prior to allowing access to
the network. CHAP [8] and PAP [9] are the two authentication
protocols most commonly used within the PPP [10] framework today.
Some groups of users are requiring different forms of proof of
identity (e.g., token or smart cards, Kerberos credentials, etc.)
for special purposes (such as acquiring access to corporate
intranets). The Extensible Authentication Protocol (EAP) [7] was
created in order to provide a general mechanism for support of
these methods.
NAS configuration/authorization
In order to set up the session, authorization parameters need to
be sent to from the home authentication server to the local ISP's
NAS.
Address assignment/routing
If it is desired that the user be able to communicate with the
rest of the Internet, then the session will be assigned a routable
IP address by the NAS.
Security
In the process of authenticating and authorizing the user session,
it may be desirable to provide protection against a variety of
security threats.
3.3. Accounting Subsystem
The function of the accounting subsystem is to enable the
participants in the roaming consortium to keep track of what
resources are used during a session. Relevant information includes
how long the user was connected to the service, connection speed,
port type, etc.
4. Roaming Requirements
4.1. Phonebook requirements
4.1.1. Phone book update protocol
Portability
The update protocol MUST allow for updating of clients on a range of
platforms and operating systems. Therefore the update mechanism MUST
NOT impose any operating system-specific requirements.
Authentication
The client MUST be able to determine the authenticity of the server
sending the phone book update. The server MAY also be able to
authenticate the client.
Versioning
The update protocol MUST provide for updating of the phone book from
an arbitrary previous version to the latest available version.
Integrity Checking
The client MUST be able to determine the integrity of the received
update before applying it, and MUST be able to determine the
integrity of the newly produced phone book after updating it.
Light weight transfers
Since the client may be a low-end machine or internet appliance, the
update protocol MUST be lightweight.
Language support
The phone book update mechanism MUST support the ability to request
that the phone book be transmitted in a particular language and
character set. For example, if the customer has a Russian language
software package, then the propagation and update protocols MUST
provide a mechanism for the user to request a Russian language phone
book.
4.1.2. Phone book format
Phone number attributes
The phone book format MUST support phone number attributes commonly
used by Internet service providers. These attributes are required in
order to provide users with information on the capabilities of the
available phone numbers.
Provider attributes
In addition to providing information relating to a given phone
number, the phone book MUST provide information on the individual
roaming consortium members. These attributes are required in order
to provide users with information about the individual providers in
the roaming consortium.
Service attributes
In addition to providing information relating to a given phone
number, and service provider, the phone book MUST provide information
relevant to configuration of the service. These attributes are
necessary to provide the client with information relating to the
operation of the service.
Extensibility
Since it will frequently be necessary to add phone book attributes,
the phone book format MUST support the addition of phone number,
provider and service attributes without modification to the update
protocol. Registration of new phone book attributes will be handled
by IANA. The attribute space MUST be sufficiently large to
accomodate growth.
Compactness
Since phone book will typically be frequently updated, the phone book
format MUST be compact so as to minimize the bandwidth used in
updating it.
4.2. Authentication requirements
4.2.1. Connection Management
Given the current popularity and near ubiquity of PPP, a roaming
standard MUST provide support for PPP and IP. A roaming standard MAY
provide support for other framing protocols such as SLIP. However,
SLIP support is expected to prove difficult since SLIP does not
support negotiation of connection parameters and lacks support for
protocols other than IP.
A roaming standard MAY provide support for non-IP protocols (e.g.,
IPX or AppleTalk) since these may be useful for the provision of
corporate intranet access via the Internet. Since it is intended
that the client will begin PPP negotiation immediately on connection,
support for scripting SHOULD NOT be part of a roaming standard.
4.2.2. Identification
A roaming standard MUST provide a standardized format for the userID
and realm presented to the NAS.
4.2.3. Verification of Identity
Authentication types
A roaming standard MUST support CHAP, and SHOULD support EAP. Due
to security concerns, PAP authentication SHOULD NOT be supported.
A possible exception is where PAP is used to support a one time
password or token.
Scalability
A roaming standard, once available, is likely to be widely
deployed on the Internet. A roaming standard MUST therefore
provide sufficient scalability to allow for the formation of
roaming associations with thousands of ISP members.
RADIUS Support
Given the current popularity and near ubiquity of RADIUS [2,3] as
an authentication, authorization and accounting solution, a
roaming standard MUST be able to incorporate RADIUS-enabled
devices within the roaming architecture. It is expected that this
will be accomplished by development of gateways between RADIUS and
the roaming standard authentication, authorization, and accounting
protocol.
4.2.4. NAS Configuration/Authorization
In order to ensure compatibility with the NAS or the local network,
authentication/authorization proxies often will add, delete, or
modify attributes returned by the home authentication server. In
addition, an authentication proxy will often carry out resource
management and policy functions. As a result, a roaming standard
MUST support the ability of proxies to perform attribute editing and
implement policy.
4.2.5. Address assignment/routing
A roaming standard MUST support dynamic address assignment. Static
address assignment MAY be supported, most likely via layer 2 or layer
3 tunneling.
Layer 2 tunneling protocols
Layer-2 tunneling protocols, such as PPTP, L2F, or L2TP, hold
great promise for the implementation of Virtual Private Networks
as a means for inexpensive access to remote networks. Therefore
proxy implementations MUST NOT preclude use of layer 2 tunneling.
Layer 3 tunneling protocols
Layer-3 tunneling protocols as embodied in Mobile IP [5], hold
great promise for providing "live", transparent mobility on the
part of mobile nodes on the Internet. Therefore, a roaming
standard MUST NOT preclude the provisioning of Mobile IP Foreign
Agents or other Mobile IP functionality on the part of service
providers.
4.2.6. Security
Security analysis
A roaming standard MUST include a thorough security analysis,
including a description of security threats and countermeasures.
This includes specification of mechanisms for fraud prevention and
detection.
Hop by hop security
A roaming standard MUST provide for hop-by-hop integrity
protection and confidentiality. This MAY be accomplished through
support of network layer security (IPSEC) [6].
End-to-end security
As policy implementation and attribute editing are common in
roaming systems, proxies may need to modify packets in transit
between a local NAS and the home server. In order to permit
authorized modifications while at the same time guarding against
attacks by rogue proxies, it is necessary for a roaming standard
to support data object security. As a result, a roaming standard
MUST provide end-to-end confidentiality and integrity protection
on an attribute-by-attribute basis. However, non-repudiation is
NOT a requirement for a roaming standard.
4.3. Accounting requirements
Real-time accounting
In today's roaming implementations, real-time accounting is a
practical necessity in order to support fraud detection and risk
management. As a result, a roaming standard MUST provide support
for real-time accounting.
Accounting record formats
Today there is no proposed standard for NAS accounting, and there
is wide variation in the protocols used by providers to
communicate accounting information within their own organizations.
Therefore, a roaming standard MUST prescribe a standardized format
for accounting records. For the sake of efficiency, the record
format MUST be compact.
Extensibility
A standard accounting record format MUST be able to encode metrics
commonly used to determine the user's bill. Since these metrics
change over time, the accounting record format MUST be extensible
so as to be able to add future metrics as they come along. The
record format MUST support both standard metrics as well as
vendor-specific metrics.
5. References
[1] Aboba, B., Lu, J., Alsop, J., Ding, J. and W. Wang, "Review of
Roaming Implementations", RFC 2194, September 1997.
[2] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2138, April
1997.
[3] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[5] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[6] Kent, S. and R. Atkinson, "Security Architecture for the Internet
Protocol", RFC 2401, November 1998.
[7] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication
Protocol (EAP)", RFC 2284, March 1998.
[8] Simpson, W., "PPP Challenge Handshake Authentication Protocol
(CHAP)", RFC 1994, August 1996.
[9] Lloyd, B. and Simpson, W., "PPP Authentication Protocols", RFC
1334, October 1992.
[10] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
1661, July 1994.
6. Security Considerations
This document, being a requirements document, does not have any
security concerns. The security requirements on protocols to be
evaluated using this document are mainly described in section 5.2.
7. Acknowledgements
Thanks to Pat Calhoun (pcalhoun@eng.sun.com), Butch Anton
(butch@ipass.com) and John Vollbrecht (jrv@merit.edu) for many useful
discussions of this problem space.
8. Authors' Addresses
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: 425-936-6605
EMail: bernarda@microsoft.com
Glen Zorn
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: 425-703-1559
EMail: glennz@microsoft.com
9. Full Copyright Statement
Copyright (C) The Internet Society (1999). 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 implementation 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
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet 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 permissions 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 WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
ISO Plain Language
On this page
§1What Roaming Means Here
The memo defines roaming capability as the ability to use multiple Internet service providers while maintaining a formal customer-vendor relationship with only one. In other words, the user has an account with one provider and can also dial in to the others.
Operational roaming services were already providing worldwide roaming capability and growing in popularity, and the memo lists who was interested: regional providers operating within a state or province, wanting to combine their efforts with other regional providers to cover a wider area; national providers wanting to combine with providers in another nation to give coverage across a group of countries or a continent; and businesses wanting to offer employees a comprehensive package of dialup services worldwide, including Internet access and secure access to corporate intranets over a virtual private network.
The document is a set of requirements. It provides an architectural framework for provisioning roaming and describes the requirements that elements of that architecture must meet. The requirements are written to be used in evaluating protocol submissions, so the requirement words describe what a protocol must be able to do, and the protocol documents themselves decide whether a given feature is required, recommended or optional. A submission is not compliant if it fails one or more of the must or must-not requirements for a capability it implements. One that satisfies all the must and must-not requirements but not all the should or should-not requirements is said to be conditionally compliant, and one that satisfies them all is unconditionally compliant.
Roaming means a dial-up customer can sign in to Internet providers other than the one they pay. This memo lists what a roaming protocol has to be able to do, so that proposed protocols can be judged against the same list.
§3The Three Subsystems
The roaming architecture has three major subsystems. The phone book subsystem maintains the user's phone book, which gives the location and phone numbers of the points of presence that are roaming enabled. The authentication subsystem gives authorized users access to those points of presence and denies access to unauthorized users. The accounting subsystem provides information on the resources used during the user's session.
The memo also fixes the vocabulary. The Network Access Server (NAS) is the device clients dial in to to get access to the network. An authentication server provides authentication and authorization within the roaming architecture, and an accounting server provides accounting. Either may be fronted by a proxy: an authentication proxy can forward authentication, implement policy, manage shared secrets and edit attributes, and to the NAS it appears to act as an authentication server while to the authentication server it appears to act as an authentication client. The accounting proxy plays the same double role for accounting, and can also improve reliability, support auditing and offer a pseudo-transactional capability.
One term matters for routing the packets. In order to route authentication and accounting packets, the user name presented to the NAS may contain structure, and that structure is the Network Access Identifier: it is the means by which the proxies work out which authentication or accounting server should receive the request.
The service has three parts: a phone book of access numbers, an authentication part that decides who gets in, and an accounting part that records what was used. Between the user's dial-in server and the provider that owns the account sit proxies, which pass requests along and can adjust them on the way.
- Roaming architecture
- Phone book subsystem Maintains the phone book of roaming-enabled access points.
- Authentication subsystem
- Connection management
- Authentication
- NAS configuration and authorization
- Address assignment and routing
- Security
- Accounting subsystem Records the resources used during the session.
§4.1What the Phone Book Must Do
The phone book subsystem covers four things: phone number presentation, phone number exchange, phone book compilation and phone book update. Only one of them has to be standardised. Presentation, which shows the available numbers and lets the user choose one, depends on the connection management software, so vendors will differ and it need not be standardised. Exchange, the propagation of number changes between providers, need not be standardised at this time because current implementations do not automate it completely. Compilation, turning received updates into a new phone book, does not affect protocol interoperability and need not be standardised. Update, propagating the compiled phone book to users, does have to be standardised, so that providers can update user phone books independently of the client's software or operating system.
The update protocol must work across a range of platforms and operating systems without imposing operating system-specific requirements. The client must be able to determine the authenticity of the server sending the update, and the server may also authenticate the client. The protocol must be able to update from an arbitrary previous version to the latest available version, must let the client determine the integrity of the received update before applying it and of the newly produced phone book afterwards, and must be lightweight because the client may be a low-end machine or an Internet appliance. The mechanism must also support requesting that the phone book be transmitted in a particular language and character set, for example a Russian language phone book.
The phone book format has its own requirements. It must support the phone number attributes commonly used by providers, so that users know the capabilities of the available numbers, plus provider attributes describing the individual members of the roaming consortium and service attributes needed to configure the service. It must support the addition of phone number, provider and service attributes without modification to the update protocol, with registration of new attributes handled by IANA and enough attribute space to accommodate growth. And it must be compact, because the phone book is typically updated often and the format competes for bandwidth.
Most of the phone book work can be left to each provider. The part that has to be the same everywhere is the way an updated phone book reaches the user, so that a provider can update it without caring what software the customer runs. That update has to be small, secure, able to jump from any old version to the newest, and able to carry the book in the customer's own language.
| Phone book function | Does it have to be standardized? |
|---|---|
| Phone number presentation | No. It depends on the connection management software, so vendors will differ. |
| Phone number exchange | Not at this time. Current implementations do not automate it completely. |
| Phone book compilation | No. It does not affect protocol interoperability. |
| Phone book update THIS RFC | Yes, so providers can update phone books independently of client software. |
§4.2Requirements for Authenticating Users
Connection management comes first. Because PPP is so popular and nearly everywhere, a roaming standard must support PPP and IP. It may support other framing protocols such as SLIP, though SLIP support is expected to prove difficult because SLIP does not support negotiation of connection parameters and lacks support for protocols other than IP. Support for non-IP protocols such as IPX or AppleTalk may be provided, since these may be useful for corporate intranet access over the Internet, but because the client will begin PPP negotiation immediately on connection, support for scripting should not be part of a roaming standard.
Identification needs a standardised format for the user ID and the realm presented to the NAS. For verification, a roaming standard must support CHAP and should support EAP, while PAP should not be supported because of security concerns, with a possible exception where PAP is used to support a one-time password or token. Because a roaming standard is likely to be widely deployed on the Internet, it must provide enough scalability to allow roaming associations with thousands of ISP members. It must also be able to incorporate RADIUS-enabled devices within the roaming architecture, which the memo expects to be accomplished with gateways between RADIUS and the roaming protocol.
Proxies in the path make two more demands. To ensure compatibility with the NAS or the local network, authentication and authorization proxies will often add, delete or modify attributes returned by the home authentication server, and will often carry out resource management and policy functions, so a roaming standard must support the ability of proxies to perform attribute editing and implement policy. For addressing, the standard must support dynamic address assignment, and may support static address assignment, most likely via layer 2 or layer 3 tunnelling. It must not preclude the use of layer 2 tunnelling protocols such as PPTP, L2F or L2TP, which hold great promise for implementing virtual private networks, and it must not preclude service providers provisioning Mobile IP Foreign Agents or other Mobile IP functionality.
A roaming protocol must let the customer connect the way dial-up normally works, using PPP and IP, and must prove who they are with CHAP, or better EAP, and not with a plain password. It has to work for groups of providers with thousands of members, and it has to let the proxies in the path adjust the answers they pass on, because that is how local rules get applied.
- MUSTCHAP — A roaming standard must support CHAP.
- SHOULDEAP — A roaming standard should support EAP.
- SHOULD NOTPAP — PAP should not be supported, apart from a one-time password or token.
§4.2.6Security Requirements
A roaming standard must include a thorough security analysis, including a description of security threats and countermeasures, and this must include mechanisms for fraud prevention and detection. It must provide for hop-by-hop integrity protection and confidentiality, which may be accomplished through support of network layer security such as IPSEC.
End-to-end protection is also required, and for a specific reason. Because policy implementation and attribute editing are common in roaming systems, proxies may need to modify packets in transit between a local NAS and the home server. In order to permit authorized modifications while at the same time guarding against attacks by rogue proxies, it is necessary for a roaming standard to support data object security, which means end-to-end confidentiality and integrity protection on an attribute-by-attribute basis. Non-repudiation is explicitly not a requirement for a roaming standard.
The memo notes that, being a requirements document, it has no security concerns of its own; the security requirements it places on the protocols being evaluated are the ones described above.
The protocol has to protect traffic on every hop and must be able to check that each attribute has not been altered. It must also explain how fraud would be prevented and spotted. One thing it does not have to do is prove afterwards who did what: non-repudiation is not required.
§4.3Accounting Requirements
Real-time accounting is a practical necessity in today's roaming implementations, because it is what supports fraud detection and risk management, so a roaming standard must provide support for it.
There is no proposed standard for NAS accounting today, and there is wide variation in the protocols used by providers to communicate accounting information within their own organizations, so a roaming standard must prescribe a standardized format for accounting records. For the sake of efficiency, that record format must be compact.
The record format must also be able to encode the metrics commonly used to determine the user's bill. Since these metrics change over time, the format must be extensible so that future metrics can be added as they come along, and it must support both standard metrics and vendor-specific metrics.
The service has to keep track of what the customer used as it happens, so that fraud can be spotted and stopped. The records need a common shape, they need to be small, and they need room for new charges to be added later.