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: Ben Campbell [mailto:[e-mail]]
> Sent: Tuesday, May 22, 2018 10:02 PM
> To: Bertz, Lyle T [CTO] <[e-mail]>
> Cc: Alissa Cooper <[e-mail]>; The IESG <[e-mail]>; dime-
> [e-mail]; [e-mail]; [e-mail]
> 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 :-)
>
> > On May 22, 2018, at 9:21 PM, Bertz, Lyle T [CTO] <[e-mail]>
> wrote:
> >
> > 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]; draft-ietf-dime-
> [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.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
> > 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%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
> >
> >
> >
> > ----------------------------------------------------------------------
> > 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.”
>
> 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?
>

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.

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

>
> >
> > ----------------------------------------------------------------------
> > 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.
>
> How about “mobile networks”?

We are fine with that.

>
> >
> > (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
>
> Please assume there will be another revision  :-)

:D

>
> >
> > = 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.
>
> Assuming Alissa is okay with the explanations for both points, please add
> some explanatory text to the section.
>

Yes

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

> > _______________________________________________
> > DiME mailing list
> > [e-mail]
> >
> 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.
> >
> > _______________________________________________
> > DiME mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dime


________________________________

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.