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

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

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]>; [e-mail]
Cc: [e-mail]; Yuval Lifshitz <[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__tools.ietf.org_html_draft-2Davasarala-2Ddiameter-2Derror-2Dinvalid-2Didentity-2D00.html&d=DwMFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=Hqz9E2LJHAT14pCYdmHOsQ&m=9slEZFhalRQfK8W0Qy624FMWppcDpsLJbAfOgESdBug&s=MP1LfzIYI7pYN8bUqxkF1kdjPlx-EQtCfvDNnG9xUXM&e=>

Regards
Ranjit