[Dime] Alissa Cooper's Discuss on draft-ietf-dime-rfc4006bis-08: (with DISCUSS and COMMENT)

[Alissa Cooper <[e-mail]>]

Alissa Cooper has entered the following ballot position for
draft-ietf-dime-rfc4006bis-08: Discuss

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/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

= Section 5.6.2 =

I'm having a little trouble understanding the expected behavior described in
Section 5.6.2 so wanted to see if I'm just confused or if there is something to
be clarified. The text says:

"In addition to the Redirect-Server AVP or Redirect-Server-Extension
   AVP, the credit-control server MAY include one or more Restriction-
   Filter-Rule AVPs, one or more Filter-Rule AVPs, or one or more
   Filter-Id AVPs in the Credit-Control-Answer message to enable the
   user to access other services (for example, zero-rated services).  In
   such a case, the access device MUST drop all the packets not matching
   the IP filters specified in the Restriction-Filter-Rule AVPs, Filter-
   Rule AVPs or Filter-Id AVPs.  If enforcement actions other than
   allowing the packets (e.g., QoS), are indicated in the Filter-Rule
   AVPs or Filter-Id AVPs, they SHOULD be performed as well.  In
   addition, if possible, to redirecting the user to the destination
   specified in the Redirect-Server AVP or Redirect-Server-Extension
   AVP."

It seems like if the server sends a Redirect-Server AVP or
Redirect-Server-Extension AVP without any of the other AVPs, then all the
traffic is supposed to be redirected. But if a Restriction-Filter-Rule AVP,
Filter-Rule AVP, or Filter-Id AVP is also included, then the non-matching
traffic MUST be dropped, in which case how does the user get redirected? Is the
last sentence (which is a sentence fragment, actually) supposed to address this
somehow? And in the case of enforcement actions involving QoS, the text seems
to say that packets matching the filter MUST be dropped AND have the QoS rules
applied to them, so I don't understand how that works.

= Section 15.1 =

RFC 6733 lists a bunch of sensitive AVPs and then says this about them:

"Diameter messages containing these or any other AVPs considered to be
   security-sensitive MUST only be sent protected via mutually
   authenticated TLS or IPsec.  In addition, those messages MUST NOT be
   sent via intermediate nodes unless there is end-to-end security
   between the originator and recipient or the originator has locally
   trusted configuration that indicates that end-to-end security is not
   needed."

It seems like the list of AVPs in Section 15.1 should have these same
requirements applied to them explicitly.


----------------------------------------------------------------------
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.