From nobody Mon Oct 16 09:59:41 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 400691321C9 for ; Mon, 16 Oct 2017 09:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.519 X-Spam-Level: X-Spam-Status: No, score=-0.519 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, 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 PiLZfsyR2ah8 for ; Mon, 16 Oct 2017 09:59:39 -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 CC16B1320B5 for ; Mon, 16 Oct 2017 09:59:38 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([fe80::3c39:d305:d721:f00a%15]) with mapi id 14.03.0319.002; Mon, 16 Oct 2017 12:59:37 -0400 From: Dave Dolson To: "dime@ietf.org list" Thread-Topic: rfc4006bis Thread-Index: AdNGn9+Lmq1jYc7kS8KpvmDxZ+14Iw== Date: Mon, 16 Oct 2017 16:59:36 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.114] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E98A911FEC2wtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Subject: [Dime] rfc4006bis 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: Mon, 16 Oct 2017 16:59:40 -0000 --_000_E8355113905631478EFF04F5AA706E98A911FEC2wtlexchp2sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable What is required to finish this off? There are no issues in https://github.com/lbertz02/rfc4006bis David Dolson Senior Software Architect Sandvine --_000_E8355113905631478EFF04F5AA706E98A911FEC2wtlexchp2sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

What is required to finish this off?

There are no issues in https://github.com/lbertz02/rfc4006bis

 

 

David Dolson

Senior Software Architect

Sandvine

 

--_000_E8355113905631478EFF04F5AA706E98A911FEC2wtlexchp2sandvi_-- From nobody Sun Oct 22 11:16:49 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 5F01E13A428 for ; Sun, 22 Oct 2017 11:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 7PBpuBX_wEyn for ; Sun, 22 Oct 2017 11:16:46 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BF9E13A427 for ; Sun, 22 Oct 2017 11:16:46 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id a132so17792464lfa.7 for ; Sun, 22 Oct 2017 11:16:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=j4yJ4JYtGyGj19JuhgA9sc9hhQeP4p/mJEySNH7YitM=; b=q0/vMcVaVPLnWkD906Bk+rPlIHk6TSAXBRCRWxGOskrFIXu5bdAgKNk0w5NomTUBzj lM6ChZ9NYEl/eT47MOFADZrOVDjtuuj026fr/rV3G30e/BkUPMUbJmyYI5uTsZZa8li/ scrE494pGNB1BCMA5iCrjq40jAjfJ97DBp1ZtgiDLueaZSDNi1M608PEuN4mXqfIxbNy 2x0AEPxatgrG+D3sQZQdgYGGvsw2K7XwN01/Azmatt6iJhrmkpGh4LPjr886hKJwO5eu oUH2kd88evlQbjjxpnGn5YohQAdvjDbgUuT0CVUNMxdci8oC4NK2nZaURMTxpzhFA10L W+OA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=j4yJ4JYtGyGj19JuhgA9sc9hhQeP4p/mJEySNH7YitM=; b=KCHznrlNWoUmurwv1O/bjr86btxYAp255AXr4WF1Q8k1f6Hj3AbqZLC6Em05jA/IFD NEtbaXbomM+cmjlJv1EtwUzgUS2QWY1NJ/SdKqV1ij7xav4N5j/cEJxz1fHSS3RhOtur lw4vwz0wsj+qEo0Qw/5EMU0gI/0rD3iCmfqKBNUE5Qa2XWfDjPY1dHfP6N6le+ssearG 3Wxz0/ioBXz9+B1pJ+026WG1bosIPUj8a4xEsW52pLEvb7Eoj3vbGc/0z8VaVAtbWxQD WqaGrK06lQ5Ar7L6lrkecyzOIkJRvwFwrkgYaKW++MO2FFGY4cpIlU+wMP0pb6BrKXJz Mn7g== X-Gm-Message-State: AMCzsaW0MJlDImWpEew4Sei0kjiDTI4WSy+kzYx9S6kevBlJeXG+BDuj Pl9afHU9Wc+XbreoB9JAg9i1XZIz X-Google-Smtp-Source: ABhQp+RDnbbCgyATJzBeUUUnd37bHcglxdUeW+tpatBlMzHhCjg/IEXd4166Gf0uQPgyNdiB6GnwNg== X-Received: by 10.25.76.212 with SMTP id z203mr3052739lfa.39.1508696204803; Sun, 22 Oct 2017 11:16:44 -0700 (PDT) Received: from jounis-imac.home ([83.150.126.201]) by smtp.gmail.com with ESMTPSA id 13sm1349602ljv.10.2017.10.22.11.16.43 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 22 Oct 2017 11:16:44 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Jouni In-Reply-To: Date: Sun, 22 Oct 2017 21:16:38 +0300 Cc: "dime@ietf.org list" Content-Transfer-Encoding: quoted-printable Message-Id: <07E16CFB-DAF9-40A4-A5BD-6313BB81BEF3@gmail.com> References: To: Dave Dolson X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [Dime] rfc4006bis 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: Sun, 22 Oct 2017 18:16:48 -0000 Hi Dave, Okay great. Could you also close the open tickets in Issue Tracker if = they are solved. Other than that if the authors think the document is ready just ask for = publication and we=E2=80=99ll start a WGLC. - Jouni > On 16 Oct 2017, at 19:59, Dave Dolson wrote: >=20 > What is required to finish this off? > There are no issues in https://github.com/lbertz02/rfc4006bis > =20 > =20 > David Dolson > Senior Software Architect > Sandvine > =20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Tue Oct 24 02:30:45 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 0CFF413F151 for ; Tue, 24 Oct 2017 02:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.021 X-Spam-Level: X-Spam-Status: No, score=-0.021 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 snY-Cf7HOGwK for ; Tue, 24 Oct 2017 02:30:41 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C2EE13F3C4 for ; Tue, 24 Oct 2017 02:30:26 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa%18]) with mapi id 14.03.0319.002; Tue, 24 Oct 2017 05:30:24 -0400 From: Dave Dolson To: Jouni CC: "dime@ietf.org list" Thread-Topic: [Dime] rfc4006bis Thread-Index: AdNGn9+Lmq1jYc7kS8KpvmDxZ+14IwE445QAAEnNfzA= Date: Tue, 24 Oct 2017 09:30:23 +0000 Message-ID: References: <07E16CFB-DAF9-40A4-A5BD-6313BB81BEF3@gmail.com> In-Reply-To: <07E16CFB-DAF9-40A4-A5BD-6313BB81BEF3@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.153.91.22] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dime] rfc4006bis 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, 24 Oct 2017 09:30:44 -0000 VGhlIGlzc3VlcyBhcmUgcmVzb2x2ZWQgaW4gdGhlIGxhdGVzdCB2ZXJzaW9uLg0KV2UgcmVxdWVz dCBwdWJsaWNhdGlvbi4NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSm91 bmkgW21haWx0bzpqb3VuaS5ub3NwYW1AZ21haWwuY29tXSANClNlbnQ6IFN1bmRheSwgT2N0b2Jl ciAyMiwgMjAxNyA4OjE3IFBNDQpUbzogRGF2ZSBEb2xzb24NCkNjOiBkaW1lQGlldGYub3JnIGxp c3QNClN1YmplY3Q6IFJlOiBbRGltZV0gcmZjNDAwNmJpcw0KDQpIaSBEYXZlLA0KDQpPa2F5IGdy ZWF0LiBDb3VsZCB5b3UgYWxzbyBjbG9zZSB0aGUgb3BlbiB0aWNrZXRzIGluIElzc3VlIFRyYWNr ZXIgaWYgdGhleSBhcmUgc29sdmVkLg0KT3RoZXIgdGhhbiB0aGF0IGlmIHRoZSBhdXRob3JzIHRo aW5rIHRoZSBkb2N1bWVudCBpcyByZWFkeSBqdXN0IGFzayBmb3IgcHVibGljYXRpb24gYW5kIHdl 4oCZbGwgc3RhcnQgYSBXR0xDLg0KDQotIEpvdW5pDQoNCg0KPiBPbiAxNiBPY3QgMjAxNywgYXQg MTk6NTksIERhdmUgRG9sc29uIDxkZG9sc29uQHNhbmR2aW5lLmNvbT4gd3JvdGU6DQo+IA0KPiBX aGF0IGlzIHJlcXVpcmVkIHRvIGZpbmlzaCB0aGlzIG9mZj8NCj4gVGhlcmUgYXJlIG5vIGlzc3Vl cyBpbiBodHRwczovL2dpdGh1Yi5jb20vbGJlcnR6MDIvcmZjNDAwNmJpcw0KPiAgDQo+ICANCj4g RGF2aWQgRG9sc29uDQo+IFNlbmlvciBTb2Z0d2FyZSBBcmNoaXRlY3QNCj4gU2FuZHZpbmUNCj4g IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBE aU1FIG1haWxpbmcgbGlzdA0KPiBEaU1FQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vZGltZQ0KDQo= From nobody Thu Oct 26 12:29:47 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 B237913F5EF for ; Thu, 26 Oct 2017 12:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 gjSKu9URXEfE for ; Thu, 26 Oct 2017 12:29:43 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AB8D13F5EB for ; Thu, 26 Oct 2017 12:29:43 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id l23so4948428lfk.10 for ; Thu, 26 Oct 2017 12:29:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gyUubClsHUCGX0Gsofm2o/rdJ2cimttHKR7vUkKJSvY=; b=oSLUW5u9l1svqhTDW1Mgczr/W5UCj0Fy+jF7lUQDt+AhAhHSHce1wGwrOly8KhINMB 8Z/wkg7FH1QrVNoFkrRNqzuBGw5gm6K0jOYpVgoCaRN2TVLhyX7tDZHRZruOKcpJ2PBc qdRD0r/iGzYo5tc/WvvePIdLlglzSwy/M96WEl4NGvEg0FJ+SiqKJ1r9ie0+yn7VyVGM DWwvvt3yoLmjlW5co9trnosJrtY+q1GBBCcQJ0GYuA8UQKHVf3QR2jRtvRD6ipDlTg5e GF1JhJSJo0F1UFRokBK20gySz543FXxm6soC/dLTKQle3eVKcC/3xRfJdtg7zwAu9aQM vhjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gyUubClsHUCGX0Gsofm2o/rdJ2cimttHKR7vUkKJSvY=; b=BaAIdqVbWaFkxRQTnX7NXT/9d7zkR5A95PlcyHhOvsIqgS4/WC+YJ0WJH6KDCS6p7A fAfPV1K3grnBp26Wlk/XT5Vq0fyDV7iQ12KJ+NP6liZunIWNgrsBhOwdv4E78dwKRQhi sHiW3ofL+w6L2B48vAkI/V224OKzJGGn2H286hPbRfDje+6BxL/Jz97BYtKlNdc27AXX DNryRxBptVOyEhnrfYT9Daxbyww/v5vUKNfulJBJe6CBwXCAAAlbvixiS9oh3RksbRDk 9opE7JDUz6CZQrVnRBkDB6k908F3Bjj/paQMMEtw06GZCiM0QjvFkb92ehBQa0aiC9L5 JQQA== X-Gm-Message-State: AMCzsaUDQt9gUwt3BYsL7K49tU3UykCzh3eQa/yuObK+aTUlNmzcQrr+ wvkXGV4+DFonF/Zsc+6bWiNR/CGL X-Google-Smtp-Source: ABhQp+TVcopRP8H27WOXMtjQW5ixUVz43WZB0P0oy7DNMo3f2XcLWlEhnwwyhN3mXTpUn8NUdLvE/A== X-Received: by 10.25.23.214 with SMTP id 83mr8269549lfx.213.1509046181849; Thu, 26 Oct 2017 12:29:41 -0700 (PDT) Received: from jounis-imac.home ([83.150.126.201]) by smtp.gmail.com with ESMTPSA id q192sm1588924ljb.5.2017.10.26.12.29.40 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 26 Oct 2017 12:29:40 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Jouni In-Reply-To: Date: Thu, 26 Oct 2017 22:29:39 +0300 Cc: "dime@ietf.org list" Content-Transfer-Encoding: quoted-printable Message-Id: <37480551-698C-4250-AD3F-530147873FF9@gmail.com> References: <07E16CFB-DAF9-40A4-A5BD-6313BB81BEF3@gmail.com> To: Dave Dolson X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [Dime] rfc4006bis 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: Thu, 26 Oct 2017 19:29:46 -0000 Hi, OK. We=E2=80=99ll do one very quick WGLC round (1 week) and then go to = publication process if there is no issues. - Jouni > On 24 Oct 2017, at 12:30, Dave Dolson wrote: >=20 > The issues are resolved in the latest version. > We request publication. >=20 >=20 > -----Original Message----- > From: Jouni [mailto:jouni.nospam@gmail.com]=20 > Sent: Sunday, October 22, 2017 8:17 PM > To: Dave Dolson > Cc: dime@ietf.org list > Subject: Re: [Dime] rfc4006bis >=20 > Hi Dave, >=20 > Okay great. Could you also close the open tickets in Issue Tracker if = they are solved. > Other than that if the authors think the document is ready just ask = for publication and we=E2=80=99ll start a WGLC. >=20 > - Jouni >=20 >=20 >> On 16 Oct 2017, at 19:59, Dave Dolson wrote: >>=20 >> What is required to finish this off? >> There are no issues in https://github.com/lbertz02/rfc4006bis >>=20 >>=20 >> David Dolson >> Senior Software Architect >> Sandvine >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 From nobody Tue Oct 31 09:32:26 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 2DEE313F949 for ; Tue, 31 Oct 2017 09:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 7aseH6ZAeecA for ; Tue, 31 Oct 2017 09:32:22 -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 027FE13F95F for ; Tue, 31 Oct 2017 09:32:21 -0700 (PDT) Received: from pps.filterd (m0083689.ppops.net [127.0.0.1]) by m0083689.ppops.net-00191d01. (8.16.0.21/8.16.0.21) with SMTP id v9VGHLFH021531; Tue, 31 Oct 2017 12:32:19 -0400 Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by m0083689.ppops.net-00191d01. with ESMTP id 2dxr8uuhvu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 31 Oct 2017 12:32:19 -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 v9VGWI1a010689; Tue, 31 Oct 2017 11:32:18 -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 v9VGWDqP010638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 31 Oct 2017 11:32:14 -0500 Received: from MOSTLS1MSGHUBAG.ITServices.sbc.com (MOSTLS1MSGHUBAG.itservices.sbc.com [135.41.4.154]) by dalint01.pst.cso.att.com (RSA Interceptor); Tue, 31 Oct 2017 16:32:10 GMT Received: from MOSTLS1MSGUSRFG.ITServices.sbc.com ([169.254.7.170]) by MOSTLS1MSGHUBAG.ITServices.sbc.com ([135.41.4.154]) with mapi id 14.03.0361.001; Tue, 31 Oct 2017 11:32:10 -0500 From: "AVASARALA, RANJIT KUMAR" To: "dime@ietf.org" CC: "DOLLY, MARTIN C" , "ben@nostrum.com" Thread-Topic: draft-avasarala-diameter-error-invalid-identity-00 Thread-Index: AdNSZIrJm2O1lnw9Q5e+yrjpjtgOFg== Date: Tue, 31 Oct 2017 16:32:08 +0000 Message-ID: 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_BD15502709C85D4DAA2DCBF30D38A3B7172894DCMOSTLS1MSGUSRFG_" 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_06:, , 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-1710310203 Archived-At: Subject: [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 16:32:24 -0000 --_000_BD15502709C85D4DAA2DCBF30D38A3B7172894DCMOSTLS1MSGUSRFG_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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_BD15502709C85D4DAA2DCBF30D38A3B7172894DCMOSTLS1MSGUSRFG_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
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 i= s 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 g= eneration 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 bi= lling.
 
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<= /div>
 
We request everyone to review the draft and comment.
 
 
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.

 

 

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

 

 

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.

 

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

 

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

 

 

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:

 

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

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

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

 

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

 

 

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

ty

 

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:

 

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

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

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

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

 

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

 

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

 

 

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

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

 

ty

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

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

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

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

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

 

 

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