So in order to report the cases of invalid iMEI, this draft proposes a= new diameter protocol error code – DIAMETER_INVALID_MOBILE_IDENTITY<= /div>

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-iden= tity-00.html

Regards

Ranjit

--_000_BD15502709C85D4DAA2DCBF30D38A3B7172894DCMOSTLS1MSGUSRFG_-- From nobody Tue Oct 31 10:06:48 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D347B13F9D1 for ; Tue, 31 Oct 2017 10:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ys76Z0LSFLnb for ; Tue, 31 Oct 2017 10:06:45 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8B6513F9C6 for ; Tue, 31 Oct 2017 10:06:38 -0700 (PDT) Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by WTL-EXCHP-3.sandvine.com ([fe80::3c39:d305:d721:f00a%15]) with mapi id 14.03.0319.002; Tue, 31 Oct 2017 13:06:37 -0400 From: Yuval Lifshitz To: "AVASARALA, RANJIT KUMAR" , "dime@ietf.org" CC: "ben@nostrum.com" , Yuval Lifshitz Thread-Topic: draft-avasarala-diameter-error-invalid-identity-00 Thread-Index: AdNSZIrJm2O1lnw9Q5e+yrjpjtgOFgABIxwg Date: Tue, 31 Oct 2017 17:06:36 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.142.2] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_C43C255C7106314F8D13D03FA20CFE49ED56978Cwtlexchp1sandvi_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dime] draft-avasarala-diameter-error-invalid-identity-00 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 17:06:47 -0000 --_000_C43C255C7106314F8D13D03FA20CFE49ED56978Cwtlexchp1sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 t= he 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 specificatio= n forcing the credit control server to validate it would contradict the exi= sting specification Best Regards, Yuval From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of AVASARALA, RANJIT KU= MAR Sent: Tuesday, October 31, 2017 6:32 PM To: dime@ietf.org Cc: ben@nostrum.com Subject: [Dime] draft-avasarala-diameter-error-invalid-identity-00 Hello all We published a new Internet draft addressing the issue of invalid IMEI in S= IP / 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-Equ= ipment-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 genera= tion that eventually lead to generation of CDRs. So in scenarios where IME= I 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 in= consistency in billing. So there is a need to reduce or prevent the generation of bad records and t= his can be done by validating the received IMEI and reporting invalid insta= nces 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-diame= ter-error-invalid-identity-00.html Regards Ranjit --_000_C43C255C7106314F8D13D03FA20CFE49ED56978Cwtlexchp1sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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 i= ts payload is not necessarily IMEI or IMEISV. This mean that specification forcing the credit control server to validate it would = contradict the existing specification

<= /p>

Best Regards,<= /span>

<= /p>

Yuval

<= /p>

From: DiME [ma= ilto:dime-bounces@ietf.org] On Behalf Of AVASARALA, RANJIT KUMAR
Sent: Tuesday, October 31, 2017 6:32 PM
To: dime@ietf.org
Cc: ben@nostrum.com
Subject: [Dime] draft-avasarala-diameter-error-invalid-identity-00

Hello all

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

Here is the background

IMEI is used for uniquely identifying t= he mobile devices. IMEI is present in SIP REGISTER request (Contact h= eader) 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 wh= ich 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 reco= rds that are generated become “bad” and lead to inconsistency i= n billing.

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

So in order to report the cases of inva= lid iMEI, this draft proposes a new diameter protocol error code – DI= AMETER_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-d= iameter-error-invalid-identity-00.html

Regards

Ranjit

--_000_C43C255C7106314F8D13D03FA20CFE49ED56978Cwtlexchp1sandvi_-- From nobody Tue Oct 31 11:08:40 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93BC713F5BC for ; Tue, 31 Oct 2017 11:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.411 X-Spam-Level: X-Spam-Status: No, score=-3.411 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 37ONNxPG8jsg for ; Tue, 31 Oct 2017 11:08:36 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F9DF139564 for ; Tue, 31 Oct 2017 11:08:36 -0700 (PDT) Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.16.0.21/8.16.0.21) with SMTP id v9VHuZB1022132; Tue, 31 Oct 2017 14:08:34 -0400 Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by m0049463.ppops.net-00191d01. with ESMTP id 2dxvg4mt1n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 31 Oct 2017 14:08:33 -0400 Received: from enaf.dadc.sbc.com (localhost [127.0.0.1]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id v9VI8UKi045411; Tue, 31 Oct 2017 13:08:32 -0500 Received: from dalint01.pst.cso.att.com (dalint01.pst.cso.att.com [135.31.133.159]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id v9VI8TcI045406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 31 Oct 2017 13:08:29 -0500 Received: from MOSTLS1MSGHUBAA.ITServices.sbc.com (MOSTLS1MSGHUBAA.itservices.sbc.com [135.41.4.148]) by dalint01.pst.cso.att.com (RSA Interceptor); Tue, 31 Oct 2017 18:08:22 GMT Received: from MOSTLS1MSGUSRFG.ITServices.sbc.com ([169.254.7.170]) by MOSTLS1MSGHUBAA.ITServices.sbc.com ([135.41.4.148]) with mapi id 14.03.0361.001; Tue, 31 Oct 2017 13:08:21 -0500 From: "AVASARALA, RANJIT KUMAR" To: Yuval Lifshitz , "dime@ietf.org" Thread-Topic: draft-avasarala-diameter-error-invalid-identity-00 Thread-Index: AdNSZIrJm2O1lnw9Q5e+yrjpjtgOFgABIxwgAAJK+5A= Date: Tue, 31 Oct 2017 18:08:21 +0000 Message-ID: References:

In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.38.35.228] Content-Type: multipart/alternative; boundary="_000_BD15502709C85D4DAA2DCBF30D38A3B71728D777MOSTLS1MSGUSRFG_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-31_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710310222 Archived-At: Subject: Re: [Dime] draft-avasarala-diameter-error-invalid-identity-00 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 18:08:39 -0000 --_000_BD15502709C85D4DAA2DCBF30D38A3B71728D777MOSTLS1MSGUSRFG_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 enti= ty 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 IM= EI 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 reco= rds 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 ent= ity receiving the error has an option to re-send the request with a valid v= alue if it can. Regards Ranjit VoLTE T4 Support 317-224-9441 From: Yuval Lifshitz [mailto:ylifshitz@sandvine.com] Sent: Tuesday, October 31, 2017 12:07 PM To: AVASARALA, RANJIT KUMAR ; dime@ietf.org Cc: ben@nostrum.com; Yuval Lifshitz 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 i= s DIAMETER_INVALID_AVP_VALUE (5004) * 3xxx level error codes are meant for peer level (per hop) while the c= ase 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 fo= rcing the credit control server to validate it would contradict the existin= g specification Best Regards, Yuval From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of AVASARALA, RANJIT KU= MAR Sent: Tuesday, October 31, 2017 6:32 PM To: dime@ietf.org Cc: ben@nostrum.com Subject: [Dime] draft-avasarala-diameter-error-invalid-identity-00 Hello all We published a new Internet draft addressing the issue of invalid IMEI in S= IP / 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-Equ= ipment-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 genera= tion that eventually lead to generation of CDRs. So in scenarios where IME= I 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 in= consistency in billing. So there is a need to reduce or prevent the generation of bad records and t= his can be done by validating the received IMEI and reporting invalid insta= nces 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-diame= ter-error-invalid-identity-00.html Regards Ranjit --_000_BD15502709C85D4DAA2DCBF30D38A3B71728D777MOSTLS1MSGUSRFG_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Yuval

Thank you for the comments.

I agree that a standard diameter error exists ̵= 1; 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 t= he request with a valid value (assuming it can)

Yes User-Equipment-info AVP is optional in Credit C= ontrol 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 receiv= ing 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:ylifshi= tz@sandvine.com]
Sent: Tuesday, October 31, 2017 12:07 PM
To: AVASARALA, RANJIT KUMAR <ra698k@att.com>; dime@ietf.org Cc: ben@nostrum.com; Yuval Lifshitz <ylifshitz@sandvine.com> 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 DIA= METER_INVALID_AVP_VALUE (5004)
3xxx level error codes are meant for peer level (per hop) while the case y= ou describe is session level (end 2 end)
User-Equipment-Info is an optional AVP (at least in RFC4006), and its payl= oad 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:dime-bounces@ietf.org] On Behalf Of AVASARALA, RANJIT KUMAR
Sent: Tuesday, October 31, 2017 6:32 PM
To: dime@ietf.org
Cc: ben@nostrum.com
Subject: [Dime] draft-avasarala-diameter-error-invalid-identity-00

Hello all

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

Here is the background

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

This IMEI goes all the way till CCFs which use it a= s part of records generation that eventually lead to generation of CDRs.&nb= sp; So in scenarios where IMEI is correct, the records are considered good but if the IMEI is invalid or incorrect, then the reco= rds that are generated become “bad” and lead to inconsistency i= n billing.

So there is a need to reduce or prevent the generat= ion 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, th= is draft proposes a new diameter protocol error code – DIAMETER_INVAL= ID_MOBILE_IDENTITY

We request everyone to review the draft and comment= .

The URL of the draft is - https://tools.ietf.org/html/draft-avasarala-d= iameter-error-invalid-identity-00.html

Regards

Ranjit

--_000_BD15502709C85D4DAA2DCBF30D38A3B71728D777MOSTLS1MSGUSRFG_-- From nobody Tue Oct 31 11:46:10 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A19C413F5B5 for ; Tue, 31 Oct 2017 11:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.069 X-Spam-Level: X-Spam-Status: No, score=0.069 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACjwNG4dnUgS for ; Tue, 31 Oct 2017 11:46:00 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0118.outbound.protection.outlook.com [104.47.42.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2224413F594 for ; Tue, 31 Oct 2017 11:46:00 -0700 (PDT) Received: from CO2PR05CA0057.namprd05.prod.outlook.com (10.166.88.153) by BN6PR05MB3586.namprd05.prod.outlook.com (10.174.234.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.197.4; Tue, 31 Oct 2017 18:45:58 +0000 Received: from SN1NAM01FT040.eop-nam01.prod.protection.outlook.com (2a01:111:f400:7e40::201) by CO2PR05CA0057.outlook.office365.com (2603:10b6:102:2::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.197.4 via Frontend Transport; Tue, 31 Oct 2017 18:45:57 +0000 Authentication-Results: spf=pass (sender IP is 144.230.32.82) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=sprint.com; Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.32.82 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.32.82; helo=preapdm3.corp.sprint.com; Received: from preapdm3.corp.sprint.com (144.230.32.82) by SN1NAM01FT040.mail.protection.outlook.com (10.152.65.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.178.5 via Frontend Transport; Tue, 31 Oct 2017 18:45:57 +0000 Received: from pps.filterd (preapdm3.corp.sprint.com [127.0.0.1]) by preapdm3.corp.sprint.com (8.16.0.21/8.16.0.21) with SMTP id v9VIck38022172; Tue, 31 Oct 2017 14:45:57 -0400 Received: from plswe13m03.ad.sprint.com (plswe13m03.corp.sprint.com [144.229.214.22]) by preapdm3.corp.sprint.com with ESMTP id 2dvm5751g3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 31 Oct 2017 14:45:56 -0400 Received: from PLSWE13M04.ad.sprint.com (2002:90e5:d617::90e5:d617) by plswe13m03.ad.sprint.com (2002:90e5:d616::90e5:d616) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Tue, 31 Oct 2017 13:45:55 -0500 Received: from PLSWE13M04.ad.sprint.com ([fe80::2c01:fcb8:e729:4a7a]) by plswe13m04.ad.sprint.com ([fe80::2c01:fcb8:e729:4a7a%24]) with mapi id 15.00.1293.002; Tue, 31 Oct 2017 13:45:55 -0500 From: "Bertz, Lyle T [CTO]" To: "AVASARALA, RANJIT KUMAR" , Yuval Lifshitz , "dime@ietf.org" Thread-Topic: draft-avasarala-diameter-error-invalid-identity-00 Thread-Index: AdNSZIrJm2O1lnw9Q5e+yrjpjtgOFgABIxwgAAJK+5AAAKJMwA== Date: Tue, 31 Oct 2017 18:45:55 +0000 Message-ID: <62823085c481447e95e17e4e62c6ce8c@plswe13m04.ad.sprint.com> References:

In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.123.104.22] Content-Type: multipart/alternative; boundary="_000_62823085c481447e95e17e4e62c6ce8cplswe13m04adsprintcom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:144.230.32.82; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(376002)(346002)(39860400002)(2980300002)(438002)(189002)(53754006)(199003)(54896002)(260700001)(54356999)(7736002)(81166006)(6306002)(6246003)(50986999)(345774005)(106466001)(81156014)(512954002)(33646002)(8676002)(316002)(2501003)(356003)(76176999)(16586007)(30436002)(53936002)(110136005)(8936002)(24736003)(236005)(790700001)(3846002)(561944003)(68736007)(6116002)(102836003)(189998001)(4546004)(478600001)(84326002)(14454004)(5250100002)(2906002)(229853002)(45080400002)(5660300001)(2950100002)(7696004)(966005)(2900100001)(97736004)(106002)(86362001)(53546010)(108616004)(230783001)(575784001)(606006); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR05MB3586; H:preapdm3.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; SN1NAM01FT040; 1:735KsOb8Y9ynM99n/03dG08NZvlTUkTCzJAiSVcV2NuX7vRb7gamd0T2jiRqqHj4yhR+n16gf8lbS0CZxR4PwWSQ9ubOfWrwDxbL1gBYpqqMX56HIozDpXHGyQtzESrz X-MS-Office365-Filtering-Correlation-Id: 65c0a8ad-f953-49ee-1649-08d5208f9fe1 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(8251501002)(4534020)(4602075)(2017052603199); SRVR:BN6PR05MB3586; X-Microsoft-Exchange-Diagnostics: 1; BN6PR05MB3586; 3:TNVqFg+ImP8/eMo6QH+cKdV3J2QM+SEkaEW2Uun2OMxs7seycSckHFuK4Z0QgD0rkcUiyIgHnDYY755JBDMT8D5I7kF2PdnH3rYDg0zgV1KsyAy09Te92NzVL3cgwK8oBLN5PjeFjFA6iSZvytkEQTnO0W4E18WKPhfiX+/+s85jeB0ruoIHg/Owq88xADWnGlIxqpuT7vj2KZ32kSOAPnZQEgnctorjGhPn3lnwWa8wB1irc5yZgpaNiKlA4FLpnVcWg+wIHdCV+NNmDQcwwOQEimL8iPHsK8OukAa7otZyCdPbLIZm/xOqy5KT/rT80/y07RtFyOXqINK/LODd+ZHpP3DMosPOT31CRQkjJVk=; 25:PjR9nusxXKosog7jU1LzCWnesyLRBanFoaJlnzZ0CTi6fyNipMacrp9uPzPt9NVWwuL3N2VcHVOx7vLV6SBXGtRql7RIQO8bBUqlMsEMseaHqBTiK6KwFUWh1sqKCgzRS9E0vdjytjhbycqakJkOG4qYuQJLSHHHc6CVQ7BDm1Ar/dZc4NZr9+Z/aEWc9zN84ZwSB18Sq8nZ9O36tsxokhncA1EnzdGbfIYXbiVy1pBHKOTRhAixOIPpmLSQllGVl9FsxKqoMYCmPcb12qtewq980KvJSbElN8c+zsauA0ddfXx5KUIMasGsA2abVl4Gl7nsSscFVsYO+QCj/lX5uQ== X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN6PR05MB3586: X-Microsoft-Exchange-Diagnostics: 1; BN6PR05MB3586; 31:ATEgUMtyte219/VTvmdCf2r7+3rf/002ofxmyfKtPwvEEpIif1btFCi95pSBeQs+darU+mUCOJcfZQ1Oz21uA0JNqKc5mikjs3efXmZjRMKuXnwVhIuScA4eDPo6pLdy4rsLf6sdBBdcQ5S6RPouKeXFfAiREKRCQGkOU41/qjLqIl0NcKtPBXWxR/Jr1XVhCJ2TBuWAN2U40M+B1qm1hcn+tIzqLbRzV0FshyIVs5Y=; 20:r8J0r4eVameUNrypw5BOFw26WeV12heMPwojqrp8PvMihRtEceMyNtEUkK2clEeYSxpTK4AdgawKES86hBwFWW9tT5LdoOwNgAQvoL8iwv6fbjfueK0mRXtEwB522mb8DeDhg9GBy3XMMjNe5qZ3DHir1/QSdKsfTgNj4i2dIQr8jkRoYRbjqle4Dk5ab7h++5clbjh8E0gs/Fy7PY9KZlaKpxec2Z+MmZQLkXG2ir+fHbsD3O9pfv0sQUeD2akg4HRaQHWdX7cPcKLTKYty3hrne5xP/SyzRyaA531ViX3qN2lyWCD50GxrFSptwsFUlJKcdR0fzhLTMbuKK8AJQKTww4tt6BvmNPDm90/uh/Gq4vaqfMgMZrm/G4Meyp6jt7f/z9PT7p1+bJug6zHkTw4zg1SbKOdOgtfgZWsG3fkTTtveDe72BV6vCAEBTb5t1T4vpeEHUVYdW3S32AApQ0x9R5v2NO6jd45AH8coWIpC/OOODsAzFBmKfh6gRb3y X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(189930954265078)(97927398514766)(219752817060721)(21748063052155)(211171220733660); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93004095)(100000703101)(100105400095)(10201501046)(3002001)(3231020)(6055026)(6041248)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN6PR05MB3586; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN6PR05MB3586; X-Microsoft-Exchange-Diagnostics: 1; BN6PR05MB3586; 4:aGQ6763NZpF/+duTBETS5ffJhEMBmqyIQ1tPwTZSYWHYmTGXLwDfNrUMyajPxw6lntP1FKqgOY68HtCd8yOM4goLUR0BKJBUaf52CbPwCtM7TUtv0kUOpzcv6Svoavsj76Dtt6QVXNVyz5N9f/57rC1SxfzME5GM/fMDoRxaDdcYM6/Tb2tL7/mnre6rBFF6sdJ3nwmVV5yC/ohwEXv5Mu3c++8AJhcJxGNZ6TWBjDiYYLvE/NdXpghtwKmE8EP3VUGnDZOIR8Gtcl/m8n7nt4/yxoqekJLF2kpNpf8UK4FLBSvGHlzuD6B7Mi7pZ2W95rYw6HJqef/JLkSjW+tX3ossADzBY6z5Ka69LO0olqiYQbuG68qeoRmKut8RkHlLIqcM2/TMIIOi6SDMl9xZ6AGtUbjE4+mvp/y/A4XyqmlV0KjEkXaPQ+zajiGtH50CJVgwAU5LboTCjJOb4CZWrN8GJCtbzJ5JJv0/iKqEVIw= X-Forefront-PRVS: 04772EA191 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN6PR05MB3586; 23:HEEWlCkTtv6JE+feKt1CJVl8D6QVoq8mlM7HgY1Bs?= =?us-ascii?Q?Tp8RDudGoXcTd5hUDmD4epLqYvv+A1OcxRB3jyAfDgYy/m1Y/sD+0CF9qBou?= =?us-ascii?Q?wBM5Es8Grb9d3IooxjSJJKTNVEYhAkeL/UBwNBKo7NJmGT6bQf2n6qn6VlA/?= =?us-ascii?Q?jpZbtoqEAaWGG+AqxNeL+g7bEXzmSLcMJQlpr3UW7RfrMYBFPNfseB7WBNcA?= =?us-ascii?Q?I+7xIhxCL3jBaLxshhk5J/RKeDk7V4pm6l4fQbs+Bmo1c0lrWrIxk86IfRbN?= =?us-ascii?Q?aZk2KAntWrD3+e5d/H0z0wDokp1MzY9sSDc0V0w6jB1XLVljH8pgeIxEjOOA?= =?us-ascii?Q?iYzsAdtBUz8LzNUYLU+uULeA/wSNqtfZbXMAPa3S6ANhk/+SP+TJSQIhVtvL?= =?us-ascii?Q?+6PYGZkwJaVDF4oFQRi5W6hz2TA5mhpU+0YXmbcYRu7BS5oyY+bnMegRmQPR?= =?us-ascii?Q?nEm/PwxqR8ae4xYHAMrGt7Cd1JqOtXg/apCuwI5jekeFkFy8IcWRyHPwAyGD?= =?us-ascii?Q?0mLuP1BKj/Rtf3oHNbRlOOUg8Ol+Wo09SHR1A5ZyosMSUcpLzy73vtmekDJK?= =?us-ascii?Q?kZ0hJuPtBTZVmyE5sB6h/pkX1Qsp9oI+b5MbfFRFdcBbwf9XvEHxGXDbGZwh?= =?us-ascii?Q?HEYtqm7Z+3Af2r2IGZScCFmmB7HXOJpzXBfAJPbvi2ziKWMvG6cDh+z+Klxr?= =?us-ascii?Q?zcRq4+VVecxSRw15hWPsKuT/NnDhqL2taz3Ycaba3SLEew91F8lpMDVVofn4?= =?us-ascii?Q?GIyqsUmHS8S53IHSZw8DOAxrPiiHJjIZcgON+WfSTs/Fdx05vc4Z0/jEaDBr?= =?us-ascii?Q?XQ4aqaUD6aht9V6AEzkMAITWWxbCI3Rb73za5KYdYAjiuyjUhWPjtb/sRza/?= =?us-ascii?Q?wapr35+pg2MB4UtNaTwxDrl/GDKRM1hUWyJALFwX0sr1HcW3FNtvTFsy9uo3?= =?us-ascii?Q?GbZdjPIIaujQixTvqRb3sar9uLEO1JhDPaLFLeMfaSfRyWE8JyjFxuuFIgtS?= =?us-ascii?Q?mrnJR3lgUK2U7iYOXCqLnMskj79vOsxHV6nIq+W8TVsH2eMzTV4vxiZ0WFq2?= =?us-ascii?Q?FRGKGmbumas6+NxaxIepM4fmNM1OGcEYYz1WHan8jzDzSNf2u9FLxwESy8R7?= =?us-ascii?Q?yJi1KuqBaeDowRhQaXwTon4C4khumnmzDAMGIz4QNoAE8HoQ9wkX4OxmXQMd?= =?us-ascii?Q?pqkvmcD/2Xbb4MBwyJ3NmTeb/VVHNVw69oerbtnw8ktMfva6AfJviJXjE/80?= =?us-ascii?Q?Gq79fkfhkoA+xyUBw7cTXsfU3u6giMCPe9K9+YFOOaUjAHUO49pCD2ykkzf5?= =?us-ascii?Q?GRTBLzcGfUJ/upaO2JmziA7uFbMaDIAL9k6uUCofYeD5SqLiOdIibtttOiu4?= =?us-ascii?Q?W1zeeovfhmzEtgeSs3NJUz6B/9oUkmHOk5R+m6w10MRch1Y?= X-Microsoft-Exchange-Diagnostics: 1; BN6PR05MB3586; 6:KfUrVvANgo2rCWd8yJFIZFty5kbb9ZvT/siGfw7rGmlHYJc0gLt7dnWgx53GXdHSzKGwDOGTCVf4UY4yhaF8yrlLrFzNrkK7a7c5tj+v13zve1RVwToG2TgBPyBpFDwlox/8BxVZTPQHUPl5CZYlO6uC+7XOkX7+gyF1UaXRNQ73KEtSWTKm6fVLBDiJCU5kzrFzInuV5MR7zRK5g0ZRTcBnbSNOlC/Vv5P0z9bS7y3jHHwtt7/whsO5IrwbZW6CkWRlzdcgeZ8BIyNpL/8JR7jTUYiBtxIhYfSl6ctAmTJJTKhQxAEIcoveBgP3dGeVfwzTxcCojhPaOPF4CzTVry/KNEKvJC28/6HH3BRl0gc=; 5:ZTOm9XdfbUPB2g8ibguJB3DG4HoWMBlvjiCWASND8sDfo2p3vafFbv1cUEuPLMuAjY+rcpkulesej5p32wX8fJbtNOp1pvWVBvCFDk2ca/XQ8d7/bHJ7+CVu3gXsZrNSvT9atWGhKS79MQFWa9DhhAuSnwXbq9G0e+/aLtqC1zo=; 24:3SN9Qqi1uwmnml/ssaMjkBpi+v4riSf1Xj/rcnc9xcP/KWuyPsPijF4JoV7dEw49P7zVAfYJ0FG4upz5RytC2o9TfGsAHn99xcm5AASmvso=; 7:CYfJ6qygf2hQ7bJJWonKvWPVcqqLkuUF7WzcPVJAn2IHFvyDBNPIifxiyAuD4EbNLBjfoh/Bzs/wrjVwhNwhwfIDCnSo4R7R/oV9uWp2+ckCbrbHF202GZ0HJEi/YSqQ7du/KGsW/dyBecPegIiS6vr+DN1rnLU0KPR8PHBtQxj5QUBuZFHnkbwnjgKK4q/sv+OaqIp1cDFRMNPpBYz7VMcVhGbvcagUpxqucflUQLaZRaCvLbeG00s1/zdLk656 SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Oct 2017 18:45:57.5502 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 65c0a8ad-f953-49ee-1649-08d5208f9fe1 X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.32.82]; Helo=[preapdm3.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR05MB3586 Archived-At: Subject: Re: [Dime] draft-avasarala-diameter-error-invalid-identity-00 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 18:46:09 -0000 --_000_62823085c481447e95e17e4e62c6ce8cplswe13m04adsprintcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A few questions: 1. How did a CTF get and invalid IMEI? It is typically pulling from = somewhere else. 2. When you say invalid in the spec you reference format. If it is f= ormat that is doable but if it is questioning data / associations outside o= f the AVP or message then this is problematic. An invalid value in the pr= oposal is too vague. Was it a well formed AVP which did not pass some app l= evel semantic check or was it just bad data? 3. Is this a IMSI-IMEI(SV) association issue? Lyle From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of AVASARALA, RANJIT KU= MAR Sent: Tuesday, October 31, 2017 1:08 PM To: Yuval Lifshitz ; dime@ietf.org 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 enti= ty 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 IM= EI 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 reco= rds 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 ent= ity receiving the error has an option to re-send the request with a valid v= alue if it can. Regards Ranjit VoLTE T4 Support 317-224-9441 From: Yuval Lifshitz [mailto:ylifshitz@sandvine.com] Sent: Tuesday, October 31, 2017 12:07 PM To: AVASARALA, RANJIT KUMAR >; dime@i= etf.org Cc: ben@nostrum.com; Yuval Lifshitz > 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 i= s DIAMETER_INVALID_AVP_VALUE (5004) * 3xxx level error codes are meant for peer level (per hop) while the c= ase 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 fo= rcing the credit control server to validate it would contradict the existin= g specification Best Regards, Yuval From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of AVASARALA, RANJIT KU= MAR Sent: Tuesday, October 31, 2017 6:32 PM To: dime@ietf.org Cc: ben@nostrum.com Subject: [Dime] draft-avasarala-diameter-error-invalid-identity-00 Hello all We published a new Internet draft addressing the issue of invalid IMEI in S= IP / 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-Equ= ipment-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 genera= tion that eventually lead to generation of CDRs. So in scenarios where IME= I 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 in= consistency in billing. So there is a need to reduce or prevent the generation of bad records and t= his can be done by validating the received IMEI and reporting invalid insta= nces 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-diame= ter-error-invalid-identity-00.html Regards Ranjit ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e 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. --_000_62823085c481447e95e17e4e62c6ce8cplswe13m04adsprintcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A few questions:

1. = ; How did a CTF get and invalid= IMEI? It is typically pulling from somewhere else.

2. = ; When you say invalid in the s= pec 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 p= roposal is too vague. Was it a well formed AVP which did not pass some app = level semantic check or was it just bad data?

3. = ; Is this a IMSI-IMEI(SV) assoc= iation issue?

Lyle

From: DiME [mailto:dime-bounces@ietf= .org] On Behalf Of AVASARALA, RANJIT KUMAR
Sent: Tuesday, October 31, 2017 1:08 PM
To: Yuval Lifshitz <ylifshitz@sandvine.com>; dime@ietf.org
Subject: Re: [Dime] draft-avasarala-diameter-error-invalid-identity-= 00

Hi Yuval

Thank you for the comments.

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.

Regards

Ranjit

VoLTE T4 Support

317-224-9441

From: Yuval Lifshitz [mailto:ylifshitz@sandvine.com]
Sent: Tuesday, October 31, 2017 12:07 PM
To: AVASARALA, RANJIT KUMAR <ra= 698k@att.com>; dime@ietf.org
Cc: ben@nostrum.com; Yuval Li= fshitz <ylifshitz@sandvine.com= >
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 DIAMET= ER_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 contr= adict the existing specification

Best Regards,

Yuval

Hello all

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

Here is the background

So there is a need to reduce or prevent the generat= ion 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, th= is draft proposes a new diameter protocol error code – DIAMETER_INVAL= ID_MOBILE_IDENTITY

We request everyone to review the draft and comment= .

The URL of the draft is - https://tools.ietf.org/html/draft-avasarala-d= iameter-error-invalid-identity-00.html

Regards

Ranjit

This e-mail may contain Sprint proprietary information intended for the sol= e 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.
--_000_62823085c481447e95e17e4e62c6ce8cplswe13m04adsprintcom_-- From nobody Tue Oct 31 11:57:38 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3663E13F5FF for ; Tue, 31 Oct 2017 11:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.411 X-Spam-Level: X-Spam-Status: No, score=-3.411 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7CSH8-WkjbyM for ; Tue, 31 Oct 2017 11:57:33 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EABA13F5F2 for ; Tue, 31 Oct 2017 11:57:33 -0700 (PDT) Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.16.0.21/8.16.0.21) with SMTP id v9VIvROV035991; Tue, 31 Oct 2017 14:57:31 -0400 Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by m0049458.ppops.net-00191d01. with ESMTP id 2dxvu15tef-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 31 Oct 2017 14:57:28 -0400 Received: from enaf.dadc.sbc.com (localhost [127.0.0.1]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id v9VIvEWv118120; Tue, 31 Oct 2017 13:57:16 -0500 Received: from dalint01.pst.cso.att.com (dalint01.pst.cso.att.com [135.31.133.159]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id v9VIv9UU118026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 31 Oct 2017 13:57:10 -0500 Received: from MOSTLS1MSGHUBAA.ITServices.sbc.com (MOSTLS1MSGHUBAA.itservices.sbc.com [135.41.4.148]) by dalint01.pst.cso.att.com (RSA Interceptor); Tue, 31 Oct 2017 18:56:53 GMT Received: from MOSTLS1MSGUSRFG.ITServices.sbc.com ([169.254.7.170]) by MOSTLS1MSGHUBAA.ITServices.sbc.com ([135.41.4.148]) with mapi id 14.03.0361.001; Tue, 31 Oct 2017 13:56:53 -0500 From: "AVASARALA, RANJIT KUMAR" To: "Bertz, Lyle T [CTO]" , Yuval Lifshitz , "dime@ietf.org" Thread-Topic: draft-avasarala-diameter-error-invalid-identity-00 Thread-Index: AdNSZIrJm2O1lnw9Q5e+yrjpjtgOFgABIxwgAAJK+5AAAKJMwAABIT8w Date: Tue, 31 Oct 2017 18:56:53 +0000 Message-ID: References:

<62823085c481447e95e17e4e62c6ce8c@plswe13m04.ad.sprint.com> In-Reply-To: <62823085c481447e95e17e4e62c6ce8c@plswe13m04.ad.sprint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.38.35.228] Content-Type: multipart/alternative; boundary="_000_BD15502709C85D4DAA2DCBF30D38A3B71728FDFAMOSTLS1MSGUSRFG_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-31_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710310228 Archived-At: Subject: Re: [Dime] draft-avasarala-diameter-error-invalid-identity-00 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 18:57:36 -0000 --_000_BD15502709C85D4DAA2DCBF30D38A3B71728FDFAMOSTLS1MSGUSRFG_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Lyle Answers inline Regards Ranjit VoLTE T4 Support 317-224-9441 From: Bertz, Lyle T [CTO] [mailto:Lyle.T.Bertz@sprint.com] Sent: Tuesday, October 31, 2017 1:46 PM To: AVASARALA, RANJIT KUMAR ; Yuval Lifshitz ; dime@ietf.org 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 som= ewhere else. 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 cor= e. 1. When you say invalid in the spec you reference format. If it is form= at that is doable but if it is questioning data / associations outside of t= he AVP or message then this is problematic. An invalid value in the propo= sal is too vague. Was it a well formed AVP which did not pass some app leve= l semantic check or was it just bad data? 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 C= CF that receives the IMEI should validate the IMEI (which the CCFs currentl= y 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? not association - but the value itself. Technically IMEI and IMEI= SV are same (except for additional value of SV) Lyle From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of AVASARALA, RANJIT KU= MAR Sent: Tuesday, October 31, 2017 1:08 PM To: Yuval Lifshitz >;= dime@ietf.org 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 enti= ty 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 IM= EI 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 reco= rds 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 ent= ity receiving the error has an option to re-send the request with a valid v= alue if it can. Regards Ranjit VoLTE T4 Support 317-224-9441 From: Yuval Lifshitz [mailto:ylifshitz@sandvine.com] Sent: Tuesday, October 31, 2017 12:07 PM To: AVASARALA, RANJIT KUMAR >; dime@i= etf.org Cc: ben@nostrum.com; Yuval Lifshitz > 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 i= s DIAMETER_INVALID_AVP_VALUE (5004) * 3xxx level error codes are meant for peer level (per hop) while the c= ase 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 fo= rcing the credit control server to validate it would contradict the existin= g specification Best Regards, Yuval From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of AVASARALA, RANJIT KU= MAR Sent: Tuesday, October 31, 2017 6:32 PM To: dime@ietf.org Cc: ben@nostrum.com Subject: [Dime] draft-avasarala-diameter-error-invalid-identity-00 Hello all We published a new Internet draft addressing the issue of invalid IMEI in S= IP / 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-Equ= ipment-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 genera= tion that eventually lead to generation of CDRs. So in scenarios where IME= I 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 in= consistency in billing. So there is a need to reduce or prevent the generation of bad records and t= his can be done by validating the received IMEI and reporting invalid insta= nces 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-diame= ter-error-invalid-identity-00.html Regards Ranjit ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e 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. --_000_BD15502709C85D4DAA2DCBF30D38A3B71728FDFAMOSTLS1MSGUSRFG_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Lyle

Answers inline <Ranjit>

Regards

Ranjit

VoLTE T4 Support

317-224-9441

From: Bertz, Lyle T [CTO] [mailto:Ly= le.T.Bertz@sprint.com]
Sent: Tuesday, October 31, 2017 1:46 PM
To: AVASARALA, RANJIT KUMAR <ra698k@att.com>; Yuval Lifshitz &= lt;ylifshitz@sandvine.com>; dime@ietf.org
Subject: RE: draft-avasarala-diameter-error-invalid-identity-00=

A few questions:

How did a CTF get and invalid IMEI? It is typically pulling from som= ewhere else.

<Ranjit> invalid iMEI can come from dev= ices reporting invalid IMEI value. This IMEI value comes from device = to MME to PGW and all the way to IMS core.

When you say invalid in the spec you reference format. If it is form= at that is doable but if it is questioning data / associations outside of t= he 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 inval= id E.g. the IMEI should be 15 digits long and should follow the rules defin= ed in RFC 7254/7255. So the CCF that receives the IMEI should validate the IMEI (which the CCFs currently do not) and once they d= o, and if they determine that the IMEI is invalid, then they should insert = the error code into Diameter response (E.g. CCA).

Is this a IMSI-IMEI(SV) association issue?

<Ranjit> not association – but the valu= e itself. Technically IMEI and IMEISV are same (except for additional= value of SV)

Lyle

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of AVASARALA, RANJIT KUMAR
Sent: Tuesday, October 31, 2017 1:08 PM
To: Yuval Lifshitz <yli= fshitz@sandvine.com>; dime@ietf.org
Subject: Re: [Dime] draft-avasarala-diameter-error-invalid-identity-= 00

Hi Yuval

Thank you for the comments.

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.

Regards

Ranjit

VoLTE T4 Support

317-224-9441

Dear Ranjit,

I think there are several issues with= your proposal:

A standard diameter error already exists for the case described. It is DIA= METER_INVALID_AVP_VALUE (5004)
3xxx level error codes are meant for peer level (per hop) while the case y= ou describe is session level (end 2 end)
User-Equipment-Info is an optional AVP (at least in RFC4006), and its payl= oad 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

Hello all

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

Here is the background

So there is a need to reduce or prevent the generat= ion 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, th= is draft proposes a new diameter protocol error code – DIAMETER_INVAL= ID_MOBILE_IDENTITY

We request everyone to review the draft and comment= .

The URL of the draft is - https://tools.ietf.org/html/draft-avasarala-d= iameter-error-invalid-identity-00.html

Regards

Ranjit

--_000_BD15502709C85D4DAA2DCBF30D38A3B71728FDFAMOSTLS1MSGUSRFG_-- From nobody Tue Oct 31 12:02:28 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18D6513F623 for ; Tue, 31 Oct 2017 12:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id InQQNXSez69l for ; Tue, 31 Oct 2017 12:02:21 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0122.outbound.protection.outlook.com [104.47.33.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDD8913F67F for ; Tue, 31 Oct 2017 12:01:27 -0700 (PDT) Received: from SN1PR05CA0025.namprd05.prod.outlook.com (10.163.68.163) by CY4PR05MB3590.namprd05.prod.outlook.com (10.171.244.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.197.4; Tue, 31 Oct 2017 19:01:26 +0000 Received: from BY2NAM01FT037.eop-nam01.prod.protection.outlook.com (2a01:111:f400:7e42::204) by SN1PR05CA0025.outlook.office365.com (2a01:111:e400:5197::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.197.4 via Frontend Transport; Tue, 31 Oct 2017 19:01:25 +0000 Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.172.38 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.172.38; helo=plsapdm2.corp.sprint.com; Received: from plsapdm2.corp.sprint.com (144.230.172.38) by BY2NAM01FT037.mail.protection.outlook.com (10.152.68.63) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.178.5 via Frontend Transport; Tue, 31 Oct 2017 19:01:25 +0000 Received: from pps.filterd (plsapdm2.corp.sprint.com [127.0.0.1]) by plsapdm2.corp.sprint.com (8.16.0.21/8.16.0.21) with SMTP id v9VHjgPL043229; Tue, 31 Oct 2017 14:01:24 -0500 Received: from prewe13m03.ad.sprint.com (prewe13m03.corp.sprint.com [144.226.128.22]) by plsapdm2.corp.sprint.com with ESMTP id 2dvqp64dhg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 31 Oct 2017 14:01:24 -0500 Received: from PLSWE13M04.ad.sprint.com (2002:90e5:d617::90e5:d617) by PREWE13M03.ad.sprint.com (2002:90e2:8016::90e2:8016) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Tue, 31 Oct 2017 15:01:23 -0400 Received: from PLSWE13M04.ad.sprint.com ([fe80::2c01:fcb8:e729:4a7a]) by plswe13m04.ad.sprint.com ([fe80::2c01:fcb8:e729:4a7a%24]) with mapi id 15.00.1293.002; Tue, 31 Oct 2017 14:01:22 -0500 From: "Bertz, Lyle T [CTO]" To: "AVASARALA, RANJIT KUMAR" , Yuval Lifshitz , "dime@ietf.org" Thread-Topic: draft-avasarala-diameter-error-invalid-identity-00 Thread-Index: AdNSZIrJm2O1lnw9Q5e+yrjpjtgOFgABIxwgAAJK+5AAAKJMwAABIT8wAABUNKA= Date: Tue, 31 Oct 2017 19:01:22 +0000 Message-ID: <0cc48ec93fd94822a8ca43e1861f44ca@plswe13m04.ad.sprint.com> References:

<62823085c481447e95e17e4e62c6ce8c@plswe13m04.ad.sprint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.123.104.22] Content-Type: multipart/alternative; boundary="_000_0cc48ec93fd94822a8ca43e1861f44caplswe13m04adsprintcom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:144.230.172.38; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(376002)(346002)(39860400002)(2980300002)(438002)(53754006)(189002)(199003)(54896002)(110136005)(76176999)(2906002)(966005)(606006)(16586007)(356003)(345774005)(575784001)(68736007)(2900100001)(229853002)(189998001)(8936002)(45080400002)(106002)(53546010)(230783001)(86362001)(7696004)(6246003)(50986999)(5660300001)(108616004)(2950100002)(93886005)(5250100002)(316002)(30436002)(106466001)(84326002)(4546004)(97736004)(2501003)(24736003)(236005)(478600001)(14454004)(790700001)(260700001)(33646002)(102836003)(512954002)(53946003)(8676002)(7736002)(53936002)(54356999)(81166006)(3846002)(561944003)(81156014)(6116002)(6306002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR05MB3590; H:plsapdm2.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM01FT037; 1:uxnYZuXZrzI6jwKYOdiZ3CgUU1WltFtUa9iBpjIzDFQRC8jbzu5wJiJsr3i7HIsm3uAKto5AT2Ti4cjvNQwffFojtL26eRcMsDxtBSripbIwyEZs4v4YnNg2PWM1+uQO X-MS-Office365-Filtering-Correlation-Id: fd1ee498-6577-4780-2553-08d52091c905 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(8251501002)(4534020)(4602075)(2017052603238); SRVR:CY4PR05MB3590; X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB3590; 3:jrCh0/Kh5MkRGacda/5esGs1grjHGKPwO7TFiU8lpL3h/Zgx9PUNgg/Zxb6Cb2+UfAtomzvnUptRMkFHr6ECGnIxHVI7OmUm4CmohpquG2KS27ahhYaZnLlBIqXY9T0p7EcmeYjt5MNjemr67ep7U0m5i9k729HVMJkMG98lxEvZzuTFEazS1NoQkwbtCcAKr3syHmV+rhkyqJsYC+IK2eWrCXiewZJAiHHvzDnaUOgk3LPzW2vZYiKe8NaUa8o/xVnmwQnrE57D66MtOE6iN+WRHyvudiF/0Vx9mfXJ4Tiz+8qhK0I64OU8RRB0NSlGkbcvrdlOXrLJqWm8Kbi5GkVUeFDVdm19jaTcGoWDtCw=; 25:tnOtcHV/12qUt5JlCmTc4tPUSkgK2xvpvq3qk7yrKWtLgQm80RWHVbvLqUFCCN0jHnttJXSYZp/m2Y94AO9fUkG7quw7tTlpPluLH+/m/lzMEpcbfZBBug1w2HE+g15FqTnL8Pfwh8+Aj3xZoCcJqCfnaVq7ReAFWbT3n+h6ud36MOR93kJKptvFtywGcicitdMDCLaT8lMr8gmdh5RDTqOoriF0nPcwEy0usLS28WEd9ZPzpHsSEMhWl4+7htR6wJ06sVfg068sqnS2eVAMDV28ZT+izLmbBXNtrv0r5oInckYcoPYxA1oh+w2I5UuDlyCcD6B/zoeCApUSE9Pz3g== X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CY4PR05MB3590: X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB3590; 31:aG/zzzBET9p1ymcHn1W6ggDB1oVEeJ0oUTVwevlphXT+61Xl+zrkzrTEPZhjJEOUDFLvZTIEKcRQwJzVXHsEOl8+3nYHH23aZvIUwQ/dz6lGGz+sv8gSM8bM3wofshUs60R7ed9rKq/9XL6K1mwj5zoaNFKnOIsdCRFunXfhgjk/+qi/YD2GYBVPm4J4X759MmMHO2HDJ1kTpAZaIwyZj9xt6zejWElJabuDDtII12k=; 20:4XJiNDYhZzQ+EqYKvaSodDeWFtY4iNFDem6kdwg5paZgFxlxGP5HGWT1GzuXElhhQ9wDH+l7lQnrrVE/UuCNm6WpfjoxBKicxYCTzpn/f8XqcLbarRzbJzAF5RLsqL+ivLEjRE4tzg/w/abhmD9NgtdTZ4u0aUYnJvm7DsUtrs3SJHmBLMxV2kHUG1YIY6bRPOQr2cKPPrC+T0/VM++RQJITPXFrJUT75KlioQ92F9Pcg+9DMuDfaduIxwgWu5tQSopb6cz1EgDtGFq9Q3Mdbf0YJkjQ8HCLF8RujWFiUDVZnjyZdcsa+eBSAbZYV3wY4LvRjMzOVTwleIx73ZF5WhO+/jqaG2o00aoX+IbgkFAnJEeSyogdCZ5fTL7d31KLyhH9X6gimqqWgKOqJiPh1i7ULV0LYX9Myfe8WyEhXmBoMY2Mr6SGbK4fQDntywuCoZbu/o5wXGew3Brmzt9N+TKOLBWGVRL+Jk2tuiGWWJp4xFXWppKoOFX9cxKKW27b X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(18430343700868)(189930954265078)(97927398514766)(219752817060721)(21748063052155)(211171220733660); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93004095)(3231020)(3002001)(10201501046)(6055026)(6041248)(20161123558100)(20161123560025)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR05MB3590; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR05MB3590; X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB3590; 4:9fULwca6Z/00dgt7GkWtjZsPHsR84+Sn1SRHu/yEdsLGDopC8HFv9tFD5itzC9GXOC+7hrZ/SRYOLhmssJiZO5JM5KHVyOYClm/gMD9OnDDvzKItgtb74T2cvVWnF129ji72KktgC9I+rKZtegDQuuhd9Ie/z7BgqLAKlER8KxUF4nwLZOxoBh+NexU77PI3d+cUQ0AjX89KYxb8pKSVxl0GzN4Kv67tf6WatM+Qe5Tadu7HXBpZtdd4sdbDTI3gjeSYP7KerAOK0VVIgHWuCsGAli7w52gmdYfk8rg8QHBPDwb20hgOFAMYS27r6yXTwFIwE4CJbrMpYr9RDa8Q2Pehqoj+WFZ3ykhyw/7OxoqOoow5CjbXJqWdKrFT+6Ve+uH1H7HyTOXno1iz5pyRmTAput7lEVQtRvnYSgkZvDVSiIYjoiiOnvMBE22oiwMjPQPqUPIG2ORpK2vG3qFx6BunVVleniyKefr9vLyMR6oPdeIFbiEe2oGT7xLu/+JGzvIFRDwTesCbzV+nmTR3yA== X-Forefront-PRVS: 04772EA191 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY4PR05MB3590; 23:J5CMkn8q6LAfd3UWK0VgOmqqkH2j3/FCmwu/TE4NC?= =?us-ascii?Q?CvfWlLV5XydzI8da2Sxis9TOMRgVxx6HkWgi3VVdkzDw62jqjna2y4HrdeYb?= =?us-ascii?Q?6XDDQxW17Qe7m3fRebvsi9goMeyhKjSw9GUjNzVeyhrmni+Zbv86IKvPeYPR?= =?us-ascii?Q?WL8SO7RTbTLSkbxoeGH1PW064rAEapSWptRX9saxm47U0x7SOXGagUrGXJsf?= =?us-ascii?Q?ONNUwoi5GzK1ipWv0+cydlL5NtibH+tqqqktTvA9KhGAvS5YV63eiF/U/wdI?= =?us-ascii?Q?S3MZdyiS+nfFqp9cYOgI3wTpK8Y6tFUzdX3MUWZIX+nbyZSK77HnVUvtU8wX?= =?us-ascii?Q?F3ajkQbiX+60hRp99Mpn/i6fxISAQIL0p+i5LDwkN7I9kF+lV+GzcGDKRIAZ?= =?us-ascii?Q?AJXMWLcBu85i+TkmXsCB3a0wBXKwK0LQq4sVFoM1kJHYOCci7DNECEpPRIAA?= =?us-ascii?Q?Jg6kIM8ztCpBaZdAqJ8gIiI09l1jfkDOosyDBZK+rQG6I4XRUdFOSkdW8ECw?= =?us-ascii?Q?nzCQywURrraAPSIssDNiYXjB17kdKOSUBgNWlU9mHrIzR3xIyUzqB6M808YZ?= =?us-ascii?Q?d79HLejecjYxQkRfb8IBV8vsjN4b+aiGNvoNIPEze1fyIiwRCjXhUw570++9?= =?us-ascii?Q?QsoFOxa0SmusruuKR0ADqQlCtiYrgROzsDMYqxG/MbFsA8WtWYEJOcFJraLv?= =?us-ascii?Q?RgzB/VbwehD+nKDJqUbS0rArBICH/3+HpciXxXfGaKzCfoLfkTwfc34YPTFj?= =?us-ascii?Q?/Nt7tUchNl7g4AAdp/5nq4WHlTDfErZCAdG78Lgw1lJ6pA7CXcZbP0F/ylbQ?= =?us-ascii?Q?/Y3eBlkGTZDjKYTlK/AxnBqG1quXq4RO4sA/96JmgqPWQORZrLfDDQbNzWwf?= =?us-ascii?Q?4Hyi/CtggNgfQ8qPaEwLudfn5vZf2UejCiHkPuwV2yygUJqi445Uk2CcCxRH?= =?us-ascii?Q?rfuu7kBHa+iweRdOJ1nmQeE9ESAWLcnSFN0r1t13ZBJQXQlMzEpLEzg6NYd5?= =?us-ascii?Q?w7J3RxyO5VcKe98RluNOZstsdRL03saNCPcVr9csxCgHiJc9ZpVozJqMcfbf?= =?us-ascii?Q?5Gc3XUy57BF5Z35pVBiqexf6ssKsd/asHFR0660T8qI2RaJsdLt6bv4qBGCX?= =?us-ascii?Q?az6CLIAr2E4ImFmzu43U+J8RQIxBEmWI2ynZ2G/3H8NhQBN4jQ+aSROOI/or?= =?us-ascii?Q?0gGy21bKnCJ3wWoe+QBolF8xZKBBsUKMZU4Uw6UhJqsJFKlMlWV3coot6wCb?= =?us-ascii?Q?Z4iRBl7zaENE2AWmo6WQlAdUODNYc0r12wNZwXDKGSGIEXn8a/osRXRv3URW?= =?us-ascii?Q?yJToMJVhCw1dGFpELCFG3EhUz4CfxTK83R/a9KSfaLq4Fiq3H8BIbMLZkR8n?= =?us-ascii?Q?7+7GuXAc4Hq+bNN1AXnTBFsxwaZTGDBeIhLgg0yz9wXrMVHqed7+E3F2ebfN?= =?us-ascii?Q?l4faYXNW4lKcmgQxYo/KPYpEych3Zw=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB3590; 6:ECXCeVHPfsIrVSQdVDNnyQf8ViR1LGyVEVACb8NyMiy6mWOtbYJw3cjG74a6PoW0w0KVHqIBEtGysWEM8WN4IiGcXDwuJcMS7/3wkmydZ93/wNUhdmtGqI8AfX0YurxpCEqtYQ6C8JE+KDkToeTJvZ8gM32BfFfBZXtspyvkY559VIGHWwCwngaIkbE6T2QhoTJqbqhduBaJyo0hkUY5nn+krRcnmljlSvHlpuvP1ngkVRxeAKbU1iZpVhSH2B7k1nG5++xmnq0r1Zi3VXfrha3COP0SbnnMua+sQwV5nfvZ9lkUhAb94zwxVFff5U3k6Kd3E+OgqXMTZ+42G7XxypYRPfkrFl5+pRpbuY1SnzI=; 5:/KWlsyA0+xECNoilGxoYG/A4n4z+IRYN/BX0ZKZUKkqlqGkOLRhfeOsnh1aqm6d/AqGJ07EI0lqTXMxO67DNccz8ByrwlMjt8BPjKfzKflEtxzkJnROAYajBk4GOkZIviiXjoMj8hIYEEuY2lkZF6eMF6U1JY1+PW2Xm3d+nuTA=; 24:HNAivWjPGknkjUqmaJ1UyG0WUwhThcVSCUPOxFaKeinyeicSK0N1u/Y5pz12jjIHgSJzvj1EsGx3ilDn0tehgbY8lJSLJW9Z8ixg7JckGRc=; 7:a/SjuzZY6VW1UiU/pWBqIvxUGprOCpyY6p5GP9bYH/Czkl/4cj9aUGpnAIJkvP9J3No6wjukjWJyFhX10jK5guxhavSe+tEAy4nozqDaSHvnnD7MegGaCu5rmsAcSDTUECkyor4o6RZ4VSSsHYwJPQOVn7Zq/vdfHbroEP9oV6COrYrmDVYv/A8kVPUkbtmJ5c+orglrPcHIYcAOISC2Oy9vBVuL/+UYe/MirmMtq3l4Y/SlEE+J7F1NU12WIN6+ SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Oct 2017 19:01:25.5822 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: fd1ee498-6577-4780-2553-08d52091c905 X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.172.38]; Helo=[plsapdm2.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB3590 Archived-At: Subject: Re: [Dime] draft-avasarala-diameter-error-invalid-identity-00 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 19:02:26 -0000 --_000_0cc48ec93fd94822a8ca43e1861f44caplswe13m04adsprintcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ty From: AVASARALA, RANJIT KUMAR [mailto:ra698k@att.com] Sent: Tuesday, October 31, 2017 1:57 PM To: Bertz, Lyle T [CTO] ; Yuval Lifshitz ; dime@ietf.org Subject: RE: draft-avasarala-diameter-error-invalid-identity-00 Hi Lyle Answers inline Regards Ranjit VoLTE T4 Support 317-224-9441 From: Bertz, Lyle T [CTO] [mailto:Lyle.T.Bertz@sprint.com] Sent: Tuesday, October 31, 2017 1:46 PM To: AVASARALA, RANJIT KUMAR >; Yuval = Lifshitz >; dime@ietf= .org 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 som= ewhere else. 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 cor= e. 1. When you say invalid in the spec you reference format. If it is form= at that is doable but if it is questioning data / associations outside of t= he AVP or message then this is problematic. An invalid value in the propo= sal is too vague. Was it a well formed AVP which did not pass some app leve= l semantic check or was it just bad data? 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 C= CF that receives the IMEI should validate the IMEI (which the CCFs currentl= y 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? not association - but the value itself. Technically IMEI and IMEI= SV are same (except for additional value of SV) Lyle From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of AVASARALA, RANJIT KU= MAR Sent: Tuesday, October 31, 2017 1:08 PM To: Yuval Lifshitz >;= dime@ietf.org 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 enti= ty 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 IM= EI 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 reco= rds 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 ent= ity receiving the error has an option to re-send the request with a valid v= alue if it can. Regards Ranjit VoLTE T4 Support 317-224-9441 From: Yuval Lifshitz [mailto:ylifshitz@sandvine.com] Sent: Tuesday, October 31, 2017 12:07 PM To: AVASARALA, RANJIT KUMAR >; dime@i= etf.org Cc: ben@nostrum.com; Yuval Lifshitz > 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 i= s DIAMETER_INVALID_AVP_VALUE (5004) * 3xxx level error codes are meant for peer level (per hop) while the c= ase 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 fo= rcing the credit control server to validate it would contradict the existin= g specification Best Regards, Yuval From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of AVASARALA, RANJIT KU= MAR Sent: Tuesday, October 31, 2017 6:32 PM To: dime@ietf.org Cc: ben@nostrum.com Subject: [Dime] draft-avasarala-diameter-error-invalid-identity-00 Hello all We published a new Internet draft addressing the issue of invalid IMEI in S= IP / 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-Equ= ipment-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 genera= tion that eventually lead to generation of CDRs. So in scenarios where IME= I 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 in= consistency in billing. So there is a need to reduce or prevent the generation of bad records and t= his can be done by validating the received IMEI and reporting invalid insta= nces 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-diame= ter-error-invalid-identity-00.html Regards Ranjit ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e 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. --_000_0cc48ec93fd94822a8ca43e1861f44caplswe13m04adsprintcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From: AVASARALA, RANJIT KUMAR [mailt= o:ra698k@att.com]
Sent: Tuesday, October 31, 2017 1:57 PM
To: Bertz, Lyle T [CTO] <Lyle.T.Bertz@sprint.com>; Yuval Lifsh= itz <ylifshitz@sandvine.com>; dime@ietf.org
Subject: RE: draft-avasarala-diameter-error-invalid-identity-00=

Hi Lyle

Answers inline <Ranjit>

Regards

Ranjit

VoLTE T4 Support

317-224-9441

From: Bertz, Lyle T [CTO] [mailto:Lyle.T.Bertz@sprint.com]
Sent: Tuesday, October 31, 2017 1:46 PM
To: AVASARALA, RANJIT KUMAR <ra= 698k@att.com>; Yuval Lifshitz <ylifshitz@sandvine.com>; dime@ietf.org
Subject: RE: draft-avasarala-diameter-error-invalid-identity-00=

A few questions:

Ho= w did a CTF get and invalid IMEI? It is typically pulling from somewh= ere else.

<Ranjit> invalid iMEI can come from dev= ices reporting invalid IMEI value. This IMEI value comes from device = to MME to PGW and all the way to IMS core.

Wh= en 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 inv= alid 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?=

Is= this a IMSI-IMEI(SV) association issue?

<Ranjit> not association – but the valu= e itself. Technically IMEI and IMEISV are same (except for additional= value of SV)

Lyle

Hi Yuval

Thank you for the comments.

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.

Regards

Ranjit

VoLTE T4 Support

317-224-9441

Dear Ranjit,

I think there are several issues with= your proposal:

A = standard diameter error already exists for the case described. It is DIAMET= ER_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 contr= adict the existing specification

Best Regards,

Yuval

Hello all

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

Here is the background

So there is a need to reduce or prevent the generat= ion 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, th= is draft proposes a new diameter protocol error code – DIAMETER_INVAL= ID_MOBILE_IDENTITY

We request everyone to review the draft and comment= .

The URL of the draft is - https://tools.ietf.org/html/draft-avasarala-d= iameter-error-invalid-identity-00.html

Regards

Ranjit

--_000_0cc48ec93fd94822a8ca43e1861f44caplswe13m04adsprintcom_-- From nobody Tue Oct 31 23:33:44 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2753613FDA2 for ; Tue, 31 Oct 2017 23:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.07 X-Spam-Level: X-Spam-Status: No, score=0.07 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HxXf6X3PO8JK for ; Tue, 31 Oct 2017 23:33:38 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83EFF13FDB6 for ; Tue, 31 Oct 2017 23:33:38 -0700 (PDT) Received: from WTL-EXCHSV2-1.sandvine.com (192.168.194.58) by WTL-EXCHSV2-1.sandvine.com (192.168.194.58) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.26; Wed, 1 Nov 2017 02:33:37 -0400 Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by WTL-EXCHSV2-1.sandvine.com (192.168.194.58) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1034.26 via Frontend Transport; Wed, 1 Nov 2017 02:33:37 -0400 Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by blr-exchp-2.sandvine.com ([::1]) with mapi id 14.03.0319.002; Wed, 1 Nov 2017 02:33:36 -0400 From: Yuval Lifshitz To: "Bertz, Lyle T [CTO]" , "AVASARALA, RANJIT KUMAR" , "dime@ietf.org" CC: "Gardella, Maryse (Nokia - FR) (maryse.gardella@nokia.com)" , Yuval Lifshitz Thread-Topic: draft-avasarala-diameter-error-invalid-identity-00 Thread-Index: AdNSZIrJm2O1lnw9Q5e+yrjpjtgOFgABIxwgAAJK+5AAAKJMwAABIT8wAABUNKAAF7UloA== Date: Wed, 1 Nov 2017 06:33:36 +0000 Message-ID: References:

<62823085c481447e95e17e4e62c6ce8c@plswe13m04.ad.sprint.com> <0cc48ec93fd94822a8ca43e1861f44ca@plswe13m04.ad.sprint.com> In-Reply-To: <0cc48ec93fd94822a8ca43e1861f44ca@plswe13m04.ad.sprint.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.142.2] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_C43C255C7106314F8D13D03FA20CFE49ED569963wtlexchp1sandvi_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dime] draft-avasarala-diameter-error-invalid-identity-00 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 06:33:42 -0000 --_000_C43C255C7106314F8D13D03FA20CFE49ED569963wtlexchp1sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ranjit, Please look at section 7.1.17 (page 99) of the 3GPP/ETSI Gy specification: = http://www.etsi.org/deliver/etsi_ts/132200_132299/132299/14.05.00_60/ts_132= 299v140500p.pdf In that document (which is based on RFC4006) they are specifically addressi= ng the case where User-Equipment-Info is of type IMEI/SV, as well as noting= on the validation of that AVP. Please note that in the specification above, section 7.1.11 (pages 96-97), = domain specific, result codes were added. Would probably be good to propose= the new result code as an enhancement for that spec? This could be a 5xxx or 4xxx result code, depending whether you think that = a retry would resolve the issue. If you think that that would be the way fo= rward with that issue, I would recommend addressing the 3GPP SA5 work group= . Best Regards, Yuval From: Bertz, Lyle T [CTO] [mailto:Lyle.T.Bertz@sprint.com] Sent: Tuesday, October 31, 2017 9:01 PM To: AVASARALA, RANJIT KUMAR; Yuval Lifshitz; dime@ietf.org Subject: RE: draft-avasarala-diameter-error-invalid-identity-00 ty From: AVASARALA, RANJIT KUMAR [mailto:ra698k@att.com] Sent: Tuesday, October 31, 2017 1:57 PM To: Bertz, Lyle T [CTO] >; Yuval Lifshitz >; dime@ietf.org Subject: RE: draft-avasarala-diameter-error-invalid-identity-00 Hi Lyle Answers inline Regards Ranjit VoLTE T4 Support 317-224-9441 From: Bertz, Lyle T [CTO] [mailto:Lyle.T.Bertz@sprint.com] Sent: Tuesday, October 31, 2017 1:46 PM To: AVASARALA, RANJIT KUMAR >; Yuval = Lifshitz >; dime@ietf= .org 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 som= ewhere else. 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 cor= e. 1. When you say invalid in the spec you reference format. If it is form= at that is doable but if it is questioning data / associations outside of t= he AVP or message then this is problematic. An invalid value in the propo= sal is too vague. Was it a well formed AVP which did not pass some app leve= l semantic check or was it just bad data? 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 C= CF that receives the IMEI should validate the IMEI (which the CCFs currentl= y 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? not association - but the value itself. Technically IMEI and IMEI= SV are same (except for additional value of SV) Lyle From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of AVASARALA, RANJIT KU= MAR Sent: Tuesday, October 31, 2017 1:08 PM To: Yuval Lifshitz >;= dime@ietf.org 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 enti= ty 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 IM= EI 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 reco= rds 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 ent= ity receiving the error has an option to re-send the request with a valid v= alue if it can. Regards Ranjit VoLTE T4 Support 317-224-9441 From: Yuval Lifshitz [mailto:ylifshitz@sandvine.com] Sent: Tuesday, October 31, 2017 12:07 PM To: AVASARALA, RANJIT KUMAR >; dime@i= etf.org Cc: ben@nostrum.com; Yuval Lifshitz > 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 i= s DIAMETER_INVALID_AVP_VALUE (5004) * 3xxx level error codes are meant for peer level (per hop) while the c= ase 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 fo= rcing the credit control server to validate it would contradict the existin= g specification Best Regards, Yuval From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of AVASARALA, RANJIT KU= MAR Sent: Tuesday, October 31, 2017 6:32 PM To: dime@ietf.org Cc: ben@nostrum.com Subject: [Dime] draft-avasarala-diameter-error-invalid-identity-00 Hello all We published a new Internet draft addressing the issue of invalid IMEI in S= IP / 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-Equ= ipment-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 genera= tion that eventually lead to generation of CDRs. So in scenarios where IME= I 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 in= consistency in billing. So there is a need to reduce or prevent the generation of bad records and t= his can be done by validating the received IMEI and reporting invalid insta= nces 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-diame= ter-error-invalid-identity-00.html Regards Ranjit ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e 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. --_000_C43C255C7106314F8D13D03FA20CFE49ED569963wtlexchp1sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ranjit,

Please look at section 7.= 1.17 (page 99) of the 3GPP/ETSI Gy specification: http://www.etsi.org/deliver/etsi_ts/132200_132299/132299/14.05.00_60/ts_132= 299v140500p.pdf

In that document (which i= s based on RFC4006) they are specifically addressing the case where User-Eq= uipment-Info is of type IMEI/SV, as well as noting on the validation of that AVP.

Please note that in the s= pecification above, section 7.1.11 (pages 96-97), domain specific, result c= odes were added. Would probably be good to propose the new result code as an enhancement for that spec?

This could be a 5xxx or 4= xxx result code, depending whether you think that a retry would resolve the= issue. If you think that that would be the way forward with that issue, I would recommend addressing the 3GPP SA5 work group.

<= /p>

Best Regards,<= /span>

<= /p>

Yuval

<= /p>

From: Bertz, L= yle T [CTO] [mailto:Lyle.T.Bertz@sprint.com]
Sent: Tuesday, October 31, 2017 9:01 PM
To: AVASARALA, RANJIT KUMAR; Yuval Lifshitz; dime@ietf.org
Subject: RE: draft-avasarala-diameter-error-invalid-identity-00=

<= /p>

From: AVASAR= ALA, RANJIT KUMAR [mailto:ra698k@att.com<= /a>]
Sent: Tuesday, October 31, 2017 1:57 PM
To: Bertz, Lyle T [CTO] <Lyle.T.Bertz@sprint.com>; Yuval Lifshitz <ylifshitz@sandvine.com>; dime@ietf.org
Subject: RE: draft-avasarala-diameter-error-invalid-identity-00=

Hi Lyle

Answers inline <Ranjit>

Regards

Ranjit

VoLTE T4 Support

317-224-9441

From: Bertz,= Lyle T [CTO] [mailto:Lyle.T.Ber= tz@sprint.com]
Sent: Tuesday, October 31, 2017 1:46 PM
To: AVASARALA, RANJIT KUMAR <ra= 698k@att.com>; Yuval Lifshitz <ylifshitz@sandvine.com>; dime@ietf.org
Subject: RE: draft-avasarala-diameter-error-invalid-identity-00=

A few questions:

<= /p>

How did a CTF get and invalid IMEI? It is typically pulling= from somewhere else.

<Ranjit> invalid iMEI can c= ome from devices reporting invalid IMEI value. This IMEI value comes = from device to MME to PGW and all the way to IMS core.

When you say invalid in the spec you reference format. If i= t is format that is doable but if it is questioning data / associations outside of the AVP or message then this is problematic. An inv= alid 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 d= ata 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 t= hey do, and if they determine that the IMEI is invalid, then they should in= sert the error code into Diameter response (E.g. CCA).

Is this a IMSI-IMEI(SV) association issue?

<Ranjit> not association – = but the value itself. Technically IMEI and IMEISV are same (except fo= r additional value of SV)

<= /p>

Lyle

<= /p>

From: DiME [= mailto:dime-bounces@ietf.org] On Behalf Of AVASARALA, RANJIT KUMAR
Sent: Tuesday, October 31, 2017 1:08 PM
To: Yuval Lifshitz <yli= fshitz@sandvine.com>; dime@ietf.org
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 mob= ile 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 t= he 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 t= he 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 i= nvalid IMEI – the number of bad records being generated is increasing= – so need a way to prevent those.

So the proposed solution is for the ent= ities 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:ylifshitz@sandvi= ne.com]
Sent: Tuesday, October 31, 2017 12:07 PM
To: AVASARALA, RANJIT KUMAR <ra= 698k@att.com>; dime@ietf.org
Cc: ben@nostrum.com; Yuval Li= fshitz <ylifshitz@sandvine.com= >
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)
3xx= x level error codes are meant for peer level (per hop) while the case you d= escribe is session level (end 2 end)
User-E= quipment-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

<= /p>

Best Regards,<= /span>

<= /p>

Yuval

<= /p>

Hello all

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

Here is the background

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

So in order to report the cases of inva= lid iMEI, this draft proposes a new diameter protocol error code – DI= AMETER_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-d= iameter-error-invalid-identity-00.html

Regards

Ranjit

--_000_C43C255C7106314F8D13D03FA20CFE49ED569963wtlexchp1sandvi_--