Tech-invite   3GPPspecs   Glossaries   IETFRFCs   Groups   SIP   ABNFs   Ti+   Search in Tech-invite

in Index   Prev   Next
in Index   Prev   Next  Group: DIME

RFC 8506

Diameter Credit-Control Application

Pages: 130
Proposed STD
Obsoletes:  4006
Part 8 of 9 – Pages 101 to 110
First   Prev   Next

Top   ToC   RFC8506 - Page 101   prevText
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].
Top   ToC   RFC8506 - Page 102
   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
Top   ToC   RFC8506 - Page 103
   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.
Top   ToC   RFC8506 - Page 104
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.
Top   ToC   RFC8506 - Page 105
   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.
Top   ToC   RFC8506 - Page 106
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.
Top   ToC   RFC8506 - Page 107
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>.
Top   ToC   RFC8506 - Page 108
   [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>.
Top   ToC   RFC8506 - Page 109
   [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.
Top   ToC   RFC8506 - Page 110
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 Section