Diameter Credit-Control Application
draft-ietf-dime-rfc4006bis-12

Thanks for Joel for his OpsDir review - I looked at the diffs between 4006 and this, and am balloting based on that.
Helpful link for other ADs: http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://www.ietf.org/id/draft-ietf-dime-rfc4006bis-08.txt&url2=https://tools.ietf.org/rfc/rfc4006.txt

Thanks to the authors and other participants who helped with this revision of
the credit-control application. Thanks in particular for the addition of an
extensive privacy considerations section.

I will note that I only reviewed the diffs between this document and RFC 4006.

I have a handful of comments.

---------------------------------------------------------------------------

General nit:

This document uses the term "service specific" as a compound adjective in
several places. As a compound adjective, this should be hyphenated (i.e.,
"service-specific").

---------------------------------------------------------------------------

§1.1:

This document uses lowercase forms of RFC-2119-defined terms. Please update this
section to use the boilerplate from RFC 8174.

---------------------------------------------------------------------------

§5.1.2:

>  If independent credit-control of multiple services is used, the
>  Validity-Time AVP and Final-Unit-Indication AVP or QoS-Final-Unit-
>  Indication AVP SHOULD be present either in the Multiple-Services-
>  Credit-Control AVP(s) or at command level as single AVPs.

The phrasing here is ambiguous -- it's not clear whether the requirement is:

  (Validity-Time and Final-Unit-Indication) or QoS-Final-Unit-Indication

... or ...

  Validity-Time and (Final-Unit-Indication or QoS-Final-Unit-Indication)

I suspect it's the latter, in which case I suggest:

   If independent credit-control of multiple services is used, the
   Validity-Time AVP, and either the Final-Unit-Indication AVP or
   the QoS-Final-Unit-Indication AVP, SHOULD be present either in the
   Multiple-Services- Credit-Control AVP(s) or at command level as single
   AVPs.

---------------------------------------------------------------------------

§5.2.1:

The alignment of the "Diameter AAA Server" title on Figure 3 has changed from
RFC 4006 in a way that looks worse.

---------------------------------------------------------------------------

§5.6.2:

>  The credit-control
>  client receives a Credit-Control-Answer or service specific
>  authorization answer with the Final-Unit-Indication or the QoS-Final-
>  Unit-Indication AVP and Validity-Time AVPs but no Granted-Service-
>  Unit AVP.

This has the same confusion as above regarding the application of logical
combinations. The second half of the statement is of the form "A or B and C
but not D," which is pretty ambiguous. It's also a little unclear whether the
client receives a Credit-Control-Answer (with A or B and C but not D), or just
a Credit-Control-Answer of any description, full stop.

---------------------------------------------------------------------------

§8.19

>  Note: The values reported in a Used-Service-Unit AVP does not
>  necessarily have a relation to the grant provided in a Granted-
>  Service-Unit AVP, e.g., the value in this AVP may exceed the value in
>  the grant.

Nit: "...values reported in a Used-Service-Unit AVP do not..."
                                                    ^^

(or "...value... does not...")

---------------------------------------------------------------------------

§8.54:

>  The User-Equipment-Info-MAC (AVP Code TBD3) is of type OctetString.
>  The User-Equipment-Info-MAC AVP contains the 48-bit MAC address is
>  formatted as described in [RFC3580].

Nit: remove "is" after "address".

---------------------------------------------------------------------------

§8.65:

>  The Redirect-Address-IPAddress AVP (AVP Code TBD14) is of type
>  Address and defines the IPv4 or IPv6 address of the redirect server
>  with which the end user is to be connected when the account cannot
>  cover the service cost.

This appears to be underspecified, unless I've missed some specification
elsewhere regarding what the client is supposed to do with this IP address.
While the other redirection methods (HTTP, SIP) have relatively clear means of
contact (they indicate a protocol), the indication of only an IP address with
neither protocol nor port doesn't seem to provide enough information for a
client to act on.  Please either flesh this out in this section, or point to
another document that indicates how this IP address is to be used.

---------------------------------------------------------------------------

§12:

When new documents obsolete an RFC that originally registered values with IANA,
I'm used to seeing that document also update the IANA registry so that the
corresponding entries now point to the new document. You may consider text that
instructs IANA to update the existing RFC-4006-registered values so that they
point to this document instead of RFC 4006.

---------------------------------------------------------------------------

Appendix B:

As a general comment for all of the examples: I'm surprised that none of the
examples have been updated to reflect the newly defined capabilities in this
document. For example, all the examples in this appendix use
Final-Unit-Indication rather than QoS-Final-Unit-Indication. In practice, to
show maximally flexible and compatible examples, I would expect that the
examples would include both AVPs. This applies to all of the "Extension"
AVPs as well.

---------------------------------------------------------------------------

Appendix B.2:

>  control server.  Therefore, in this example, it is assumed that the
>  SIP Proxy adds a Record-Route header in the initial SIP INVITE

"...a Record-Route header field..."

(A SIP header is everything before the first blank line; individual lines within
a SIP header are called "header fields")

I only scanned the document, so I only have one minor question/comment:

In Section 8.39: Redirect-Server-Address looks underspecified to me. It says "address". Is it a well known DIAMETER term? What is the syntax of address? Is it a URI or something else?

Thanks for addressing my DISCUSS.

Original COMMENT:

= Section 1 =

(1) I know it's a term of art, but the term "next generation wireless networks" seems a bit out of place in two ways: (1) "wireless" seems more generic than what is implied (i.e., "cellular," I assume), and (2) is Rel-13 considered "next generation" still?

(2) "Diameter base protocol" should cite RFC 6733.

= Section 5.1 =

Assuming G-S-U stands for granted service unit, the acronym should be given upon first use here.

= Section 8.52 =

(1) Why do you need to specify the ability to send either the IMEISV or the IMEI?


(2)
"If the type of the equipment is one of the
   enumerated types of User-Equipment-Info-Type AVP, then the credit-
   control client SHOULD send the information in the User-Equipment-Info
   AVP, in addition to or instead of the User-Equipment-Info-Extension
   AVP."

Why is this normative recommendation in support of backwards compatibility different from the one given for the Subscription-Id-Extension AVP in Sec. 8.58?

= Section 15.1 =

"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)."
    
This seems like a bad idea that, if it's going to be mentioned, should be recommended against.

Thank you for addressing my DISCUSS points.  Original ballot comments preserved below:

Some additional significant but not necessarily DISCUSS-worthy
comments, followed by more editorial- and nit-level things.

In Section 1.3, "Advertising Application Support" uses the same
Auth-Application-ID value as for RFC 4006; what are the interop
consequences of this?

Alissa already noted that the text about how to split (sub-)AVPs
between the foo and foo-Extension AVPs is inconsistent among them --
e.g., Redirect-Server-Extension and User-Equipment-Info say "SHOULD
send [in the old one]", but Subscription-Id-Extension has separate
text about "[i]f full backward compatibility with [RFC4006] is
required" and slightly different behavior described.  We should try
to catch all instances of this sort of backwards compatibility and
make them consistent.

The use of UTF8String for URLs and URIs (e.g., Redirect-Address-URL)
might benefit from additional text about the expected contents.  A
lot of the time when we use a UTF8 container for names (whether
domain names or other kinds), we specify what normalization form and
canonicalization are performed, whether domain names are A-labels or
U-labels, etc., as there's a lot of potential flexibility not all of
which is good.  In this case, since the communication is only
between trusted actors, perhaps the additional restrictions are not
needed, but I am curious if the topic was raised in the WG.

Thank you for adding the Privacy Considerations and list of
Privacy-Sensitive AVPs!

Section 14

   [...] 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 or IPsec is sufficient.

I did not see any concrete guidance on what would suffice in other
environments (with multiple hops between peers).  Is this the realm
of the mythical "end-to-end security mechanism" for Diameter that is
much-desired?  (The last paragraph does have guidance on what might
*not* suffice, which is not exactly the same thing.)

   Even without any modification to the messages, an adversary can
   eavesdrop on transactions that contain privacy-sensitive information
   about the user.

This ("an adversary can") makes it sounds as if there is no
confidentiality protection anywhere in the system, but that's what
TLS/DTLS/IPSec are supposed to provide.  So maybe "an adversary that
can eavesdrop on transactions can obtain privacy-sensitive
information [...]" is better.

(Editorial- and nit-level stuff follows.)

Section 4

   A flexible credit-control application specific failure handling is
   defined in which the home service provider can model the credit-
   control client behavior according to its own credit risk management
   policy.

This sentence is hard to parse -- in "credit-control application
specific" what does "specific" bind to?  What is being modelled?  Is
anything being controlled (as opposed to modelled)?

Section 4.1.1

   2.  The Service-Parameter-Info AVP MAY be used as a container to pass
   legacy rating information in its original encoded form (e.g., ASN.1
   BER).  [...]

Why BER and not DER?  The unnecessary flexibility in BER vs. DER has
been known to tickle parser bugs and create security
vulnerabilities.

Section 4.1.2

   [...] To
   facilitate interoperability, it is RECOMMENDED that the rating input
   and the values of the Service-Context-Id be coordinated via an
   informational RFC or other permanent and readily available reference.
   The specification of another cooperative standardization body (e.g.,
   3GPP, OMA, or 3GPP2) SHOULD be used.

The RECOMMENDED and SHOULD seem slightly in conflict.

Section 5.1.1

As noted elsewhere, 60 seconds per minute does not always hold; it
seems that this text could be reworded to just talk about a
"constant rate" or "constant level per fixed time period" or
similar.

Section 5.1.2

   [...]
   timer (Section 13) every time a CCR message with the value
   UPDATE_REQUEST is sent while they are in PendingU state.  When
   answers to all pending messages are received, the state machine moves
   to OPEN state, and Tx is stopped.

Transmission, or the Tx timer (is stopped)?

Using a different title for Section 5.2.2 might make the parallel
between it and Section 5.2.1 more clear.  That is, perhaps something
like "First Interrogation Included with Authorization Messages".

Section 5.7

   [...] It is RECOMMENDED that the client complement the credit-
   control failure procedures with backup accounting flow toward an
   accounting server. [...]

Nit: it looks like there's a missing article here, maybe "a backup
accounting flow" is better.

   The AAA transport profile [RFC3539] defines the application layer
   watchdog algorithm that enables failover from a peer that has failed
   and is controlled by a watchdog timer (Tw) defined in [RFC3539].

Nit: Is it "the" watchdog algorithm or "an" watchdog algorithm?

Section 6.2

Should there be text indicating how the client indicates what
service the balance check is being requested for?

Section 8.54

Maybe give a section reference in RFC 3580 for how the formatting is
done?

Section 12

   [...] Initially, such Expert discussions take place on the AAA
   WG mailing list.

That list appears to be dead, suggesting that this text should be
updated.  (I also agree with Adam's comments about updating the IANA Considerations.)

Why is the disclaimer in Section B.4 (and other examples) not needed in Section B.3?

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3353


I only gave this a light read. Some minor comments below.

COMMENTS
S 1.2.
>         deduction of credit from the end user account when service is
>         completed and refunding of reserved credit that is not used.
>   
>      Diameter Credit-control Server  A Diameter credit-control server acts
>         as a prepaid server, performing real-time rating and credit-
>         control.  It is located in the home domain and is accessed by

a definition of "home domain" would be useful


S 2.
>      credit-control application.
>   
>      When an end user requests services such as SIP or messaging, the
>      request is typically forwarded to a service element (e.g., SIP Proxy)
>      in the user's home domain.  In some cases it might be possible that
>      the service element in the visited domain can offer services to the

also define visited domain, or at least point to a reference.


S 3.1.
>                                   [ CC-Correlation-Id ]
>                                   [ User-Equipment-Info ]
>                                   [ User-Equipment-Info-Extension ]
>                                  *[ Proxy-Info ]
>                                  *[ Route-Record ]
>                                  *[ AVP ]

Please expand AVP on first use.


S 4.
>      control client requests credit authorization from the credit-control
>      server prior to allowing any service to be delivered to the end user.
>   
>      In the first model, the credit-control server rates the request,
>      reserves a suitable amount of money from the user's account, and
>      returns the corresponding amount of credit resources.  Note that

Sorry, reserves the balance or the amount reserved?


S 14.
>   
>      Even without any modification to the messages, an adversary can
>      eavesdrop on transactions that contain privacy-sensitive information
>      about the user.  Also, by monitoring the credit-control messages one
>      can collect information about the credit-control server's billing
>      models and business relationships.

I'm having trouble reading these two paragraphs. Are they about what
happens if TLS isn't used?

Thanks for addressing my DISCUSS point.

Section 8.65

Any reason you are allowing encoding an IPv4 address as a IPv4-Mapped IPv6 Address while you can directly use address family 1 to encode it directly as an IPv4 address? This allows for two different encodings for the same address.