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

From: Alissa Cooper <[email-masked]>
Date: Tue, 22 May 2018 04:07:39 -0700

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.

---

From: "Bertz, Lyle T [CTO]" <[email-masked]>
Date: Wed, 23 May 2018 02:21:30 +0000

Comments inline.

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Alissa Cooper
Sent: Tuesday, May 22, 2018 6:08 AM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
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.

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

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

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

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

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

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

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 =

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
[email-masked]
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.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 22 May 2018 22:01:44 -0500

Hi,

I’m having some trouble telling your comments from Alissa’s. Somehow the quoting is reversed from normal convention, so it looks like Alissa is quoting you. But I will try to figure it out :-)

> On May 22, 2018, at 9:21 PM, Bertz, Lyle T [CTO] <[email-masked]> wrote:
> 
> Comments inline.
> 
> "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.”

I think Alissa’s point is to ask how redirection and filtering interact when both are active. Does _remaining_ traffic gets redirected after applying the filter? Note that some forms of redirection (e.g. HTTP) may not work very well if only some traffic makes it.

I also have to wonder if some of this behavior is really governed by local policy at the NAS?

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

I was going to say something similar; 6733 is the base protocol. This draft inherits the normative rules by way of using Diameter. But it doesn’t hurt to reinforce them more strongly descriptive language. How about something to the effect of ” The privacy-sensitive AVPs listed in this section must be sent across non-trusted networks or Diameter agents without end-to-end authentication and confidentiality protection, as described in [RFC6733] section 13.3"

How about “mobile networks”?

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

Please assume there will be another revision  :-)

>> 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 aggres…

Assuming Alissa is okay with the explanations for both points, please add some explanatory text to the section.

>> Makes sense.  I would recommend add the sentence "However, this is not recommended.”

It’s also commonly done, isn’t it? I think the point is to mention that the AVP is sensitive because people might do this, not to offer permission. There’s already text recommending against directly using personal information. Would it help to change “may” to “might”? to avoid any semblance of “permission”?

Some of the other AVPs likely carried in the same message are going to have personally identifiable information one way or another (i.e. Subscription-ID).

> https://www.ietf.org/mailman/listinfo/dime

---

From: "Bertz, Lyle T [CTO]" <[email-masked]>
Date: Wed, 23 May 2018 12:29:41 +0000

Comments inline.

> From: Ben Campbell [mailto:[email-masked]]
> Sent: Tuesday, May 22, 2018 10:02 PM
> To: Bertz, Lyle T [CTO] <[email-masked]>
> Cc: Alissa Cooper <[email-masked]>; The IESG <[email-masked]>; dime-
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Dime] Alissa Cooper's Discuss on draft-ietf-dime-rfc4006bis-08:
> (with DISCUSS and COMMENT)
>
> Hi,
>
> I’m having some trouble telling your comments from Alissa’s. Somehow the
> quoting is reversed from normal convention, so it looks like Alissa is quoting
> you. But I will try to figure it out :-)
>
> > 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.
> >
> >
> > 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.i
> etf.org%2Fiesg%2Fstatement%2Fdiscuss-
> criteria.html&data=02%7C01%7Clyle.t.bertz%40sprint.com%7Ca619c2ae255a
> 4e3db64f08d5bfd44063%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C0%
> 7C636625840688755751&sdata=TSuSzLz5Ey2TL45eg2TDQf%2BVQXBei6cxbVz5
> tU%2FtlRo%3D&reserved=0
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatr
> acker.ietf.org%2Fdoc%2Fdraft-ietf-dime-
> rfc4006bis%2F&data=02%7C01%7Clyle.t.bertz%40sprint.com%7Ca619c2ae255
> a4e3db64f08d5bfd44063%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C0
> %7C636625840688755751&sdata=rOjsjxdmG7IcUDzAuDhvkB9cCOopAv70yPH
> CckL%2B9SA%3D&reserved=0
> >
> >
> >
> > 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:
> >
> > 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.”
>
> I think Alissa’s point is to ask how redirection and filtering interact when both
> are active. Does _remaining_ traffic gets redirected after applying the filter?
> Note that some forms of redirection (e.g. HTTP) may not work very well if
> only some traffic makes it.
>

The rules are always enforced prior to redirection on the NAS.

To your point, the policy *could* govern local behavior of redirect in the rule but in general this is poor practice, e.g. what if two rules with the same precedence redirect to different locations for overlapping traffic and a Redirect-Server-Extension AVP is present?  This would definitely be poor design on their part.  Users of the Redirect-Server and Redirect-Server-Extension AVP align the rules with the redirect use case.

> I was going to say something similar; 6733 is the base protocol. This draft
> inherits the normative rules by way of using Diameter. But it doesn’t hurt to
> reinforce them more strongly descriptive language. How about something to
> the effect of ” The privacy-sensitive AVPs listed in this section must be sent
> across non-trusted networks or Diameter agents without end-to-end
> authentication and confidentiality protection, as described in [RFC6733]
> section 13.3"
>

Perfect! We will fix.

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

We are fine with that.

> Please assume there will be another revision  :-)

:D

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

Yes

> It’s also commonly done, isn’t it? I think the point is to mention that the AVP
> is sensitive because people might do this, not to offer permission. There’s
> already text recommending against directly using personal information.
> Would it help to change “may” to “might”? to avoid any semblance of
> “permission”?
>
> Some of the other AVPs likely carried in the same message are going to have
> personally identifiable information one way or another (i.e. Subscription-ID).
>

If "might" works for everyone we'll make the change.

> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
> etf.org%2Fmailman%2Flistinfo%2Fdime&data=02%7C01%7Clyle.t.bertz%40s
> print.com%7Ca619c2ae255a4e3db64f08d5bfd44063%7C4f8bc0acbd784bf5b55
> f1b31301d9adf%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.
> >

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 23 May 2018 11:07:50 -0400

> On May 23, 2018, at 8:29 AM, Bertz, Lyle T [CTO] <[email-masked]> wrote:
> 
> Comments inline.
> 

Yes, this is what I think is not clear in the original or in the suggested replacement text.

>> authentication and confidentiality protection, as described in [RFC6733]

Assuming you meant s/must/MUST NOT/ this seems fine.

>> How about “mobile networks”?

WFM

>> some explanatory text to the section.

WFM

>> personally identifiable information one way or another (i.e. Subscription-ID).

What I was thinking was more that this potentially makes the URLs guessable in such a way that attackers accessing them could obtain personal information about any subscriber whose name they know. Is that not a concern?

Thanks,
Alissa

---

From: Ben Campbell <[email-masked]>
Date: Wed, 23 May 2018 10:43:20 -0500

> On May 23, 2018, at 10:07 AM, Alissa Cooper <[email-masked]> wrote:
> 
>>>> 
>>>> = Section 15.1 =
>>>> 

That’s a very good point. Would it help to add some guidance to make these hard to guess along with the existing text about not adding user identifying information?

Ben.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 23 May 2018 10:46:33 -0500

> That’s a very good point. Would it help to add some guidance to make these hard to guess along with the existing text about not adding user identifying information?

That seems worth doing.

Thanks,

Benjamin