Subject: [Dime] Eric Rescorla's No Objection on draft-ietf-dime-rfc4006bis-08: (with COMMENT)

From: Eric Rescorla <[email-masked]>
Date: Wed, 23 May 2018 20:41:08 -0700

Eric Rescorla has entered the following ballot position for
draft-ietf-dime-rfc4006bis-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4006bis/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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?

---

From: Yuval Lifshitz <[email-masked]>
Date: Thu, 24 May 2018 06:33:13 +0000 (UTC)

inline
    On Thursday, May 24, 2018, 6:41:17 a.m. GMT+3, Eric Rescorla <[email-masked]> wrote:  

COMMENTS
S 1.2.

[yuval] base spec define "home realm" we should probably change to that

S 2.

[yuval] base spec defined "local realm" for that. will fix

S 3.1.

[yuval] it is in the base spec

S 4.

[yuval] not sure what is not clear?

S 14.

[yuval] will clarify. see here: https://github.com/lbertz02/rfc4006bis/issues/51

_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 24 May 2018 06:17:24 -0700

On Wed, May 23, 2018 at 11:33 PM, Yuval Lifshitz <[email-masked]> wrote:

> *inline*
> *[yuval] base spec define "home realm" we should probably change to that*
>
> S 2.
> *[yuval] base spec defined "local realm" for that. will fix*
>
> S 3.1.
> >                                  [ CC-Correlation-Id ]
> >                                  [ User-Equipment-Info ]
> *[yuval] it is in the base spec*
>

I'm sure it is, but you should still expand it.

> *[yuval] not sure what is not clear?*
>

As I said above, do you return the balance or do you return the amount of
credit that has been reserved.

> *[yuval] will clarify. see here: *https://github.com/
> lbertz02/rfc4006bis/issues/51
>

This doesn't seem dramatically clearer. What sort of an adversary can do
that?

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 24 May 2018 06:58:03 -0700

On Thu, May 24, 2018 at 6:53 AM, Yuval Lifshitz <[email-masked]> wrote:

> more inline
>
> On Thursday, May 24, 2018, 4:18:06 p.m. GMT+3, Eric Rescorla <[email-masked]>
> wrote:
>
>
>
>
> Please refer to https://www.ietf.org/iesg/ statement/discuss-criteria.
> html <https://www.ietf.org/iesg/statement/discuss-criteria.html>
> https://datatracker.ietf.org/ doc/draft-ietf-dime- rfc4006bis/
> <https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4006bis/>
>
>
>
> ------------------------------ ------------------------------ ----------
> COMMENT:
> ------------------------------ ------------------------------ ----------
>
> https://mozphab-ietf. devsvcdev.mozaws.net/D3353
> <https://mozphab-ietf.devsvcdev.mozaws.net/D3353>
>
>
> [yuval] sure we can (it would be a bit awkward though, in the world of
> "Diameter" it will be like explaining what TCP stands for...)
>

https://tools.ietf.org/rfcmarkup?doc=7322#section-3.6

S 4.
> [yuval] return the reserved amount
>

OK, the text should say it.

-Ekr

> <https://github.com/lbertz02/rfc4006bis/issues/51>
>
>
> [yuval] in some cases e2e security is not possible, this is what this
> section is addressing, the github issue is to clarify that
>
> -Ekr
>
>
>
>
>
>
> ______________________________ _________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/ listinfo/dime
> <https://www.ietf.org/mailman/listinfo/dime>
>
>
>

---

From: Yuval Lifshitz <[email-masked]>
Date: Thu, 24 May 2018 13:53:07 +0000 (UTC)

more inline
    On Thursday, May 24, 2018, 4:18:06 p.m. GMT+3, Eric Rescorla <[email-masked]> wrote:  

 inline

Please refer to https://www.ietf.org/iesg/ statement/discuss-criteria. html
for more information about IESG DISCUSS and COMMENT positions.

COMMENTS
S 1.2.

S 2.

S 3.1.

I'm sure it is, but you should still expand it. 
[yuval] sure we can (it would be a bit awkward though, in the world of "Diameter" it will be like explaining what TCP stands for...)

S 4.

As I said above, do you return the balance or do you return the amount of credit that has been reserved.
[yuval] return the reserved amount

S 14.

[yuval] will clarify. see here: https://github.com/ lbertz02/rfc4006bis/issues/51

This doesn't seem dramatically clearer. What sort of an adversary can do that?
[yuval] in some cases e2e security is not possible, this is what this section is addressing, the github issue is to clarify that

-Ekr

---

From: Yuval Lifshitz <[email-masked]>
Date: Thu, 24 May 2018 14:12:20 +0000 (UTC)

inline
    On Thursday, May 24, 2018, 4:58:44 p.m. GMT+3, Eric Rescorla <[email-masked]> wrote:  

 more inline

 inline

COMMENTS
S 1.2.

S 2.

S 3.1.

https://tools.ietf.org/rfcmarkup?doc=7322#section-3.6
[yuval] in the list, but not marked as "well known". OTOH, that document gives some freedom to the RFC editor. Given that the first couple of occurrences of AVP in the spec are in titles and inside ABNF, there isn't a reasonable place to expand that. If someone tries to read any Diameter application spec, without the base one they would probably run into other issues as well

S 4.

OK, the text should say it.
[yuval] ok. will rephrase

-Ekr

S 14.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 24 May 2018 07:26:06 -0700

On Thu, May 24, 2018 at 7:12 AM, Yuval Lifshitz <[email-masked]> wrote:

> *[yuval] in the list, but not marked as "well known". OTOH, that document
> gives some freedom to the RFC editor. Given that the first couple of
> occurrences of AVP in the spec are in titles and inside ABNF, there isn't a
> reasonable place to expand that. If someone tries to read any Diameter
> application spec, without the base one they would probably run into other
> issues as well*
>

 Put it in the glossary at the start.

-Ekr

> *[yuval] ok. will rephrase*
>
> -Ekr
>
>
>
>
>
> S 14.
> >

---

From: Yuval Lifshitz <[email-masked]>
Date: Thu, 24 May 2018 14:37:18 +0000 (UTC)

ok. will add AVP to section 1.2
    On Thursday, May 24, 2018, 5:26:47 p.m. GMT+3, Eric Rescorla <[email-masked]> wrote:  

 inline

 more inline

 inline

COMMENTS
S 1.2.

S 2.

S 3.1.

https://tools.ietf.org/ rfcmarkup?doc=7322#section-3.6
[yuval] in the list, but not marked as "well known". OTOH, that document gives some freedom to the RFC editor. Given that the first couple of occurrences of AVP in the spec are in titles and inside ABNF, there isn't a reasonable place to expand that. If someone tries to read any Diameter application spec, without the base one they would probably run into other issues as well

S 4.

-Ekr

S 14.

-Ekr

---

From: Ben Campbell <[email-masked]>
Date: Thu, 24 May 2018 13:57:11 -0500

> On May 24, 2018, at 8:58 AM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> introductory paragraph, however..)
> 
> 
> >      in the user's home domain..  In some cases it might be possible that

> https://tools.ietf.org/rfcmarkup?doc=7322#section-3.6

Ekr is correct, the Diameter usage of AVP is not marked as “sufficiently well-known to not need to expand” in the abbreviation registry. Not to mention, many people in the real-time media community will also think of it as “audio-visual profile"