Re: [Dime] draft-avasarala-diameter-error-invalid-identity-00

["AVASARALA, RANJIT KUMAR" <[e-mail]>]

Hi Lyle

Answers inline <Ranjit>

Regards
Ranjit
VoLTE T4 Support
317-224-9441



From: Bertz, Lyle T [CTO] [mailto:[e-mail]]
Sent: Tuesday, October 31, 2017 1:46 PM
To: AVASARALA, RANJIT KUMAR <[e-mail]>; Yuval Lifshitz <[e-mail]>; [e-mail]
Subject: RE: draft-avasarala-diameter-error-invalid-identity-00

A few questions:


  1.  How did a CTF get and invalid IMEI?  It is typically pulling from somewhere else.
<Ranjit>  invalid iMEI can come from devices reporting invalid IMEI value.  This IMEI value comes from device to MME to PGW and all the way to IMS core.

  1.  When you say invalid in the spec you reference format.  If it is format that is doable but if it is questioning data / associations outside of the AVP or message then this is problematic.   An invalid value in the proposal is too vague. Was it a well formed AVP which did not pass some app level semantic check or was it just bad data?
<Ranjit> by invalid, I mean the data is invalid E.g. the IMEI should be 15 digits long and should follow the rules defined in RFC 7254/7255.  So the CCF that receives the IMEI should validate the IMEI (which the CCFs currently do not) and once they do, and if they determine that the IMEI is invalid, then they should insert the error code into Diameter response (E.g. CCA).

  1.  Is this a IMSI-IMEI(SV) association issue?
<Ranjit> not association - but the value itself.  Technically IMEI and IMEISV are same (except for additional value of SV)

Lyle

From: DiME [mailto:[e-mail]] On Behalf Of AVASARALA, RANJIT KUMAR
Sent: Tuesday, October 31, 2017 1:08 PM
To: Yuval Lifshitz <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Dime] draft-avasarala-diameter-error-invalid-identity-00

Hi Yuval

Thank you for the comments.

I agree that a standard diameter error exists - the AVP error.   The reason I proposed invalid mobile identity is - it will be more specific to mobile identity.  It can be changed to a 5xxx - but I want an option for the entity to re-send the request with a valid value (assuming it can)

Yes User-Equipment-info AVP is optional in Credit Control Request - but we have seen it is present most of the times and all the times the value is IMEI or IMEISV ( though other values can exist) - but in case of VoLTE / IMS scenarios, the value is usually IMEI.

Now we have lot of cases where due to invalid IMEI - the number of bad records being generated is increasing - so need a way to prevent those.

So the proposed solution is for the entities receiving IMEI as part of any AVP - to validate it and if found invalid to respond with a error.  The entity receiving the error has an option to re-send the request with a valid value if it can.


Regards
Ranjit
VoLTE T4 Support
317-224-9441



From: Yuval Lifshitz [mailto:[e-mail]]
Sent: Tuesday, October 31, 2017 12:07 PM
To: AVASARALA, RANJIT KUMAR <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; Yuval Lifshitz <[e-mail]<mailto:[e-mail]>>
Subject: RE: draft-avasarala-diameter-error-invalid-identity-00

Dear Ranjit,
I think there are several issues with your proposal:

  *   A standard diameter error already exists for the case described. It is DIAMETER_INVALID_AVP_VALUE (5004)
  *   3xxx level error codes are meant for peer level (per hop) while the case you describe is session level (end 2 end)
  *   User-Equipment-Info is an optional AVP (at least in RFC4006), and its payload is not necessarily IMEI or IMEISV. This mean that specification forcing the credit control server to validate it would contradict the existing specification

Best Regards,

Yuval

From: DiME [mailto:[e-mail]] On Behalf Of AVASARALA, RANJIT KUMAR
Sent: Tuesday, October 31, 2017 6:32 PM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: [Dime] draft-avasarala-diameter-error-invalid-identity-00

Hello all

We published a new Internet draft addressing the issue of invalid IMEI in SIP / Diameter requests.

Here is the background

IMEI is used for uniquely identifying the mobile devices.  IMEI is present in SIP REGISTER request (Contact header) and Diameter CCR Request (user-Equipment-Info AVP).   It is always assumed that the IMEI value is correct and also the entities that receive IMEI usually do not validate the value.

This IMEI goes all the way till CCFs which use it as part of records generation that eventually lead to generation of CDRs.  So in scenarios where IMEI is correct, the records are considered good but if the IMEI is invalid or incorrect, then the records that are generated become "bad" and lead to inconsistency in billing.

So there is a need to reduce or prevent the generation of bad records and this can be done by validating the received IMEI and reporting invalid instances of IMEI.

So in order to report the cases of invalid iMEI, this draft proposes a new diameter protocol error code - DIAMETER_INVALID_MOBILE_IDENTITY

We request everyone to review the draft and comment.

The URL of the draft is - https://tools.ietf.org/html/draft-avasarala-diameter-error-invalid-identity-00.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttps-2D3A-5F-5Ftools.ietf.org-5Fhtml-5Fdraft-2D2Davasarala-2D2Ddiameter-2D2Derror-2D2Dinvalid-2D2Didentity-2D2D00.html-2526d-253DDwMFAg-2526c-253DLFYZ-2Do9-5FHUMeMTSQicvjIg-2526r-253DHqz9E2LJHAT14pCYdmHOsQ-2526m-253D9slEZFhalRQfK8W0Qy624FMWppcDpsLJbAfOgESdBug-2526s-253DMP1LfzIYI7pYN8bUqxkF1kdjPlx-2DEQtCfvDNnG9xUXM-2526e-253D-26data-3D02-257C01-257Clyle.t.bertz-2540sprint.com-257C44eb4dec63ce4bfcec0f08d5208a6cd7-257C4f8bc0acbd784bf5b55f1b31301d9adf-257C0-257C0-257C636450701272955406-26sdata-3DQz57rER72b51IojZ3iN21OgJcjdNaQkgX6uSaAc-252Bpsg-253D-26reserved-3D0&d=DwMFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=Hqz9E2LJHAT14pCYdmHOsQ&m=C1X46Oah2dkod6mTzQd2Gucu43Pt0QxtveM6b_VzXnA&s=k7aQgGjqXY88-5XHB6akQ90W0ewaV11A-e096n0aSdU&e=>

Regards
Ranjit






________________________________

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.