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

["Bertz, Lyle T [CTO]" <[e-mail]>]

Comments inline.

-----Original Message-----
From: DiME [mailto:[e-mail]] On Behalf Of Alissa Cooper
Sent: Tuesday, May 22, 2018 6:08 AM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: [Dime] Alissa Cooper's Discuss on draft-ietf-dime-rfc4006bis-08: (with DISCUSS and COMMENT)

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.


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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html&data=02%7C01%7Clyle.t.bertz%40sprint.com%7Ca619c2ae255a4e3db64f08d5bfd44063%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C0%7C636625840688755751&sdata=TSuSzLz5Ey2TL45eg2TDQf%2BVQXBei6cxbVz5tU%2FtlRo%3D&reserved=0
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-dime-rfc4006bis%2F&data=02%7C01%7Clyle.t.bertz%40sprint.com%7Ca619c2ae255a4e3db64f08d5bfd44063%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C0%7C636625840688755751&sdata=rOjsjxdmG7IcUDzAuDhvkB9cCOopAv70yPHCckL%2B9SA%3D&reserved=0



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

> The statement "In such a case, the access device MUST drop all the packets not matching the IP filters specified in the Restriction-Filter-Rule AVPs" and is redundant with the definition of Restriction-Filter-Rule.  Filter-Rule and the rule referred to by Filter-Id also contain the appropriate traffic filter and actions. I would propose a simplification, replace all text from "In such a case ..." with

"In such a case, the access device MUST treat all packets according to the Restriction-Filter-Rule AVPs, Filter-Rules AVPs and the rules referred to by the Filter-Id AVP.  This is in addition to, if possible, redirecting the user to the destination specified in the Redirect-Server AVP or Redirect-Server-Extension AVP."

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

> 6733 is clear about what applies when declared as security sensitive but the addition of the following may help.

"As sensitive AVPs the Diameter message requirements specified in Section 13.3 of RFC 6733 apply."

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

> Fair point.   We tend to use "wireless" though as opposed to "cellular".  Dropping 'next generation' makes sense.

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

> If the DISCUSS can be resolved and we have a next revision (I assume we will) we can update this

= Section 5.1 =

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

> Can update in next revision along with the DISCUSS items

= Section 8.52 =

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

>  They are distinct structures and the latest generation of networks are starting to use IMEISV (with no support for just the IMEI).  However, the IMEI value is identical.

(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?

> It was found that backwards compatibility issues were more prevalent with User-Equipment-Info around the IMEISV and some implementations can deal with IMEISV and IMEI. The language above is aggressive in recommending the "in addition to" in order to maximize compatibility.  8.58 is cleaner in terms of its recommendation and production issues have not been seen on this AVP so it seemed appropriate to limit the AVP values to one or the other and not both as it is for User-Equipment-Info and User-Equipment-Info-Extension.

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

> Makes sense.  I would recommend add the sentence "However, this is not recommended."
_______________________________________________
DiME mailing list
[e-mail]
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdime&data=02%7C01%7Clyle.t.bertz%40sprint.com%7Ca619c2ae255a4e3db64f08d5bfd44063%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C0%7C636625840688755751&sdata=q3LE6zquhvAVJ%2B6rJzlqfep80r3JZrX5wgoASHwii%2BQ%3D&reserved=0

________________________________

This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.