draft-ietf-dime-rfc4006bis-06.txt   draft-ietf-dime-rfc4006bis-07.txt 
Network Working Group L. Bertz, Ed. Network Working Group L. Bertz, Ed.
Internet-Draft Sprint Internet-Draft Sprint
Obsoletes: 4006 (if approved) D. Dolson, Ed. Obsoletes: 4006 (if approved) D. Dolson, Ed.
Intended status: Standards Track Y. Lifshitz, Ed. Intended status: Standards Track Y. Lifshitz, Ed.
Expires: July 6, 2018 Sandvine Expires: September 21, 2018 Sandvine
January 2, 2018 March 20, 2018
Diameter Credit-Control Application Diameter Credit-Control Application
draft-ietf-dime-rfc4006bis-06 draft-ietf-dime-rfc4006bis-07
Abstract Abstract
This document specifies a Diameter application that can be used to This document specifies a Diameter application that can be used to
implement real-time credit-control for a variety of end user services implement real-time credit-control for a variety of end user services
such as network access, Session Initiation Protocol (SIP) services, such as network access, Session Initiation Protocol (SIP) services,
messaging services, and download services. The Diameter Credit- messaging services, and download services. The Diameter Credit-
Control application as defined in this document obsoletes RFC4006, Control application as defined in this document obsoletes RFC4006,
and it must be supported by all new Diameter Credit-Control and it must be supported by all new Diameter Credit-Control
Application implementations. Application implementations.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 6, 2018. This Internet-Draft will expire on September 21, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 5, line 16 skipping to change at page 5, line 16
12.12. Final-Unit-Action AVP . . . . . . . . . . . . . . . . . 95 12.12. Final-Unit-Action AVP . . . . . . . . . . . . . . . . . 95
12.13. Multiple-Services-Indicator AVP . . . . . . . . . . . . 95 12.13. Multiple-Services-Indicator AVP . . . . . . . . . . . . 95
12.14. Redirect-Address-Type AVP . . . . . . . . . . . . . . . 96 12.14. Redirect-Address-Type AVP . . . . . . . . . . . . . . . 96
12.15. Requested-Action AVP . . . . . . . . . . . . . . . . . . 96 12.15. Requested-Action AVP . . . . . . . . . . . . . . . . . . 96
12.16. Subscription-Id-Type AVP . . . . . . . . . . . . . . . . 96 12.16. Subscription-Id-Type AVP . . . . . . . . . . . . . . . . 96
12.17. Tariff-Change-Usage AVP . . . . . . . . . . . . . . . . 96 12.17. Tariff-Change-Usage AVP . . . . . . . . . . . . . . . . 96
12.18. User-Equipment-Info-Type AVP . . . . . . . . . . . . . . 96 12.18. User-Equipment-Info-Type AVP . . . . . . . . . . . . . . 96
13. Credit-Control Application Related Parameters . . . . . . . . 96 13. Credit-Control Application Related Parameters . . . . . . . . 96
14. Security Considerations . . . . . . . . . . . . . . . . . . . 97 14. Security Considerations . . . . . . . . . . . . . . . . . . . 97
14.1. Direct Connection with Redirects . . . . . . . . . . . . 98 14.1. Direct Connection with Redirects . . . . . . . . . . . . 98
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 99 15. Privacy Considerations . . . . . . . . . . . . . . . . . . . 99
15.1. Normative References . . . . . . . . . . . . . . . . . . 99 15.1. Privacy Sensitive AVPs . . . . . . . . . . . . . . . . . 99
15.2. Informative References . . . . . . . . . . . . . . . . . 101 15.2. Data Minimization . . . . . . . . . . . . . . . . . . . 100
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 102 15.3. Diameter Agents . . . . . . . . . . . . . . . . . . . . 101
Appendix B. Credit-Control Sequences . . . . . . . . . . . . . . 102 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 102
B.1. Flow I . . . . . . . . . . . . . . . . . . . . . . . . . 102 16.1. Normative References . . . . . . . . . . . . . . . . . . 102
B.2. Flow II . . . . . . . . . . . . . . . . . . . . . . . . . 105 16.2. Informative References . . . . . . . . . . . . . . . . . 104
B.3. Flow III . . . . . . . . . . . . . . . . . . . . . . . . 107 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 105
B.4. Flow IV . . . . . . . . . . . . . . . . . . . . . . . . . 107 Appendix B. Credit-Control Sequences . . . . . . . . . . . . . . 105
B.5. Flow V . . . . . . . . . . . . . . . . . . . . . . . . . 109 B.1. Flow I . . . . . . . . . . . . . . . . . . . . . . . . . 105
B.6. Flow VI . . . . . . . . . . . . . . . . . . . . . . . . . 110 B.2. Flow II . . . . . . . . . . . . . . . . . . . . . . . . . 108
B.7. Flow VII . . . . . . . . . . . . . . . . . . . . . . . . 111 B.3. Flow III . . . . . . . . . . . . . . . . . . . . . . . . 110
B.8. Flow VIII . . . . . . . . . . . . . . . . . . . . . . . . 113 B.4. Flow IV . . . . . . . . . . . . . . . . . . . . . . . . . 110
B.9. Flow IX . . . . . . . . . . . . . . . . . . . . . . . . . 115 B.5. Flow V . . . . . . . . . . . . . . . . . . . . . . . . . 112
Appendix C. Changes relative to RFC4006 . . . . . . . . . . . . 120 B.6. Flow VI . . . . . . . . . . . . . . . . . . . . . . . . . 113
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 121 B.7. Flow VII . . . . . . . . . . . . . . . . . . . . . . . . 114
B.8. Flow VIII . . . . . . . . . . . . . . . . . . . . . . . . 116
B.9. Flow IX . . . . . . . . . . . . . . . . . . . . . . . . . 118
Appendix C. Changes relative to RFC4006 . . . . . . . . . . . . 123
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 124
1. Introduction 1. Introduction
This document specifies a Diameter application that can be used to This document specifies a Diameter application that can be used to
implement real-time credit-control for a variety of end user services implement real-time credit-control for a variety of end user services
such as network access, Session Initiation Protocol (SIP) services, such as network access, Session Initiation Protocol (SIP) services,
messaging services, and download services. It provides a general messaging services, and download services. It provides a general
solution to real-time cost and credit-control. solution to real-time cost and credit-control.
The prepaid model has been shown to be very successful, for instance, The prepaid model has been shown to be very successful, for instance,
skipping to change at page 13, line 4 skipping to change at page 13, line 4
this specification supports two different credit authorization this specification supports two different credit authorization
models: credit authorization with money reservation and credit models: credit authorization with money reservation and credit
authorization with direct debiting. In both models, the credit- authorization with direct debiting. In both models, the credit-
control client requests credit authorization from the credit-control control client requests credit authorization from the credit-control
server prior to allowing any service to be delivered to the end user. server prior to allowing any service to be delivered to the end user.
In the first model, the credit-control server rates the request, In the first model, the credit-control server rates the request,
reserves a suitable amount of money from the user's account, and reserves a suitable amount of money from the user's account, and
returns the corresponding amount of credit resources. Note that returns the corresponding amount of credit resources. Note that
credit resources may not imply actual monetary credit; credit credit resources may not imply actual monetary credit; credit
resources may be granted to the credit control client in the form of resources may be granted to the credit-control client in the form of
units (e.g., data volume or time) to be metered. units (e.g., data volume or time) to be metered.
Upon receipt of a successful credit authorization answer with a Upon receipt of a successful credit authorization answer with a
certain amount of credit resources, the credit-control client allows certain amount of credit resources, the credit-control client allows
service delivery to the end user and starts monitoring the usage of service delivery to the end user and starts monitoring the usage of
the granted resources. When the credit resources granted to the user the granted resources. When the credit resources granted to the user
have been consumed or the service has been successfully delivered or have been consumed or the service has been successfully delivered or
terminated, the credit-control client reports back to the server the terminated, the credit-control client reports back to the server the
used amount. The credit-control server deducts the used amount from used amount. The credit-control server deducts the used amount from
the end user's account; it may perform rating and make a new credit the end user's account; it may perform rating and make a new credit
reservation if the service delivery is continuing. This process is reservation if the service delivery is continuing. This process is
accomplished with session based credit-control that includes the accomplished with session based credit-control that includes the
first interrogation, possible intermediate interrogations, and the first interrogation, possible intermediate interrogations, and the
final interrogation. For session based credit-control, both the final interrogation. For session based credit-control, both the
credit control client and the credit-control server are required to credit-control client and the credit-control server are required to
maintain credit-control session state. Session based credit-control maintain credit-control session state. Session based credit-control
is described in more detail, with more variations, in Section 5. is described in more detail, with more variations, in Section 5.
In contrast, credit authorization with direct debiting is a single In contrast, credit authorization with direct debiting is a single
transaction process wherein the credit-control server directly transaction process wherein the credit-control server directly
deducts a suitable amount of money from the user's account as soon as deducts a suitable amount of money from the user's account as soon as
the credit authorization request is received. Upon receipt of a the credit authorization request is received. Upon receipt of a
successful credit authorization answer, the credit-control client successful credit authorization answer, the credit-control client
allows service delivery to the end user. This process is allows service delivery to the end user. This process is
accomplished with the one-time event. Session state is not accomplished with the one-time event. Session state is not
skipping to change at page 32, line 17 skipping to change at page 32, line 17
authorization for a credit pool, the server includes in the RAR authorization for a credit pool, the server includes in the RAR
message the G-S-U-Pool-Identifier AVP indicating the affected pool. message the G-S-U-Pool-Identifier AVP indicating the affected pool.
To request credit re-authorization for a service or a rating-group, To request credit re-authorization for a service or a rating-group,
the server includes in the RAR message the Service-Identifier AVP or the server includes in the RAR message the Service-Identifier AVP or
the Rating-Group AVP, respectively. To request credit re- the Rating-Group AVP, respectively. To request credit re-
authorization for all the ongoing services within the (sub-)session, authorization for all the ongoing services within the (sub-)session,
the server includes none of the above mentioned AVPs in the RAR the server includes none of the above mentioned AVPs in the RAR
message. message.
If a credit re-authorization is not already ongoing (i.e., the If a credit re-authorization is not already ongoing (i.e., the
credit-control session is in Open state), a credit control client credit-control session is in Open state), a credit-control client
that receives an RAR message with Session-Id equal to a currently that receives an RAR message with Session-Id equal to a currently
active credit-control session MUST acknowledge the request by sending active credit-control session MUST acknowledge the request by sending
the Re-Auth-Answer (RAA) message and MUST initiate the credit re- the Re-Auth-Answer (RAA) message and MUST initiate the credit re-
authorization toward the server by sending a Credit-Control-Request authorization toward the server by sending a Credit-Control-Request
message with the CC-Request-Type AVP set to the value UPDATE_REQUEST. message with the CC-Request-Type AVP set to the value UPDATE_REQUEST.
The Result-Code 2002 (DIAMETER_LIMITED_SUCCESS) SHOULD be used in the The Result-Code 2002 (DIAMETER_LIMITED_SUCCESS) SHOULD be used in the
RAA message to indicate that an additional message (i.e., CCR message RAA message to indicate that an additional message (i.e., CCR message
with the value UPDATE_REQUEST) is required to complete the procedure. with the value UPDATE_REQUEST) is required to complete the procedure.
If a quota was allocated to the service, the credit-control client If a quota was allocated to the service, the credit-control client
MUST report the used quota in the Credit-Control-Request. Note that MUST report the used quota in the Credit-Control-Request. Note that
skipping to change at page 39, line 22 skipping to change at page 39, line 22
identified by the Filter-Id AVP(s). The credit-control server SHOULD identified by the Filter-Id AVP(s). The credit-control server SHOULD
include either the Restriction-Filter-Rule AVP or the Filter-Id AVP include either the Restriction-Filter-Rule AVP or the Filter-Id AVP
in the Final-Unit-Indication group AVP of the Credit-Control-Answer in the Final-Unit-Indication group AVP of the Credit-Control-Answer
message. message.
A QoS-Final-Unit-Indication AVP with the Final-Unit-Action A QoS-Final-Unit-Indication AVP with the Final-Unit-Action
RESTRICT_ACCESS indicates to the device supporting this action that, RESTRICT_ACCESS indicates to the device supporting this action that,
upon consumption of the final granted units, the actions specified in upon consumption of the final granted units, the actions specified in
Filter-Rule AVP(s) MUST restrict the traffic according to the Filter-Rule AVP(s) MUST restrict the traffic according to the
classifiers in the Filter-Rule AVP(s). If Filter-Id AVP(s) are classifiers in the Filter-Rule AVP(s). If Filter-Id AVP(s) are
provided in the Credit-Control-Answer message, the credit control provided in the Credit-Control-Answer message, the credit-control
client MUST restrict the traffic according to the IP packet filters client MUST restrict the traffic according to the IP packet filters
identified by the Filter-Id AVP(s). The credit-control server SHOULD identified by the Filter-Id AVP(s). The credit-control server SHOULD
include either the Filter-Rule AVP or the Filter-Id AVP in the QoS- include either the Filter-Rule AVP or the Filter-Id AVP in the QoS-
Final-Unit-Indication group AVP of the Credit-Control-Answer message. Final-Unit-Indication group AVP of the Credit-Control-Answer message.
If both Final-Unit-Indication AVP and QoS-Final-Unit-Indication AVP If both Final-Unit-Indication AVP and QoS-Final-Unit-Indication AVP
exist in the Credit-Control-Answer message, a credit control client exist in the Credit-Control-Answer message, a credit-control client
which supports the QoS-Final-Unit-Indication AVP SHOULD follow the which supports the QoS-Final-Unit-Indication AVP SHOULD follow the
directives included in the QoS-Final-Unit-Indication AVP and SHOULD directives included in the QoS-Final-Unit-Indication AVP and SHOULD
ignore the Final-Unit-Indication AVP. ignore the Final-Unit-Indication AVP.
An entity other than the credit-control server may provision the An entity other than the credit-control server may provision the
access device with appropriate IP packet filters to be used in access device with appropriate IP packet filters to be used in
conjunction with the Diameter credit-control application. Such an conjunction with the Diameter credit-control application. Such an
entity may, for instance, configure the access device with IP flows entity may, for instance, configure the access device with IP flows
to be passed when the Diameter credit-control application indicates to be passed when the Diameter credit-control application indicates
RESTRICT_ACCESS or REDIRECT. The access device passes IP packets RESTRICT_ACCESS or REDIRECT. The access device passes IP packets
skipping to change at page 60, line 36 skipping to change at page 60, line 36
8.3. CC-Request-Type AVP 8.3. CC-Request-Type AVP
The CC-Request-Type AVP (AVP Code 416) is of type Enumerated and The CC-Request-Type AVP (AVP Code 416) is of type Enumerated and
contains the reason for sending the credit-control request message. contains the reason for sending the credit-control request message.
It MUST be present in all Credit-Control-Request messages. The It MUST be present in all Credit-Control-Request messages. The
following values are defined for the CC-Request-Type AVP: following values are defined for the CC-Request-Type AVP:
INITIAL_REQUEST 1 INITIAL_REQUEST 1
An Initial request is used to initiate a credit-control session, and An Initial request is used to initiate a credit-control session, and
contains credit control information that is relevant to the contains credit-control information that is relevant to the
initiation. initiation.
UPDATE_REQUEST 2 UPDATE_REQUEST 2
An Update request contains credit-control information for an existing An Update request contains credit-control information for an existing
credit-control session. Update credit-control requests SHOULD be credit-control session. Update credit-control requests SHOULD be
sent every time a credit-control re-authorization is needed at the sent every time a credit-control re-authorization is needed at the
expiry of the allocated quota or validity time. Further, additional expiry of the allocated quota or validity time. Further, additional
service-specific events MAY trigger a spontaneous Update request. service-specific events MAY trigger a spontaneous Update request.
skipping to change at page 74, line 22 skipping to change at page 74, line 22
If the Final-Unit-Action AVP is set to REDIRECT and the type of If the Final-Unit-Action AVP is set to REDIRECT and the type of
server is not one of the enumerations in the Redirect-Address-Type server is not one of the enumerations in the Redirect-Address-Type
AVP, then the QoS-Final-Unit-Indication AVP SHOULD be used together AVP, then the QoS-Final-Unit-Indication AVP SHOULD be used together
with the Redirect-Server-Extension AVP instead of the Final-Unit- with the Redirect-Server-Extension AVP instead of the Final-Unit-
Indication AVP. Indication AVP.
If the Final-Unit-Action AVP is set to RESTRICT_ACCESS or REDIRECT If the Final-Unit-Action AVP is set to RESTRICT_ACCESS or REDIRECT
and the classification of the restricted traffic cannot be expressed and the classification of the restricted traffic cannot be expressed
using IPFilterRule, or different actions (e.g., QoS) than just using IPFilterRule, or different actions (e.g., QoS) than just
allowing QoS needs to be enforced traffic, then the QoS-Final-Unit- allowing traffic needs to be enforced, then the QoS-Final-Unit-
Indication AVP SHOULD be used instead of the Final-Unit-Indication Indication AVP SHOULD be used instead of the Final-Unit-Indication
AVP. However, if the credit control server wants to preserve AVP. However, if the credit-control server wants to preserve
backward compatibility with credit-control clients that support only backward compatibility with credit-control clients that support only
[RFC4006], the Final-Unit-Indication AVP SHOULD be used together with [RFC4006], the Final-Unit-Indication AVP SHOULD be used together with
the Filter-Id AVP. the Filter-Id AVP.
The Final-Unit-Indication AVP is defined as follows (per the grouped- The Final-Unit-Indication AVP is defined as follows (per the grouped-
avp-def of [RFC6733]): avp-def of [RFC6733]):
Final-Unit-Indication ::= < AVP Header: 430 > Final-Unit-Indication ::= < AVP Header: 430 >
{ Final-Unit-Action } { Final-Unit-Action }
*[ Restriction-Filter-Rule ] *[ Restriction-Filter-Rule ]
skipping to change at page 91, line 14 skipping to change at page 91, line 14
translations between RADIUS and the Diameter credit-control translations between RADIUS and the Diameter credit-control
application is beyond the scope of this specification and SHOULD be application is beyond the scope of this specification and SHOULD be
addressed in another appropriate document, such as the RADIUS prepaid addressed in another appropriate document, such as the RADIUS prepaid
specification. specification.
The Diameter credit-control architecture may have a Translation Agent The Diameter credit-control architecture may have a Translation Agent
capable of translation between RADIUS prepaid and Diameter credit- capable of translation between RADIUS prepaid and Diameter credit-
control protocols. An AAA server (usually the home AAA server) may control protocols. An AAA server (usually the home AAA server) may
act as a Translation Agent and as a Diameter credit-control client act as a Translation Agent and as a Diameter credit-control client
for service elements that use credit-control mechanisms other than for service elements that use credit-control mechanisms other than
Diameter credit control for instance, RADIUS prepaid. In this case, Diameter credit-control for instance, RADIUS prepaid. In this case,
the home AAA server contacts the Diameter credit-control server as the home AAA server contacts the Diameter credit-control server as
part of the authorization process. The interworking architecture is part of the authorization process. The interworking architecture is
illustrated Figure 9, and interworking flow in Figure 10. In a illustrated Figure 9, and interworking flow in Figure 10. In a
roaming situation the service element (e.g., the NAS) may be located roaming situation the service element (e.g., the NAS) may be located
in the visited network, and a visited AAA server is usually in the visited network, and a visited AAA server is usually
contacted. The visited AAA server connects then to the home AAA contacted. The visited AAA server connects then to the home AAA
server. server.
RADIUS Prepaid RADIUS Prepaid
+--------+ +---------+ protocol +------------+ +--------+ +--------+ +---------+ protocol +------------+ +--------+
skipping to change at page 98, line 16 skipping to change at page 98, line 16
Another kind of threat is malicious modification, injection, or Another kind of threat is malicious modification, injection, or
deletion of AVPs or complete credit-control messages. The credit- deletion of AVPs or complete credit-control messages. The credit-
control messages contain sensitive billing related information (such control messages contain sensitive billing related information (such
as subscription Id, granted units, used units, cost information) as subscription Id, granted units, used units, cost information)
whose malicious modification can have financial consequences. whose malicious modification can have financial consequences.
Sometimes simply delaying the credit-control messages can cause Sometimes simply delaying the credit-control messages can cause
disturbances in the credit-control client or server. disturbances in the credit-control client or server.
Even without any modification to the messages, an adversary can Even without any modification to the messages, an adversary can
invite a security threat by eavesdropping, as the transactions eavesdrop on transactions that contain privacy-sensitive information
contain private information about the user. Also, by monitoring the about the user. Also, by monitoring the credit-control messages one
credit-control messages one can collect information about the credit- can collect information about the credit-control server's billing
control server's billing models and business relationships. models and business relationships.
When third-party relays or proxy are involved, the hop-by-hop When third-party relays or proxy are involved, the hop-by-hop
security does not necessarily provide sufficient protection for security does not necessarily provide sufficient protection for
Diameter user session. In some cases, it may be inappropriate to Diameter user session. In some cases, it may be inappropriate to
send Diameter messages, such as CCR and CCA, containing sensitive send Diameter messages, such as CCR and CCA, containing sensitive
AVPs via untrusted Diameter proxy agents, as there are no assurances AVPs via untrusted Diameter proxy agents, as there are no assurances
that third-party proxies will not modify the credit-control commands that third-party proxies will not modify the credit-control commands
or AVP values. or AVP values.
14.1. Direct Connection with Redirects 14.1. Direct Connection with Redirects
skipping to change at page 99, line 10 skipping to change at page 99, line 10
value of the Redirect-Host-Usage AVP is unequal to zero, all value of the Redirect-Host-Usage AVP is unequal to zero, all
following messages are sent to the host specified in the Redirect- following messages are sent to the host specified in the Redirect-
Host AVP until the time specified by the Redirect-Max-Cache-Time AVP Host AVP until the time specified by the Redirect-Max-Cache-Time AVP
is expired. is expired.
There are some authorization issues even with redirects. There may There are some authorization issues even with redirects. There may
be attacks toward nodes that have been properly authorized, but that be attacks toward nodes that have been properly authorized, but that
abuse their authorization or have been compromised. These issues are abuse their authorization or have been compromised. These issues are
discussed more widely in [RFC4072], Section 8. discussed more widely in [RFC4072], Section 8.
15. References 15. Privacy Considerations
15.1. Normative References As the Diameter protocol, and especially credit-control application,
deals with subscribers and their actions, extra care should be taken
regarding the privacy of the subscribers. In terms of [RFC6973],
both the credit-control client and 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 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, as a
human readable format of the Cost-Information AVP.
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 may embed
personal information on the subscriber in the URL/I (e.g. to
create a personalized message). However, the service-provider
may anonymise the subscriber's identity instead in the URL/I,
and let the redirect server query the information directly.
Similar AVPs are: Redirect-Address-URL, Redirect-Address-SIP-
URI.
9. Service-Context-Id AVP: depending with 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 has a
different value for: Packet Switching, SMS and MMS etc.)
10. Service-Parameter-Info AVP: depending with 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, 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, User-Equipment-Info-IMEI.
13. QoS-Final-Unit-Indication AVP: grouped AVP which may contains
privacy-sensitive information in its sub-AVPs (e.g IPFilterRule,
redirect address).
Note that some AVPs which 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 credit-control
client and credit-control server. This, however, could be minimized
by following these guidelines:
1. Data stored in the credit-control client does not need to be
persisted across sessions. All data could be deleted once the
session end, and 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 privacy level could
be agreed upon), this is not always true for the 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 sessions over information per
rating-group; prefer hourly byte summary over per transaction
byte counts.
C. If not strictly needed, the more sensitive information (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 decision should be logged instead of
the data used to make them.
D. Due to the reasons explained in 1, the credit-control server
would be a preferred location for storing such transaction
information, instead of the credit-control client
15.3. Diameter Agents
Diameter agents, as described in [RFC6733], may be owned by third-
parties. If end-to-end security is supported between credit-control
client and 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 into privacy-sensitive
AVPs, in order to take correct routing decisions, or even modify the
content of these AVPs. For example, a proxy agent may need to look
into the Subscription-Id-IMSI AVP, in order to extract the mobile
country and network codes of the user, and use them to lookup 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] "Complement to ITU-T Recommendation E.164 (05/1997):"List [CE164] "Complement to ITU-T Recommendation E.164 (05/1997):"List
of ITU-T Recommendation E.164 assigned country codes"", of ITU-T Recommendation E.164 assigned country codes"",
June 2000. June 2000.
[CE212] "Complement to ITU-T Recommendation E.212 (11/1997):" List [CE212] "Complement to ITU-T Recommendation E.212 (11/1997):" List
of mobile country or geographical area codes"", February of mobile country or geographical area codes"", February
1999. 1999.
[E164] "Recommendation E.164/I.331 (05/97): The International [E164] "Recommendation E.164/I.331 (05/97): The International
skipping to change at page 101, line 16 skipping to change at page 104, line 11
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[TGPPIMEI] [TGPPIMEI]
3rd Generation Partnership Project, "Technical 3rd Generation Partnership Project, "Technical
Specification Group Core Network, Numbering, addressing Specification Group Core Network, Numbering, addressing
and identification, (release 13), 3GPP TS 23.003 v. and identification, (release 13), 3GPP TS 23.003 v.
13.5.0", 2016-04. 13.5.0", 2016-04.
15.2. Informative References 16.2. Informative References
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866,
DOI 10.17487/RFC2866, June 2000, DOI 10.17487/RFC2866, June 2000,
<https://www.rfc-editor.org/info/rfc2866>. <https://www.rfc-editor.org/info/rfc2866>.
[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese,
"IEEE 802.1X Remote Authentication Dial In User Service "IEEE 802.1X Remote Authentication Dial In User Service
(RADIUS) Usage Guidelines", RFC 3580, (RADIUS) Usage Guidelines", RFC 3580,
DOI 10.17487/RFC3580, September 2003, DOI 10.17487/RFC3580, September 2003,
<https://www.rfc-editor.org/info/rfc3580>. <https://www.rfc-editor.org/info/rfc3580>.
skipping to change at page 101, line 44 skipping to change at page 104, line 39
[RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., Ed., [RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., Ed.,
and P. McCann, "Diameter Mobile IPv4 Application", and P. McCann, "Diameter Mobile IPv4 Application",
RFC 4004, DOI 10.17487/RFC4004, August 2005, RFC 4004, DOI 10.17487/RFC4004, August 2005,
<https://www.rfc-editor.org/info/rfc4004>. <https://www.rfc-editor.org/info/rfc4004>.
[RFC4072] Eronen, P., Ed., Hiller, T., and G. Zorn, "Diameter [RFC4072] Eronen, P., Ed., Hiller, T., and G. Zorn, "Diameter
Extensible Authentication Protocol (EAP) Application", Extensible Authentication Protocol (EAP) Application",
RFC 4072, DOI 10.17487/RFC4072, August 2005, RFC 4072, DOI 10.17487/RFC4072, August 2005,
<https://www.rfc-editor.org/info/rfc4072>. <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] [TGPPCHARG]
3rd Generation Partnership Project, "Technical 3rd Generation Partnership Project, "Technical
Specification Group Services and System Aspects, Service Specification Group Services and System Aspects, Service
aspects; Charging and Billing, (release 13), 3GPP TS aspects; Charging and Billing, (release 13), 3GPP TS
22.115 v. 13.3.0", 2016-03. 22.115 v. 13.3.0", 2016-03.
Appendix A. Acknowledgements Appendix A. Acknowledgements
The original authors of RFC4006 are: Harri Hakala, Leena Mattila, The original authors of RFC4006 are: Harri Hakala, Leena Mattila,
Juha-Pekka Koskinen, Marco Stura, and John Loughney. Juha-Pekka Koskinen, Marco Stura, and John Loughney.
skipping to change at page 121, line 36 skipping to change at page 124, line 36
Add extensible Redirect-Server-Extension AVP and included types Add extensible Redirect-Server-Extension AVP and included types
(from Section 8.64 to Section 8.67). (from Section 8.64 to Section 8.67).
Add extensible QoS-Final-Unit-Indication AVP (in Section 8.68). Add extensible QoS-Final-Unit-Indication AVP (in Section 8.68).
Updated Security Section to include language consistent with Updated Security Section to include language consistent with
structures of latest base protocol specification. structures of latest base protocol specification.
Update references to obsolete RFC 5226 to refer to RFC 8126, and Update references to obsolete RFC 5226 to refer to RFC 8126, and
resulting updateds to Section 12. resulting updates to Section 12.
Add section on Privacy Considerations.
Authors' Addresses Authors' Addresses
Lyle Bertz (editor) Lyle Bertz (editor)
Sprint Sprint
6220 Sprint Parkway 6220 Sprint Parkway
Overland Park, KS 66251 Overland Park, KS 66251
United States United States
Email: lyleb551144@gmail.com Email: lyleb551144@gmail.com
David Dolson (editor) David Dolson (editor)
Sandvine Sandvine
408 Albert Street 408 Albert Street
Waterloo, ON N2L 3V3 Waterloo, ON N2L 3V3
Canada Canada
Phone: +1 519 880 2400 Email: ddolson@acm.org
Email: ddolson@sandvine.com
Yuval Lifshitz (editor) Yuval Lifshitz (editor)
Sandvine Sandvine
408 Albert Street 408 Albert Street
Waterloo, ON N2L 3V3 Waterloo, ON N2L 3V3
Canada Canada
Phone: +1 519 880 2400 Email: yuvalif@yahoo.com
Email: ylifshitz@sandvine.com
 End of changes. 21 change blocks. 
39 lines changed or deleted 187 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/