RFC 8506
Diameter Credit-Control Application
13. Parameters Related to the Credit-Control Application
Tx timer When real-time credit-control is required, the credit-control client contacts the credit-control server before and while the service is provided to an end user. Due to the real-time nature of the application, communication delays SHOULD be minimized, e.g., to avoid an overly long service setup time experienced by the end user. The Tx timer is introduced to control the waiting time in the client in the Pending state. When the Tx timer elapses, the credit-control client takes action for the end user according to the value of the CCFH or the DDFH. The recommended value is 10 seconds. Tcc timer The Tcc timer supervises an ongoing credit-control session in the credit-control server. It is RECOMMENDED to use the Validity-Time as input to set the Tcc timer value. In the case of transient failures in the network, the Diameter Credit-Control server might change to Idle state. To avoid this, the Tcc timer MAY be set so that Tcc is equal to 2 x Validity-Time. Credit-Control-Failure-Handling and Direct-Debiting-Failure-Handling Client implementations may offer the possibility of locally configuring these AVPs. In such a case, their values and behavior are defined in Sections 5.7 and 6.5, respectively.14. Security Considerations
Security considerations regarding the Diameter protocol itself are discussed in [RFC6733]. The use of this application of Diameter MUST take into consideration the security issues and requirements of the base protocol. This application includes a mechanism for application-layer replay protection by means of (1) the Session-Id AVP as specified in [RFC6733] and (2) the CC-Request-Number AVP, which is specified in this document. The Diameter Credit-Control application is often used within one domain, and there may be a single hop between the peers. In these environments, the use of TLS/TCP, DTLS/SCTP (Datagram Transport Layer Security / Stream Control Transmission Protocol), or IPsec is sufficient. The details of security considerations related to TLS/TCP, DTLS/SCTP, and IPsec are discussed in [RFC6733].
Because this application handles monetary transactions (directly or indirectly), it increases interest in various security attacks. Therefore, all parties communicating with each other MUST be authenticated, including, for instance, TLS client-side authentication. In addition, authorization of the client SHOULD be emphasized, i.e., that the client is allowed to perform credit-control for a certain user. The specific means of authorization are outside the scope of this specification but can be, for instance, manual configuration. Another kind of threat is malicious modification, injection, or deletion of AVPs or complete credit-control messages. The credit-control messages contain sensitive billing-related information (such as subscription identifiers, granted units, used units, or cost information) whose malicious modification can have financial consequences. Sometimes simply delaying the credit-control messages can cause disturbances in the credit-control client or server. Even without any modifications to the messages, an adversary that can eavesdrop on transactions can obtain privacy-sensitive information. Also, by monitoring the credit-control messages, one can collect information about the credit-control server's billing models and business relationships. When third-party relays or proxies are involved, hop-by-hop security does not necessarily provide sufficient protection for Diameter user sessions. In some cases, it may be inappropriate to send Diameter messages, such as CCR messages and CCA messages, containing sensitive AVPs via untrusted Diameter proxy agents, as there are no assurances that third-party proxies will not modify the credit-control commands or AVP values.14.1. Direct Connection with Redirects
A Diameter Credit-Control agent cannot always know whether agents between it and the end user's Diameter Credit-Control server are reliable. In this case, the Diameter Credit-Control agent doesn't have a routing entry in its Diameter routing table (defined in [RFC6733], Section 2.7) for the realm of the credit-control server in the end user's home realm. The Diameter Credit-Control agent can have a default route configured to a local redirect agent, and it redirects the CCR message to the redirect agent. The local redirect agent then returns a redirect notification (Result-Code 3006, DIAMETER_REDIRECT_INDICATION) to the credit-control agent, as well as information about the Diameter Credit-Control server(s) (Redirect- Host AVP) and information about how the routing entry resulting from the Redirect-Host is to be used (Redirect-Host-Usage AVP). The Diameter Credit-Control agent then forwards the CCR message directly
to one of the hosts identified by the CCA message from the redirect agent. If the value of the Redirect-Host-Usage AVP does not equal zero, all subsequent messages are sent to the host specified in the Redirect-Host AVP until the time specified by the Redirect-Max-Cache- Time AVP has expired. Even with redirects, there are some authorization issues. There may be attacks toward nodes that have been properly authorized but that abuse their authorization or have been compromised. These issues are discussed more widely in [RFC4072], Section 8.14.2. Application-Level Redirects
This document includes a redirection feature (Section 5.6.2) whereby the service provider can redirect (in an application-specific way) the end user to an alternate location when their credits have expired. This technique is useful in that it allows the user to return to normal service quickly, but it also exposes additional risks and attack surface. In particular, this redirection can potentially occur at an arbitrary point in a user's session, potentially without any additional contextual confirmation available to the user that the redirection is driven by the network. This lack of confirmation matters because, in many application protocols, the communication peer is also capable of inducing redirection. When the peer is an attacker, the redirection can be to an attacker-controlled site. In particular, such sites may be "phishing" sites designed to appear similar to legitimate payment sites in an attempt to obtain users' payment information for fraudulent purposes. When users become accustomed to such redirections, they may have difficulty distinguishing such attacks from legitimate redirections. Because of the potentially harmful consequences of arbitrary redirection by an attacker (such as to phishing sites), it is important for service providers to be aware of that risk and ensure that their users are aware of it as well. Service providers should follow industry best practices for the specific application-layer protocol to reduce the chances that such attacks could be mistaken for legitimate redirections. The details of such a practice are out of scope for this document.
15. Privacy Considerations
As the Diameter protocol, and especially the credit-control application, deal with subscribers and their actions, extra care should be taken regarding the privacy of the subscribers. Per terminology used in [RFC6973], both the credit-control client and the credit-control server are intermediary entities, wherein the subscribers' privacy may be compromised even if no security issues exist, and only authorized entities have access to the privacy- sensitive information.15.1. Privacy-Sensitive AVPs
The privacy-sensitive AVPs listed in this section MUST NOT be sent across non-trusted networks or Diameter agents without end-to-end authentication and confidentiality protection, as described in [RFC6733], Section 13.3. The following AVPs contain privacy-sensitive information at different levels: 1. CC-Correlation-Id AVP: may contain privacy-sensitive information, as the service provider may encode personal information that helps it correlate different subscriptions and access technologies. 2. Check-Balance-Result AVP: contains information on the balance status of the subscriber. 3. Currency-Code AVP: contains information on the subscriber's locale. 4. Cost-Unit AVP: contains privacy-sensitive information for the Cost-Information AVP, in human-readable format. 5. Service-Identifier AVP: may contain privacy-sensitive information about the subscriber's Internet activity. 6. Rating-Group AVP: may contain privacy-sensitive information about the subscriber's Internet activity. 7. Restriction-Filter-Rule AVP: the information inside IPFilterRule may be used to infer services used by the subscriber.
8. Redirect-Server-Address AVP: the service provider might embed
personal information on the subscriber in the URL/URI (e.g., to
create a personalized message). However, the service provider
may instead anonymize the subscriber's identity in the URL/URI
and let the redirect server query the information directly.
Such anonymized information must not allow personal information
or the subscriber's identity to be easily guessed. Furthermore,
the service provider should treat the URL/URI schema itself as
confidential and make sure it cannot be inferred (1) from
observation of the traffic or (2) due to its trivial structure.
A trivial structure could allow an adversary to query/modify
personal information even without knowing the subscriber's
identity. Similar AVPs are Redirect-Address-URL and Redirect-
Address-SIP-URI.
9. Service-Context-Id AVP: depending on how the service provider
uses it, it may contain privacy-sensitive information about the
service (e.g., in a 3GPP network Service-Context-Id AVP, it has
a different value for packet switching, SMS, Multimedia Messages
(MMSs), etc.).
10. Service-Parameter-Info AVP: depending on how the service
provider uses it, it may contain privacy-sensitive information
about the subscriber (e.g., location).
11. Subscription-Id-Data AVP: contains the identity of the
subscriber. Similar AVPs are Subscription-Id-E164,
Subscription-Id-IMSI, Subscription-Id-SIP-URI, Subscription-Id-
NAI, and Subscription-Id-Private.
12. User-Equipment-Info-Value AVP: contains the identity of the
device of the subscriber. Similar AVPs are User-Equipment-Info-
IMEISV, User-Equipment-Info-MAC, User-Equipment-Info-EUI64,
User-Equipment-Info-ModifiedEUI64, and User-Equipment-Info-IMEI.
13. QoS-Final-Unit-Indication AVP: Grouped AVP that may contain
privacy-sensitive information in its sub-AVPs (e.g.,
IPFilterRule, redirect address).
Note that some AVPs that are used in this document are defined in
[RFC6733] and may contain privacy-sensitive information. These AVPs
are not listed above.
15.2. Data Minimization
Due to the nature of the credit-control application, some personal data and identity information must be stored in both the credit-control client and the credit-control server. However, this could be minimized by following these guidelines: 1. Data stored in the credit-control client does not need to persist across sessions. All data could be deleted once the session ends and could be reconstructed once a new session is initialized. Note that while the credit-control server is usually owned by the service provider with which the subscriber already has some direct legal or business relationship (where the privacy level could be agreed upon), this is not always true for a credit-control client that may be owned by a third party. 2. Some information about the subscriber has to be stored in persistent storage in the credit-control server (e.g., identity, balance); however, per-transaction information does not have to be stored in persistent storage, and per-session information may be deleted from persistent storage once the session ends. 3. In some cases, per-transaction information has to be stored on the credit-control server, client, or both, for regulatory, auditability, or debugging reasons. However, this could be minimized by following these guidelines: A. Data retention does not need to exceed the required duration. B. Transaction information could be aggregated in some cases (e.g., prefer information per session over information per rating-group; prefer hourly byte summary over per-transaction byte counts). C. If not strictly needed, information that is more sensitive (e.g., location, equipment type) could be filtered out of such logs. This information is often used to make rating decisions, and in this case, the rating decisions should be logged instead of the data used to make them. D. Due to the reasons explained in the first guideline, the credit-control server, rather than the credit-control client, would be the preferred location for storing such transaction information.
15.3. Diameter Agents
Diameter agents, as described in [RFC6733], may be owned by third parties. If end-to-end security is supported between the credit-control client and the credit-control server, the operator can use it to encrypt privacy-sensitive AVPs (as listed in Section 15.1) and prevent such information from leaking into the agent. In some cases, the Diameter agent needs access to privacy-sensitive AVPs, in order to make correct routing decisions or even to modify the content of these AVPs. For example, a proxy agent may need to look at the Subscription-Id-IMSI AVP, in order to extract the mobile country and network codes of the user and use them to look up the destination to which the request should be routed (see Section 2.8.2 in [RFC6733]). In such a case, the credit-control client and credit-control server may use a mechanism that anonymizes the identity of the subscriber, as well as a mechanism to encrypt other AVPs not used by the agent.16. References
16.1. Normative References
[CE164] International Telecommunication Union, "COMPLEMENT TO ITU-T RECOMMENDATION E.164 (11/2010): LIST OF ITU-T RECOMMENDATION E.164 ASSIGNED COUNTRY CODES", November 2011, <https://www.itu.int/dms_pub/itu-t/opb/sp/ T-SP-E.164D-11-2011-PDF-E.pdf>. [CE212] International Telecommunication Union, "COMPLEMENT TO RECOMMENDATION ITU-T E.212 (09/2016): LIST OF MOBILE COUNTRY OR GEOGRAPHICAL AREA CODES", February 2017, <https://www.itu.int/dms_pub/itu-t/opb/sp/ T-SP-E.212A-2017-PDF-E.pdf>. [E164] International Telecommunication Union, "The international public telecommunication numbering plan", ITU-T Recommendation E.164, November 2010, <https://www.itu.int/rec/T-REC-E.164/>. [E212] International Telecommunication Union, "The international identification plan for public networks and subscriptions", ITU-T Recommendation E.212, September 2016, <https://www.itu.int/rec/T-REC-E.212/en>.
[EUI64] IEEE, "Guidelines for Use of Extended Unique Identifier (EUI), Organizationally Unique Identifier (OUI), and Company ID (CID)", August 2017, <https://standards.ieee.org/content/dam/ ieee-standards/standards/web/documents/tutorials/eui.pdf>. [ISO4217] ISO, "Codes for the representation of currencies", ISO 4217:2015, 2015, <https://www.iso.org/ iso-4217-currency-codes.html>. [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <https://www.rfc-editor.org/info/rfc791>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>. [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and Accounting (AAA) Transport Profile", RFC 3539, DOI 10.17487/RFC3539, June 2003, <https://www.rfc-editor.org/info/rfc3539>. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>. [RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. Loughney, "Diameter Credit-Control Application", RFC 4006, DOI 10.17487/RFC4006, August 2005, <https://www.rfc-editor.org/info/rfc4006>. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M., Ed., and A. Lior, "Traffic Classification and Quality of Service (QoS) Attributes for Diameter", RFC 5777, DOI 10.17487/RFC5777, February 2010, <https://www.rfc-editor.org/info/rfc5777>. [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, DOI 10.17487/RFC5952, August 2010, <https://www.rfc-editor.org/info/rfc5952>. [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, Ed., "Diameter Base Protocol", RFC 6733, DOI 10.17487/RFC6733, October 2012, <https://www.rfc-editor.org/info/rfc6733>. [RFC7155] Zorn, G., Ed., "Diameter Network Access Server Application", RFC 7155, DOI 10.17487/RFC7155, April 2014, <https://www.rfc-editor.org/info/rfc7155>. [RFC7423] Morand, L., Ed., Fajardo, V., and H. Tschofenig, "Diameter Applications Design Guidelines", BCP 193, RFC 7423, DOI 10.17487/RFC7423, November 2014, <https://www.rfc-editor.org/info/rfc7423>. [RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, DOI 10.17487/RFC7542, May 2015, <https://www.rfc-editor.org/info/rfc7542>. [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. [TGPPIMEI] 3rd Generation Partnership Project, Technical Specification Group Core Network, "Numbering, addressing and identification (release 15)", 3GPP TS 23.003 version 15.6.0, December 2018.
16.2. Informative References
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, DOI 10.17487/RFC2866, June 2000, <https://www.rfc-editor.org/info/rfc2866>. [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines", RFC 3580, DOI 10.17487/RFC3580, September 2003, <https://www.rfc-editor.org/info/rfc3580>. [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, DOI 10.17487/RFC3725, April 2004, <https://www.rfc-editor.org/info/rfc3725>. [RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., Ed., and P. McCann, "Diameter Mobile IPv4 Application", RFC 4004, DOI 10.17487/RFC4004, August 2005, <https://www.rfc-editor.org/info/rfc4004>. [RFC4072] Eronen, P., Ed., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, DOI 10.17487/RFC4072, August 2005, <https://www.rfc-editor.org/info/rfc4072>. [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-editor.org/info/rfc6973>. [TGPPCHARG] 3rd Generation Partnership Project, Technical Specification Group Services and System Aspects, "Service aspects; Charging and Billing", 3GPP TS 22.115 version 15.5.0, September 2018.
(next page on part 9)
