From ecrit-bounces@ietf.org Thu Sep 11 08:03:03 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF6463A684F; Thu, 11 Sep 2008 08:03:03 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D607A3A693C for ; Thu, 11 Sep 2008 08:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZ5oiuuxayRY for ; Thu, 11 Sep 2008 08:02:59 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [85.30.129.39]) by core3.amsl.com (Postfix) with ESMTP id 690903A6BD9 for ; Thu, 11 Sep 2008 08:02:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id A6B3420F615B; Thu, 11 Sep 2008 17:02:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J9HyqBk6IW95; Thu, 11 Sep 2008 17:02:45 +0200 (CEST) Received: from [172.16.35.222] (64-103-25-233.cisco.com [64.103.25.233]) by srv01.frobbit.se (Postfix) with ESMTP id 2064E20F6148; Thu, 11 Sep 2008 17:02:45 +0200 (CEST) Message-Id: From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: ECRIT , Fred Baker Mime-Version: 1.0 (Apple Message framework v928.1) Date: Thu, 11 Sep 2008 17:02:44 +0200 References: <79721BC6592A523331B68181@p3.JCK.COM> X-Mailer: Apple Mail (2.928.1) Subject: [Ecrit] Fwd: ETSI defining ASN.1 (with derived XML schema) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org John correctly suggest I send this message also to you. I am looking = for people involved in the ETSI work with definition of interface = between LEA and providers of services that has retained data according = to for example the European Data Retention Directive. Patrik Begin forwarded message: > From: John C Klensin > Date: to 11 sep 2008 16.54.42 GMT+02:00 > To: Patrik F=E4ltstr=F6m > Cc: apps-discuss@ietf.org, jon.peterson@neustar.biz > Subject: Re: ETSI defining ASN.1 (with derived XML schema) > > > > --On Thursday, 11 September, 2008 12:07 +0200 Patrik F=E4ltstr=F6m > wrote: > >> Is anyone working with the ETSI standard for how to transfer >> data between providers of services and law enforcement >> agencies when talking about data retention? >> >> They are defining an ASN.1 format of the data, and then they >> have the intention (as it seems) to derive an XML schema >> from it. When talking with ETSI, they are interested in >> getting help from IETF, and if someone is interested in >> helping, please help. I can help with contacts if you do not >> have any. >> >> > KeyWest/Docs/SA3LI07_080_DTS-LI-00033_V0.4.0._RD_HO.doc > > > Patrik, > > Did you also forward this to the ECRIT folks (and Fred)? If > not, please do so -- it would seem to me, at least in my > ignorance, that right way to approach this problem would be to > extend the ECRIT model to deal with this type of message, rather > than reinventing the wheel, much less by using ASN.1 as a > starting point. And there is already supposed to be a close > liaison relationship between ECRIT and ETSI. > > john > > >> >> Patrik >> >> _______________________________________________ >> Apps-Discuss mailing list >> Apps-Discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss > > > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 11 19:43:20 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC5533A68F5; Thu, 11 Sep 2008 19:43:20 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFE2C3A68F5 for ; Thu, 11 Sep 2008 19:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mf5ejG9h4oUm for ; Thu, 11 Sep 2008 19:43:19 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by core3.amsl.com (Postfix) with ESMTP id C22773A689F for ; Thu, 11 Sep 2008 19:43:18 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so367868fga.41 for ; Thu, 11 Sep 2008 19:43:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=2dAarulFeAlPhX38dtWSocX6cOF/9ccb7GUAxlkDAx4=; b=kxb//N6WpgEA+aXlYHxpVGkXKhA+SCpeQDuij5X1bnjN6FzOr1nec1UJiuKqkg6vKG I3dH9A7+75sXepoaC/RaIlX8zadtE9sB/6/p1U9thBCfDCQ/tosPKvOk6pXOL7jSumwZ c0DvXULBuoMybVuXNsxFpaYeOWFVyAWZDXm3Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=hxoBeuDxisOp5G445B+6U4hHKgU/sSyvjOIuNDafTAkenOkLM2FXWi+z2rYfMsZ+Lm 4s6QLeUTTpUY6JlKNujBDQAGuog9hMxc9L7Mj+MhlJCtFPnk/HKhWtb5GJePwKjbRCpq Ph5wQelt3EJKwxrNdWx8TK5DoIFP4RpjcDbas= Received: by 10.180.239.8 with SMTP id m8mr2895526bkh.48.1221187404949; Thu, 11 Sep 2008 19:43:24 -0700 (PDT) Received: by 10.180.205.3 with HTTP; Thu, 11 Sep 2008 19:43:24 -0700 (PDT) Message-ID: Date: Fri, 12 Sep 2008 10:43:24 +0800 From: "Raman Chan" To: ecrit@ietf.org MIME-Version: 1.0 Subject: [Ecrit] Security Threat in Emergency Call System X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0393761046==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org --===============0393761046== Content-Type: multipart/alternative; boundary="----=_Part_40717_14973334.1221187404943" ------=_Part_40717_14973334.1221187404943 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, In RFC5069,section 6. "the service provider's call routing entity MUST verify that the destination address (e.g., SIP Request-URI) presented in the call signalling is that of a PSAP. " How to judge a URI is a PSAP-URI at the proxy side? Is there any protocol to verify the URI, or the proxy just also issue another LoST query and compare the result URI with request-URI? Thanks Raman ------=_Part_40717_14973334.1221187404943 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi,
In RFC5069,section 6.
  "the service provider's call routing entity MUST verify
     that the destination address (e.g., SIP Request-URI) presented in the
     call signalling is that of a PSAP. "
 
How to judge a URI is a PSAP-URI at the proxy side?
Is there any protocol to verify the URI, or the proxy just also issue another LoST query and compare the result URI with request-URI?
 
Thanks
Raman
------=_Part_40717_14973334.1221187404943-- --===============0393761046== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --===============0393761046==-- From ecrit-bounces@ietf.org Thu Sep 11 22:47:59 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10E5C3A6B17; Thu, 11 Sep 2008 22:47:59 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CB493A6B17 for ; Thu, 11 Sep 2008 22:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.996 X-Spam-Level: X-Spam-Status: No, score=-4.996 tagged_above=-999 required=5 tests=[AWL=1.603, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AsiLPggjGUND for ; Thu, 11 Sep 2008 22:47:56 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id A5A3B3A6B04 for ; Thu, 11 Sep 2008 22:47:55 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m8C5ltrk015730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Sep 2008 07:47:55 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m8C5ltvr016187; Fri, 12 Sep 2008 07:47:55 +0200 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Sep 2008 07:47:52 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.17]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Sep 2008 07:47:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 12 Sep 2008 08:47:50 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Security Threat in Emergency Call System Thread-Index: AckUgV4B+gZTa5qZQEuA2yt4QyzyngAGZIIQ References: From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Raman Chan" , X-OriginalArrivalTime: 12 Sep 2008 05:47:51.0940 (UTC) FILETIME=[18724C40:01C9149B] Subject: Re: [Ecrit] Security Threat in Emergency Call System X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org You would use LoST again to compare it. We have discussed reverse lookup mechanisms in the past as well but they seem to introduce complexity that isn't really necessary Ciao Hannes ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of ext Raman Chan Sent: 12 September, 2008 05:43 To: ecrit@ietf.org Subject: [Ecrit] Security Threat in Emergency Call System Hi, In RFC5069,section 6. "the service provider's call routing entity MUST verify that the destination address (e.g., SIP Request-URI) presented in the call signalling is that of a PSAP. " How to judge a URI is a PSAP-URI at the proxy side? Is there any protocol to verify the URI, or the proxy just also issue another LoST query and compare the result URI with request-URI? Thanks Raman _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 11 23:31:13 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9FEC3A6B5B; Thu, 11 Sep 2008 23:31:13 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E5FA28C0DC for ; Thu, 11 Sep 2008 23:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.191 X-Spam-Level: X-Spam-Status: No, score=-0.191 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qu2h5IoQ3FnA for ; Thu, 11 Sep 2008 23:31:12 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by core3.amsl.com (Postfix) with ESMTP id A8DC43A6B41 for ; Thu, 11 Sep 2008 23:31:11 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so412257fga.41 for ; Thu, 11 Sep 2008 23:31:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=e6lvWEnDeZy3k79owrpDr7yyG8fm4hFcIuDjfGQqyp0=; b=TX3uXVrvbxMu62lPU/qIxI+TUyMns2DnowKnGTUDbMPqLUMnIHEr86zVe1JdjoHiuE Rp7uKhY5UkRXax8mKfhX9t4jZ7y4OdqkPAjdtjKwJAqi4Ke/kz7YsMcujm9hNa+PcbMM pUnaRS4ue93Tl5u9fhLoVMRv2mA20n8UtmHC0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=pTU2dXHrQ7SESYiEgca7853cRoFdKt2+vf9QQZFIvWVhCJHwf4hCQKwhqo+mTOmv2g Uc9zjuQB2/O2VkpwNB9jl/cnhUNv2tEncNjUwUrFGjOIAxHpYVWPZp/mzZzOJGI8l1sM xWWPhvPSk1GqZUWLegPwaCFryzw8TRqe/YR7I= Received: by 10.180.245.6 with SMTP id s6mr2984573bkh.39.1221201077776; Thu, 11 Sep 2008 23:31:17 -0700 (PDT) Received: by 10.180.205.3 with HTTP; Thu, 11 Sep 2008 23:31:17 -0700 (PDT) Message-ID: Date: Fri, 12 Sep 2008 14:31:17 +0800 From: "Raman Chan" To: "Tschofenig, Hannes (NSN - FI/Espoo)" In-Reply-To: MIME-Version: 1.0 References: Cc: ecrit@ietf.org Subject: Re: [Ecrit] Security Threat in Emergency Call System X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1833598914==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org --===============1833598914== Content-Type: multipart/alternative; boundary="----=_Part_42246_23887079.1221201077773" ------=_Part_42246_23887079.1221201077773 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Ok,let't assume this scenario: I live in CityA,and the city's PSAP URI is psap_a@example.com My SIP client issued LoST query got the result and cached the URI. Some time later, I went to CityB,this city's PSAP URI is psap_b@example.com When I make emergency call,the LoST query expire due to some matter, the client have to use the cached URI, so the SIP-Invite contains Request-URI:psap_a@example.comand location of CityB, the VSP'proxy make LoST query with locaiton of CityB,get the URI psap_b@example.com, the proxy may reject my emergency call. Thanks Raman On Fri, Sep 12, 2008 at 1:47 PM, Tschofenig, Hannes (NSN - FI/Espoo) < hannes.tschofenig@nsn.com> wrote: > You would use LoST again to compare it. > We have discussed reverse lookup mechanisms in the past as well but they > seem to introduce complexity that isn't really necessary > > Ciao > Hannes > > > > ________________________________ > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > Behalf Of ext Raman Chan > Sent: 12 September, 2008 05:43 > To: ecrit@ietf.org > Subject: [Ecrit] Security Threat in Emergency Call System > > > Hi, > In RFC5069,section 6. > "the service provider's call routing entity MUST verify > that the destination address (e.g., SIP Request-URI) > presented in the > call signalling is that of a PSAP. " > > How to judge a URI is a PSAP-URI at the proxy side? > Is there any protocol to verify the URI, or the proxy just also > issue another LoST query and compare the result URI with request-URI? > > Thanks > Raman > > ------=_Part_42246_23887079.1221201077773 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Ok,let't assume this scenario:
I live in CityA,and the city's PSAP URI is psap_a@example.com
My SIP client issued LoST query got the result and cached the URI.
Some time later, I went to CityB,this city's PSAP URI is psap_b@example.com
When I make emergency call,the LoST query expire due to some matter,
the client have to use the cached URI,
so the SIP-Invite contains Request-URI:psap_a@example.com and location of CityB,
the VSP'proxy make LoST query with locaiton of CityB,get the URI psap_b@example.com,
the proxy may reject my emergency call.
 
Thanks
Raman

 
On Fri, Sep 12, 2008 at 1:47 PM, Tschofenig, Hannes (NSN - FI/Espoo) <hannes.tschofenig@nsn.com> wrote:
You would use LoST again to compare it.
We have discussed reverse lookup mechanisms in the past as well but they
seem to introduce complexity that isn't really necessary

Ciao
Hannes



________________________________

       From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On
Behalf Of ext Raman Chan
       Sent: 12 September, 2008 05:43
       To: ecrit@ietf.org
       Subject: [Ecrit] Security Threat in Emergency Call System


       Hi,
       In RFC5069,section 6.
         "the service provider's call routing entity MUST verify
            that the destination address (e.g., SIP Request-URI)
presented in the
            call signalling is that of a PSAP. "

       How to judge a URI is a PSAP-URI at the proxy side?
       Is there any protocol to verify the URI, or the proxy just also
issue another LoST query and compare the result URI with request-URI?

       Thanks
       Raman


------=_Part_42246_23887079.1221201077773-- --===============1833598914== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --===============1833598914==-- From ecrit-bounces@ietf.org Fri Sep 12 08:47:34 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01D3E28C16E; Fri, 12 Sep 2008 08:47:34 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C92928C16E for ; Fri, 12 Sep 2008 08:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.221 X-Spam-Level: X-Spam-Status: No, score=-0.221 tagged_above=-999 required=5 tests=[AWL=-0.841, BAYES_50=0.001, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rg8hbktlr3Kd for ; Fri, 12 Sep 2008 08:47:32 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 44C7828C15F for ; Fri, 12 Sep 2008 08:47:32 -0700 (PDT) Received: (qmail invoked by alias); 12 Sep 2008 15:47:38 -0000 Received: from unknown (EHLO [10.183.181.140]) [192.100.124.156] by mail.gmx.net (mp067) with SMTP; 12 Sep 2008 17:47:38 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18E611fQW0EvwxBJV+NACiP8IK6rq5CTsqaiCc5sU Mi4CeliUdZEyLO Message-ID: <48CA8F23.1080100@gmx.net> Date: Fri, 12 Sep 2008 18:47:47 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: 'ECRIT' X-Y-GMX-Trusted: 0 X-FuHaFi: 0.86 Subject: [Ecrit] IETF # 73 ECRIT Session X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org We have requested a 1 hour slot for the next meeting. If you think that this is not sufficient (or too long) please drop us a mail ASAP. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 12 14:27:45 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 472FB3A69AE; Fri, 12 Sep 2008 14:27:45 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC3153A69AE for ; Fri, 12 Sep 2008 14:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QTJg2J0Zx0Te for ; Fri, 12 Sep 2008 14:27:43 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 1418F3A6957 for ; Fri, 12 Sep 2008 14:27:43 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 12 Sep 2008 21:27:51 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m8CLRpFN008210; Fri, 12 Sep 2008 14:27:51 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m8CLRpDP010462; Fri, 12 Sep 2008 21:27:51 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Sep 2008 14:27:51 -0700 Received: from jmpolk-wxp01.cisco.com ([10.21.80.146]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Sep 2008 14:27:50 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 12 Sep 2008 16:28:04 -0500 To: "Raman Chan" , "Tschofenig, Hannes (NSN - FI/Espoo)" From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 12 Sep 2008 21:27:50.0758 (UTC) FILETIME=[68C2F860:01C9151E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2953; t=1221254871; x=1222118871; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20Security=20Threat=20in=20Emer gency=20Call=20System |Sender:=20; bh=I6Ba5WtgTkAvaBiIsK+7KTqm5Mf39i/xiO46vGIrXiY=; b=tYFXoN5hAxVS0TnZA73upKszZmGNL/H5TJsrhVdOeiwOQuZvi6teEZxmFJ OVdxqXAjCrsHf59O4r1agQor+OB9TMECXWwe4w0pLPLEXwzrTd/j65X8x8E+ o0dKuGm+Kc; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: ecrit@ietf.org Subject: Re: [Ecrit] Security Threat in Emergency Call System X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Raman I'm pretty sure, pragmatically, there will be another LoST query (based on the location given) within the signaling path to the actual PSAP. This would yield the correct results, and the SIP request would go towards that URI, instead of to PSAP_a. That said, how did your SIP client know it moved to the psap_b jurisdiction? Probably because it performed a LoST query to learn the cachable PSAP URI for here your SIP client now is, in case you have to call for emergency assistance. This becomes the cached value (overwriting what you previously had in your SIP client as psap_a's URI). When you make an urn sos call, your perform LoST again, seeking the freshest URI based on your location. The fallback is to the psap_b URI you loaded when you moved to the new city (i.e., cityB). Hope this helps. James At 01:31 AM 9/12/2008, Raman Chan wrote: >Ok,let't assume this scenario: >I live in CityA,and the city's PSAP URI is >psap_a@example.com >My SIP client issued LoST query got the result and cached the URI. >Some time later, I went to CityB,this city's PSAP URI is >psap_b@example.com >When I make emergency call,the LoST query expire due to some matter, >the client have to use the cached URI, >so the SIP-Invite contains >Request-URI:psap_a@example.com >and location of CityB, >the VSP'proxy make LoST query with locaiton of CityB,get the URI >psap_b@example.com, >the proxy may reject my emergency call. > >Thanks >Raman > > >On Fri, Sep 12, 2008 at 1:47 PM, Tschofenig, Hannes (NSN - FI/Espoo) ><hannes.tschofenig@nsn.com> wrote: >You would use LoST again to compare it. >We have discussed reverse lookup mechanisms in the past as well but they >seem to introduce complexity that isn't really necessary > >Ciao >Hannes > > > >________________________________ > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On >Behalf Of ext Raman Chan > Sent: 12 September, 2008 05:43 > To: ecrit@ietf.org > Subject: [Ecrit] Security Threat in Emergency Call System > > > Hi, > In RFC5069,section 6. > "the service provider's call routing entity MUST verify > that the destination address (e.g., SIP Request-URI) >presented in the > call signalling is that of a PSAP. " > > How to judge a URI is a PSAP-URI at the proxy side? > Is there any protocol to verify the URI, or the proxy just also >issue another LoST query and compare the result URI with request-URI? > > Thanks > Raman > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Sep 14 16:05:28 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFDBA3A6A64; Sun, 14 Sep 2008 16:05:28 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB2F83A6A64 for ; Sun, 14 Sep 2008 16:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.247 X-Spam-Level: X-Spam-Status: No, score=0.247 tagged_above=-999 required=5 tests=[AWL=-1.151, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0EbebaPnPN7D for ; Sun, 14 Sep 2008 16:05:27 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id CC38B3A6808 for ; Sun, 14 Sep 2008 16:05:26 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_09_14_18_06_19 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Sun, 14 Sep 2008 18:06:18 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 14 Sep 2008 17:49:56 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sun, 14 Sep 2008 17:49:54 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A different side to emergencies Thread-Index: AckWvDRSfgyQ7TQYQ1+cdmBhnpG0/g== From: "Winterbottom, James" To: X-OriginalArrivalTime: 14 Sep 2008 22:49:56.0270 (UTC) FILETIME=[356BF4E0:01C916BC] Subject: [Ecrit] A different side to emergencies X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1987317386==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1987317386== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C916BC.354E9901" This is a multi-part message in MIME format. ------_=_NextPart_001_01C916BC.354E9901 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable http://news.cnet.com/8301-17939_109-10040997-2.html=3Ftag=3Dmncol=0D=0A=0D=0A= =20=0D=0A=0D=0A=20=0D=0A=0D=0AThis is kind of interesting, though more aime= d at contacting people that=0D=0Aknow the victim, rather than dispatching e= mergency responders to the=0D=0Avictim.=0D=0A=0D=0A=20=0D=0A=0D=0AIt is sti= ll an interesting idea.=0D=0A=0D=0A=20=0D=0A=0D=0ACheers=0D=0A=0D=0AJames=0D= =0A=0D=0A=20=0D=0A=0D=0A---------------------------------------------------= ---------------------------------------------=0D=0AThis message is for the = designated recipient only and may=0D=0Acontain privileged, proprietary, or = otherwise private information. =20=0D=0AIf you have received it in error, p= lease notify the sender=0D=0Aimmediately and delete the original. Any unau= thorized use of=0D=0Athis email is prohibited.=0D=0A-----------------------= -------------------------------------------------------------------------=0D= =0A[mf2]=0D=0A ------_=_NextPart_001_01C916BC.354E9901 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =0D= =0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A= =0D=0A=0D=0A=0D=0A=0D=0A=
=0D=0A=0D=0A

http://news.cn= et.com/8301-17939_109-10040997-2.html=3Ftag=3Dmncol

=0D=0A=0D=0A

=  

=0D=0A=0D=0A

 

=0D=0A=0D=0A

This is kind of interesting, though mo= re=0D=0Aaimed at contacting people that know the victim, rather than dispat= ching=0D=0Aemergency responders to the victim.

=0D= =0A=0D=0A

 =

=0D=0A=0D=0A

It is still an interesting idea.

=0D=0A=0D=0A=

<= span=0D=0Astyle=3D'font-size:10.0pt;color:black'> 

=0D=0A=0D=0A

Cheer= s

=0D=0A=0D=0A

James

=0D=0A=0D=0A

 

=0D=0A=0D= =0A
=0D=0A=0D=0A

<= tr>

----------------------------------------------------------------= --------------------------------
=0D=0AThis message is fo= r the designated recipient only and may
=0D= =0Acontain privileged, proprietary, or otherwise p= rivate information.  
=0D=0AIf you have re= ceived it in error, please notify the se= nder
=0D=0Aimmediately and delete the original. = ; Any unauthorized use of
=0D=0Athis email = ;is prohibited.
=0D=0A---------------------------------------------= ---------------------------------------------------
=0D=0A[mf2]
=0D=0A=0D=0A=0D=0A ------_=_NextPart_001_01C916BC.354E9901-- --===============1987317386== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --===============1987317386==-- From ecrit-bounces@ietf.org Mon Sep 15 00:24:14 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E8513A6960; Mon, 15 Sep 2008 00:24:14 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACDFD3A6960 for ; Mon, 15 Sep 2008 00:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.444 X-Spam-Level: X-Spam-Status: No, score=-1.444 tagged_above=-999 required=5 tests=[AWL=0.536, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JFswBM3kGqZ for ; Mon, 15 Sep 2008 00:24:12 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 7B6D63A68D2 for ; Mon, 15 Sep 2008 00:24:11 -0700 (PDT) Received: (qmail invoked by alias); 15 Sep 2008 07:24:20 -0000 Received: from unknown (EHLO [10.183.181.140]) [192.100.124.156] by mail.gmx.net (mp058) with SMTP; 15 Sep 2008 09:24:20 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/Mc7kL0zzMGzhwcuaDLOHH3CZmYm0YWaZMk+fW1Z Mt3o4zBFDbnEX0 Message-ID: <48CE0D9F.8080406@gmx.net> Date: Mon, 15 Sep 2008 10:24:15 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: 'ECRIT' X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5600000000000001 Subject: [Ecrit] [Fwd: I-D Action:draft-patel-ecrit-sos-parameter-00.txt] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Please take a look at this document. Milan would like to hear some comments! Ciao Hannes -------- Original Message -------- Subject: I-D Action:draft-patel-ecrit-sos-parameter-00.txt Date: Fri, 12 Sep 2008 09:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SOS Uniform Resource Identifier (URI) parameter for marking of Session Initiation Protocol (SIP) requests related to emergency services Author(s) : M. Patel Filename : draft-patel-ecrit-sos-parameter-00.txt Pages : 9 Date : 2008-09-12 This memo describes requirements and protocol conventions for a new SIP (Session Initiation Protocol) URI parameter intended for marking SIP requests and responses related to emergency services. This proposal addresses issues that exist in the current 3rd Generation Partnership Project IP Multimedia Subsystem (IMS) Emergency services solution, but is not precluded from being used by other SIP-based emergency services solutions. It is not intended as a replacement for the service URN. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-patel-ecrit-sos-parameter-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 15 04:20:11 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCA583A6B21; Mon, 15 Sep 2008 04:20:11 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CE623A6B23 for ; Mon, 15 Sep 2008 04:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[AWL=0.664, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTVyljDRUp0o for ; Mon, 15 Sep 2008 04:20:09 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 4C0E23A6B1E for ; Mon, 15 Sep 2008 04:20:09 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KfC7q-000563-Gh; Mon, 15 Sep 2008 06:20:16 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" , "'ECRIT'" References: <48CE0D9F.8080406@gmx.net> Date: Mon, 15 Sep 2008 07:20:02 -0400 Message-ID: <066301c91725$088f7d20$3b01010a@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <48CE0D9F.8080406@gmx.net> Thread-Index: AckXBA4PQ5zfWoZsQvaze6QabFX7ygAHwGlQ X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] [Fwd: I-D Action:draft-patel-ecrit-sos-parameter-00.txt] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I get emergency registration, but perhaps there is a better way to do it. I don't get Req 2. No network entity other than the PSAP should be deleting the Route entry. Req 3 is perverse. The UE is not emergency aware, yet knows about the URI parameter. Perhaps you meant that it is emergency aware, but didn't recognize the dialstring. Redirect the call to urn:service:sos. I don't understand Req 4. The gateway has to have some mechanism to recognize that the call is from the PSAP. It's constructing a From/PAI. It can use the correct domain. So, 3GPP needs a way to mark an emergency services registration. It's possible the URI parameter is the best way to do that. I'll think about that. Hmmm. Maybe I'll give you a 5th requirement. An emergency call can be transferred. The result is an INVITE from the UE with a Referred-by, which is the PSAP. The urn:services:sos would not be in the ROUTE header, but it's still an emergency call. Hmmmm. Lots of PSAPs won't REFER all the way back to the caller. They will use some form of B2BUA, but still, the RIGHT way to do it is REFER. Hmmmm. Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Hannes Tschofenig > Sent: Monday, September 15, 2008 3:24 AM > To: 'ECRIT' > Subject: [Ecrit] [Fwd: I-D Action:draft-patel-ecrit-sos-parameter-00.txt] > > Please take a look at this document. Milan would like to hear some > comments! > > Ciao > Hannes > > -------- Original Message -------- > Subject: I-D Action:draft-patel-ecrit-sos-parameter-00.txt > Date: Fri, 12 Sep 2008 09:45:01 -0700 (PDT) > From: Internet-Drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : SOS Uniform Resource Identifier (URI) parameter > for marking of Session Initiation Protocol (SIP) requests related to > emergency services > Author(s) : M. Patel > Filename : draft-patel-ecrit-sos-parameter-00.txt > Pages : 9 > Date : 2008-09-12 > > This memo describes requirements and protocol conventions for a new > SIP (Session Initiation Protocol) URI parameter intended for marking > SIP requests and responses related to emergency services. This > proposal addresses issues that exist in the current 3rd Generation > Partnership Project IP Multimedia Subsystem (IMS) Emergency services > solution, but is not precluded from being used by other SIP-based > emergency services solutions. It is not intended as a replacement > for the service URN. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-patel-ecrit-sos-parameter-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 15 10:01:26 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0600D28C0F2; Mon, 15 Sep 2008 10:01:26 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4A823A6BA5 for ; Mon, 15 Sep 2008 10:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TkuaRkgeoZ6c for ; Mon, 15 Sep 2008 10:01:23 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 6F3FC3A6B7A for ; Mon, 15 Sep 2008 10:01:23 -0700 (PDT) Received: from zharhxm1.corp.nortel.com (zharhxm1.corp.nortel.com [47.165.48.149]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m8FH1UZ18630; Mon, 15 Sep 2008 17:01:30 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 15 Sep 2008 18:01:29 +0100 Message-ID: <0913B6CD18F370498CD65864CF254E9006724DC0@zharhxm1.corp.nortel.com> In-Reply-To: <066301c91725$088f7d20$3b01010a@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] [Fwd: I-D Action:draft-patel-ecrit-sos-parameter-00.txt] Thread-Index: AckXBA4PQ5zfWoZsQvaze6QabFX7ygAHwGlQAAwhFmA= From: "Milan Patel" To: "Brian Rosen" , "ECRIT" Subject: Re: [Ecrit] [Fwd: I-D Action:draft-patel-ecrit-sos-parameter-00.txt] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Brian, I've added comments inline: I get emergency registration, but perhaps there is a better way to do it. I don't get Req 2. No network entity other than the PSAP should be deleting the Route entry. [MILAN] The Route header entry of the PSAP is inserted by the E-CSCF (in the case of an IP-based PSAP). In the case of a PSTN based PSAP, the address of the BGCF is added in the Route header, and the PSAP address is added to the Request URI. Prior to the request reaching the E-CSCF, the PSAP address is not available in the SIP headers of the INVITE request. Req 3 is perverse. The UE is not emergency aware, yet knows about the URI parameter. Perhaps you meant that it is emergency aware, but didn't recognize the dialstring. Redirect the call to urn:service:sos. [MILAN] UE may be emergency capable, but is emergency unaware since it doesn't recognize the dialled digits (emergency number plan of the roamed-to region is not available in the UE) - thus is unaware an emergency call is dialled. The P-CSCF would then add the appropriate service URN if network policy is to proceed with the emergency call. UE recognizes the dialled digits as an emergency call but does not have an appropriate service URN to add to the Request URI i.e. lifeboat service. Thus UE adds dialstring to the Request-URI and the network will add the appropriate service URN (may result in default urn:service:sos being applied). A backwards indication in these cases would allow the UE to explicitly be aware that it is involved in an emergency call. I don't understand Req 4. The gateway has to have some mechanism to recognize that the call is from the PSAP. It's constructing a From/PAI. It can use the correct domain. [MILAN] In this case, the From/PAI would be a tel-URI. An explicit marking of the call back aids special handling (network service suppression). So, 3GPP needs a way to mark an emergency services registration. It's possible the URI parameter is the best way to do that. I'll think about that. Hmmm. Maybe I'll give you a 5th requirement. An emergency call can be transferred. The result is an INVITE from the UE with a Referred-by, which is the PSAP. The urn:services:sos would not be in the ROUTE header, but it's still an emergency call. Hmmmm. Lots of PSAPs won't REFER all the way back to the caller. They will use some form of B2BUA, but still, the RIGHT way to do it is REFER. Hmmmm. Regards, Milan -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: 15 September 2008 12:20 To: 'Hannes Tschofenig'; 'ECRIT' Subject: Re: [Ecrit] [Fwd: I-D Action:draft-patel-ecrit-sos-parameter-00.txt] I get emergency registration, but perhaps there is a better way to do it. I don't get Req 2. No network entity other than the PSAP should be deleting the Route entry. Req 3 is perverse. The UE is not emergency aware, yet knows about the URI parameter. Perhaps you meant that it is emergency aware, but didn't recognize the dialstring. Redirect the call to urn:service:sos. I don't understand Req 4. The gateway has to have some mechanism to recognize that the call is from the PSAP. It's constructing a From/PAI. It can use the correct domain. So, 3GPP needs a way to mark an emergency services registration. It's possible the URI parameter is the best way to do that. I'll think about that. Hmmm. Maybe I'll give you a 5th requirement. An emergency call can be transferred. The result is an INVITE from the UE with a Referred-by, which is the PSAP. The urn:services:sos would not be in the ROUTE header, but it's still an emergency call. Hmmmm. Lots of PSAPs won't REFER all the way back to the caller. They will use some form of B2BUA, but still, the RIGHT way to do it is REFER. Hmmmm. Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Hannes Tschofenig > Sent: Monday, September 15, 2008 3:24 AM > To: 'ECRIT' > Subject: [Ecrit] [Fwd: I-D Action:draft-patel-ecrit-sos-parameter-00.txt] > > Please take a look at this document. Milan would like to hear some > comments! > > Ciao > Hannes > > -------- Original Message -------- > Subject: I-D Action:draft-patel-ecrit-sos-parameter-00.txt > Date: Fri, 12 Sep 2008 09:45:01 -0700 (PDT) > From: Internet-Drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : SOS Uniform Resource Identifier (URI) parameter > for marking of Session Initiation Protocol (SIP) requests related to > emergency services > Author(s) : M. Patel > Filename : draft-patel-ecrit-sos-parameter-00.txt > Pages : 9 > Date : 2008-09-12 > > This memo describes requirements and protocol conventions for a new > SIP (Session Initiation Protocol) URI parameter intended for marking > SIP requests and responses related to emergency services. This > proposal addresses issues that exist in the current 3rd Generation > Partnership Project IP Multimedia Subsystem (IMS) Emergency services > solution, but is not precluded from being used by other SIP-based > emergency services solutions. It is not intended as a replacement > for the service URN. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-patel-ecrit-sos-parameter-00.t xt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 16 02:17:23 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 928873A691A; Tue, 16 Sep 2008 02:17:23 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55FE028C1A6 for ; Tue, 16 Sep 2008 02:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.705 X-Spam-Level: X-Spam-Status: No, score=0.705 tagged_above=-999 required=5 tests=[AWL=-0.897, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, J_CHICKENPOX_35=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_65=0.6, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwXfj-m8SSWe for ; Tue, 16 Sep 2008 02:17:16 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by core3.amsl.com (Postfix) with ESMTP id D09F33A68D8 for ; Tue, 16 Sep 2008 02:17:15 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so1630556fga.41 for ; Tue, 16 Sep 2008 02:17:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=Ru+YLSigE6Tsf2FXuuOsKnKbzKL9iLw13OUp5NYuxNc=; b=i+np+YdbmLEb1V2y1qL/bQJ/Sp9+Qy+LqKByt06nfKwsahykmivk2Bk/erWDccbEy3 sJZuWPwkexUmDx7AdIZyaFkTXPLoVIv+ODAdCcg6lLG+b8AqaV30hgxP9IPhre2HbEbl 6z5y6fznKACtuxv7OwLynm2ajTc7jCcpRrelg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=eKi+nrxxaLhglMgdQoMnTlVCj6aTtS3WZasqYmTvGis3dbGKeyTiUx+zkvUfJ3mbpK O8NlpAVLfIwyhPbGDxl/FaV1ECY8ttbv078P4igcqT/64V4Agirjo13bPUKda/xLNIFT 5XX5GhGvub6eWuVxX4IrwipLfBL7u6AH2zIi8= Received: by 10.180.227.2 with SMTP id z2mr353947bkg.12.1221556646198; Tue, 16 Sep 2008 02:17:26 -0700 (PDT) Received: by 10.180.205.3 with HTTP; Tue, 16 Sep 2008 02:17:26 -0700 (PDT) Message-ID: Date: Tue, 16 Sep 2008 17:17:26 +0800 From: "Raman Chan" To: "James M. Polk" In-Reply-To: MIME-Version: 1.0 References: Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , ecrit@ietf.org Subject: Re: [Ecrit] Security Threat in Emergency Call System X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0642425127==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org --===============0642425127== Content-Type: multipart/alternative; boundary="----=_Part_3332_20711938.1221556646193" ------=_Part_3332_20711938.1221556646193 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline James Let's consider this extreme scenario: My SIP client learn the latest location(CityB) from LIS successfully, but the LoST query failed for quite a long-period. The fallback is still to the psap_a URI I loaded when I am in CityA. Of course,proxy can do the LoST query again,and the proxy rewrite the PSAP URI which was supplyed by SIP client. In order to prohibit PSAPURI-forgery ,the proxy *MUST* do the LoST mapping,so why we let the SIP client do this process? Thanks Raman On Sat, Sep 13, 2008 at 5:28 AM, James M. Polk wrote: > Raman > > I'm pretty sure, pragmatically, there will be another LoST query (based on > the location given) within the signaling path to the actual PSAP. This > would yield the correct results, and the SIP request would go towards that > URI, instead of to PSAP_a. > > That said, how did your SIP client know it moved to the psap_b > jurisdiction? Probably because it performed a LoST query to learn the > cachable PSAP URI for here your SIP client now is, in case you have to call > for emergency assistance. This becomes the cached value (overwriting what > you previously had in your SIP client as psap_a's URI). When you make an > urn sos call, your perform LoST again, seeking the freshest URI based on > your location. The fallback is to the psap_b URI you loaded when you moved > to the new city (i.e., cityB). > > Hope this helps. > > James > > At 01:31 AM 9/12/2008, Raman Chan wrote: > >> Ok,let't assume this scenario: >> I live in CityA,and the city's PSAP URI is >> psap_a@example.com >> My SIP client issued LoST query got the result and cached the URI. >> Some time later, I went to CityB,this city's PSAP URI is > psap_b@example.com>psap_b@example.com >> When I make emergency call,the LoST query expire due to some matter, >> the client have to use the cached URI, >> so the SIP-Invite contains >> >Request-URI:psap_a@example.com and >> location of CityB, >> the VSP'proxy make LoST query with locaiton of CityB,get the URI > psap_b@example.com>psap_b@example.com, >> the proxy may reject my emergency call. >> >> Thanks >> Raman >> >> >> On Fri, Sep 12, 2008 at 1:47 PM, Tschofenig, Hannes (NSN - FI/Espoo) >> <hannes.tschofenig@nsn.com> wrote: >> You would use LoST again to compare it. >> We have discussed reverse lookup mechanisms in the past as well but they >> seem to introduce complexity that isn't really necessary >> >> Ciao >> Hannes >> >> >> >> ________________________________ >> >> From: ecrit-bounces@ietf.org[mailto: >> ecrit-bounces@ietf.org] On >> Behalf Of ext Raman Chan >> Sent: 12 September, 2008 05:43 >> To: ecrit@ietf.org >> Subject: [Ecrit] Security Threat in Emergency Call System >> >> >> Hi, >> In RFC5069,section 6. >> "the service provider's call routing entity MUST verify >> that the destination address (e.g., SIP Request-URI) >> presented in the >> call signalling is that of a PSAP. " >> >> How to judge a URI is a PSAP-URI at the proxy side? >> Is there any protocol to verify the URI, or the proxy just also >> issue another LoST query and compare the result URI with request-URI? >> >> Thanks >> Raman >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> > > ------=_Part_3332_20711938.1221556646193 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
James
Let's consider this extreme scenario:
My SIP client learn the latest location(CityB) from LIS successfully,
but the LoST query failed for quite a long-period.
The fallback is still to the psap_a URI I loaded when I am in CityA.
 
Of course,proxy can do the LoST query again,and the proxy rewrite the PSAP URI which was supplyed  by SIP client.
 
In order to prohibit PSAPURI-forgery ,the proxy *MUST* do the LoST mapping,so why we let the SIP client do this process?
Thanks
Raman

On Sat, Sep 13, 2008 at 5:28 AM, James M. Polk <jmpolk@cisco.com> wrote:
Raman

I'm pretty sure, pragmatically, there will be another LoST query (based on the location given) within the signaling path to the actual PSAP.  This would yield the correct results, and the SIP request would go towards that URI, instead of to PSAP_a.

That said, how did your SIP client know it moved to the psap_b jurisdiction?  Probably because it performed a LoST query to learn the cachable PSAP URI for here your SIP client now is, in case you have to call for emergency assistance.  This becomes the cached value (overwriting what you previously had in your SIP client as psap_a's URI).  When you make an urn sos call, your perform LoST again, seeking the freshest URI based on your location.  The fallback is to the psap_b URI you loaded when you moved to the new city (i.e., cityB).

Hope this helps.

James


At 01:31 AM 9/12/2008, Raman Chan wrote:
Ok,let't assume this scenario:
I live in CityA,and the city's PSAP URI is <mailto:psap_a@example.com>psap_a@example.com

My SIP client issued LoST query got the result and cached the URI.
Some time later, I went to CityB,this city's PSAP URI is <mailto:psap_b@example.com>psap_b@example.com

When I make emergency call,the LoST query expire due to some matter,
the client have to use the cached URI,
so the SIP-Invite contains <mailto:Request-URI%3Apsap_a@example.com>Request-URI:psap_a@example.com and location of CityB,
the VSP'proxy make LoST query with locaiton of CityB,get the URI <mailto:psap_b@example.com>psap_b@example.com,

the proxy may reject my emergency call.

Thanks
Raman


On Fri, Sep 12, 2008 at 1:47 PM, Tschofenig, Hannes (NSN - FI/Espoo) <<mailto:hannes.tschofenig@nsn.com>hannes.tschofenig@nsn.com> wrote:
You would use LoST again to compare it.
We have discussed reverse lookup mechanisms in the past as well but they
seem to introduce complexity that isn't really necessary

Ciao
Hannes



________________________________

      From: <mailto:ecrit-bounces@ietf.org>ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On

Behalf Of ext Raman Chan
      Sent: 12 September, 2008 05:43
      To: <mailto:ecrit@ietf.org>ecrit@ietf.org

      Subject: [Ecrit] Security Threat in Emergency Call System


      Hi,
      In RFC5069,section 6.
        "the service provider's call routing entity MUST verify
           that the destination address (e.g., SIP Request-URI)
presented in the
           call signalling is that of a PSAP. "

      How to judge a URI is a PSAP-URI at the proxy side?
      Is there any protocol to verify the URI, or the proxy just also
issue another LoST query and compare the result URI with request-URI?

      Thanks
      Raman


_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit


------=_Part_3332_20711938.1221556646193-- --===============0642425127== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --===============0642425127==-- From ecrit-bounces@ietf.org Tue Sep 16 03:38:18 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 634ED28C1C8; Tue, 16 Sep 2008 03:38:18 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57D3B28C1C8 for ; Tue, 16 Sep 2008 03:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.046 X-Spam-Level: X-Spam-Status: No, score=-1.046 tagged_above=-999 required=5 tests=[AWL=-2.647, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_35=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_65=0.6, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYfB96ilfH3u for ; Tue, 16 Sep 2008 03:38:13 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id E74D628C1C5 for ; Tue, 16 Sep 2008 03:38:12 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m8GAcKRj005629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Sep 2008 12:38:20 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m8GAcJa4022818; Tue, 16 Sep 2008 12:38:19 +0200 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Sep 2008 12:38:15 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.17]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Sep 2008 12:38:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 16 Sep 2008 13:37:53 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Security Threat in Emergency Call System Thread-Index: AckX3RnUpPz10Rq5T+61z/HdE1KYqgABF6pw References: From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Raman Chan" , "James M. Polk" X-OriginalArrivalTime: 16 Sep 2008 10:38:14.0608 (UTC) FILETIME=[52D17500:01C917E8] Cc: ecrit@ietf.org Subject: Re: [Ecrit] Security Threat in Emergency Call System X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org You are right that the proxy has to be capable of doing the LoST query for cases where the clients don't support LoST or in those cases where VoIP providers care about the fraud case. Having LoST support on the end host is useful for obtaining the emergency services numbers, for validating civic addresses, for learning about PSAPs in enterprise networks, campuses, etc. Note that not everyone cares about the fraud case as with many VoIP offerings today this wouldn't really be fraud as charging isn't done on a call-by-call basis. Additionally, there is the deployment aspect: Deploying LoST on the end point is simpler when combined with a DHCP-based LoST discovery mechanism as you don't need to create a global LoST mapping database. Which specific deployment streams wil be favored is somewhat hard to tell at this point in time. We will see but the protocol was intentially designed to be flexible and can therefore be used in different settings. Ciao Hannes James Let's consider this extreme scenario: My SIP client learn the latest location(CityB) from LIS successfully, but the LoST query failed for quite a long-period. The fallback is still to the psap_a URI I loaded when I am in CityA. Of course,proxy can do the LoST query again,and the proxy rewrite the PSAP URI which was supplyed by SIP client. In order to prohibit PSAPURI-forgery ,the proxy *MUST* do the LoST mapping,so why we let the SIP client do this process? Thanks Raman On Sat, Sep 13, 2008 at 5:28 AM, James M. Polk wrote: Raman I'm pretty sure, pragmatically, there will be another LoST query (based on the location given) within the signaling path to the actual PSAP. This would yield the correct results, and the SIP request would go towards that URI, instead of to PSAP_a. That said, how did your SIP client know it moved to the psap_b jurisdiction? Probably because it performed a LoST query to learn the cachable PSAP URI for here your SIP client now is, in case you have to call for emergency assistance. This becomes the cached value (overwriting what you previously had in your SIP client as psap_a's URI). When you make an urn sos call, your perform LoST again, seeking the freshest URI based on your location. The fallback is to the psap_b URI you loaded when you moved to the new city (i.e., cityB). Hope this helps. James At 01:31 AM 9/12/2008, Raman Chan wrote: Ok,let't assume this scenario: I live in CityA,and the city's PSAP URI is psap_a@example.com My SIP client issued LoST query got the result and cached the URI. Some time later, I went to CityB,this city's PSAP URI is psap_b@example.com When I make emergency call,the LoST query expire due to some matter, the client have to use the cached URI, so the SIP-Invite contains >Request-URI:psap_a@example.com and location of CityB, the VSP'proxy make LoST query with locaiton of CityB,get the URI psap_b@example.com, the proxy may reject my emergency call. Thanks Raman On Fri, Sep 12, 2008 at 1:47 PM, Tschofenig, Hannes (NSN - FI/Espoo) <hannes.tschofenig@nsn.com> wrote: You would use LoST again to compare it. We have discussed reverse lookup mechanisms in the past as well but they seem to introduce complexity that isn't really necessary Ciao Hannes ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of ext Raman Chan Sent: 12 September, 2008 05:43 To: ecrit@ietf.org Subject: [Ecrit] Security Threat in Emergency Call System Hi, In RFC5069,section 6. "the service provider's call routing entity MUST verify that the destination address (e.g., SIP Request-URI) presented in the call signalling is that of a PSAP. " How to judge a URI is a PSAP-URI at the proxy side? Is there any protocol to verify the URI, or the proxy just also issue another LoST query and compare the result URI with request-URI? Thanks Raman _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 16 05:08:38 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD84728C125; Tue, 16 Sep 2008 05:08:38 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80E3428C125 for ; Tue, 16 Sep 2008 05:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.602 X-Spam-Level: X-Spam-Status: No, score=-4.602 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LU4lRfCqqspk for ; Tue, 16 Sep 2008 05:08:31 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id C7F4A3A6B64 for ; Tue, 16 Sep 2008 05:08:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,408,1217808000"; d="scan'208,217";a="21050661" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 16 Sep 2008 12:08:42 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m8GC8g45009836; Tue, 16 Sep 2008 08:08:42 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m8GC8gpK020955; Tue, 16 Sep 2008 12:08:42 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Sep 2008 08:08:41 -0400 Received: from [10.116.195.117] ([10.116.195.117]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Sep 2008 08:08:40 -0400 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Tue, 16 Sep 2008 08:08:39 -0400 From: Marc Linsner To: Raman Chan Message-ID: Thread-Topic: [Ecrit] Security Threat in Emergency Call System Thread-Index: AckX9PQBDFuSVHZhlU+z3JcAhBdNZg== In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 16 Sep 2008 12:08:41.0561 (UTC) FILETIME=[F588C490:01C917F4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1357; t=1221566922; x=1222430922; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20Marc=20Linsner=20 |Subject:=20Re=3A=20[Ecrit]=20Security=20Threat=20in=20Emer gency=20Call=20System |Sender:=20 |To:=20Raman=20Chan=20; bh=+IHEF2y8lh61x/FsmJ4KQQgqWjfApM9NdY89j3oUbww=; b=O4afBLUfXut/zmAR89qFo05/YF4dJHkEkS3+lwmvT53wlJLHIOSDxAp4SJ dFHUQ30YBDvJbvJUCWGaHc3Q8elzuXWlFUif2SB+eCHRTKTuL3sZ8BS9nYdA /k5ekWmiCx; Authentication-Results: rtp-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: ecrit@ietf.org Subject: Re: [Ecrit] Security Threat in Emergency Call System X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1689814387==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1689814387== Content-type: multipart/alternative; boundary="B_3304397320_32204" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3304397320_32204 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Raman, > > In order to prohibit PSAPURI-forgery ,the proxy *MUST* do the LoST mapping,so > why we let the SIP client do this process? A SIP proxy is not a required element. When there is no proxy used, the UA must be able to perform a LoST query. -Marc- --B_3304397320_32204 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [Ecrit] Security Threat in Emergency Call System Raman,

<= SPAN STYLE=3D'font-size:11pt'>
In order to prohibit PSAPURI-forgery ,the proxy *MUST* do the LoST mapping,= so why we let the SIP client do this process?
=
A SIP proxy is not a required element.  When there is no proxy used, t= he UA must be able to perform a LoST query.

-Marc- --B_3304397320_32204-- --===============1689814387== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --===============1689814387==-- From ecrit-bounces@ietf.org Tue Sep 16 08:04:47 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C00F93A69A2; Tue, 16 Sep 2008 08:04:47 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87BAC3A6998; Tue, 16 Sep 2008 08:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYJQOlIP5ZrD; Tue, 16 Sep 2008 08:04:45 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id AC4793A6984; Tue, 16 Sep 2008 08:04:45 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 16 Sep 2008 15:04:58 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m8GF4vAU009192; Tue, 16 Sep 2008 08:04:57 -0700 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m8GF4uXA012211; Tue, 16 Sep 2008 15:04:57 GMT Message-Id: From: Cullen Jennings To: ECRIT , rai@ietf.org Impp: xmpp:cullenfluffyjennings@jabber.org Mime-Version: 1.0 (Apple Message framework v928.1) Date: Tue, 16 Sep 2008 09:04:57 -0600 X-Mailer: Apple Mail (2.928.1) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=380; t=1221577498; x=1222441498; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Reminder=20of=20BOF=20deadline=20 |Sender:=20; bh=F9E0urUUx+4Cp5xjZwaf1zKv6BZ8/FUBJCj1ebhunqA=; b=G1L7WeWZeqSLh8FuncNdVYHDR5c0IC0QahVMFXRyngIXZ1CzHfZDuHUAVR uDTzqBm1yqK9yWWrkJj3qxAT3zYwgTztaU2gcQ20a3qd8YheKvc55Jv4lRIK D42YNnkcPg; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [Ecrit] Reminder of BOF deadline X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Jon and I are looking forward to getting a BOF proposal along the lines of an early warning system where authorities can warn citizens about emergencies. I wanted to remind folks that deadline is Sept 29 and that earlywarning@ietf.org is probably the right place to discuss it. Thanks, Cullen Please, don't reply to this - send replies to earlywarning list. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 16 12:41:34 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6282E3A6868; Tue, 16 Sep 2008 12:41:34 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E476D3A686C for ; Tue, 16 Sep 2008 12:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.068 X-Spam-Level: X-Spam-Status: No, score=-2.068 tagged_above=-999 required=5 tests=[AWL=0.531, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdebqea2AjUg for ; Tue, 16 Sep 2008 12:41:32 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 5B2333A6868 for ; Tue, 16 Sep 2008 12:41:32 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KfgQX-0000mY-Qw; Tue, 16 Sep 2008 14:41:37 -0500 From: "Brian Rosen" To: "'Milan Patel'" , "'ECRIT'" References: <066301c91725$088f7d20$3b01010a@cis.neustar.com> <0913B6CD18F370498CD65864CF254E9006724DC0@zharhxm1.corp.nortel.com> Date: Tue, 16 Sep 2008 15:41:35 -0400 Message-ID: <005501c91834$412c2d30$9e01010a@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <0913B6CD18F370498CD65864CF254E9006724DC0@zharhxm1.corp.nortel.com> Thread-Index: AckXBA4PQ5zfWoZsQvaze6QabFX7ygAHwGlQAAwhFmAAKfpUQA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] [Fwd: I-D Action:draft-patel-ecrit-sos-parameter-00.txt] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I'm still not getting Req 2. Is the problem that the call has to be marked before the E-CSCF or is it that some entity between the E-CSCF and the PSAP deletes it? In the case of a PSTN connected PSAP, the BGCF is the last SIP element; the call doesn't pass it as SIP. So as long as the Route entry is on when the call gets to the BGCF it should be okay. I'm also not understanding the problem in 3. If the UE recognizes the dialstring, then it should have the service URN. What am I missing? If it doesn't recognize the dialstring then the network does and redirects the call to the proper service. I claim that if the gateway is recognizing that the call back is from the PSAP so that special marking is appropriate, then it can use the domain concept as well as anything else. I don't think having another mechanism is warranted. I'm not really opposed to having some kind of marking of call backs, but I don't think it's absolutely necessary. > -----Original Message----- > From: Milan Patel [mailto:milanpa@nortel.com] > Sent: Monday, September 15, 2008 1:01 PM > To: Brian Rosen; ECRIT > Subject: RE: [Ecrit] [Fwd: I-D Action:draft-patel-ecrit-sos-parameter- > 00.txt] > > Hi Brian, > > I've added comments inline: > > I get emergency registration, but perhaps there is a better way to do > it. > > I don't get Req 2. No network entity other than the PSAP should be > deleting > the Route entry. > > [MILAN] The Route header entry of the PSAP is inserted by the E-CSCF (in > the case of an IP-based PSAP). In the case of a PSTN based PSAP, the > address of the BGCF is added in the Route header, and the PSAP address > is added to the Request URI. Prior to the request reaching the E-CSCF, > the PSAP address is not available in the SIP headers of the INVITE > request. > > Req 3 is perverse. The UE is not emergency aware, yet knows about the > URI > parameter. Perhaps you meant that it is emergency aware, but didn't > recognize the dialstring. Redirect the call to urn:service:sos. > > [MILAN] UE may be emergency capable, but is emergency unaware since it > doesn't recognize the dialled digits (emergency number plan of the > roamed-to region is not available in the UE) - thus is unaware an > emergency call is dialled. The P-CSCF would then add the appropriate > service URN if network policy is to proceed with the emergency call. > UE recognizes the dialled digits as an emergency call but does not have > an appropriate service URN to add to the Request URI i.e. lifeboat > service. Thus UE adds dialstring to the Request-URI and the network will > add the appropriate service URN (may result in default urn:service:sos > being applied). A backwards indication in these cases would allow the UE > to explicitly be aware that it is involved in an emergency call. > > I don't understand Req 4. The gateway has to have some mechanism to > recognize that the call is from the PSAP. It's constructing a From/PAI. > It > can use the correct domain. > > [MILAN] In this case, the From/PAI would be a tel-URI. An explicit > marking of the call back aids special handling (network service > suppression). > > So, 3GPP needs a way to mark an emergency services registration. It's > possible the URI parameter is the best way to do that. I'll think about > that. > > Hmmm. Maybe I'll give you a 5th requirement. An emergency call can be > transferred. The result is an INVITE from the UE with a Referred-by, > which > is the PSAP. The urn:services:sos would not be in the ROUTE header, but > it's still an emergency call. Hmmmm. Lots of PSAPs won't REFER all the > way > back to the caller. They will use some form of B2BUA, but still, the > RIGHT > way to do it is REFER. Hmmmm. > > Regards, > Milan > > > > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Brian Rosen > Sent: 15 September 2008 12:20 > To: 'Hannes Tschofenig'; 'ECRIT' > Subject: Re: [Ecrit] [Fwd: I-D > Action:draft-patel-ecrit-sos-parameter-00.txt] > > I get emergency registration, but perhaps there is a better way to do > it. > > I don't get Req 2. No network entity other than the PSAP should be > deleting > the Route entry. > > Req 3 is perverse. The UE is not emergency aware, yet knows about the > URI > parameter. Perhaps you meant that it is emergency aware, but didn't > recognize the dialstring. Redirect the call to urn:service:sos. > > I don't understand Req 4. The gateway has to have some mechanism to > recognize that the call is from the PSAP. It's constructing a From/PAI. > It > can use the correct domain. > > So, 3GPP needs a way to mark an emergency services registration. It's > possible the URI parameter is the best way to do that. I'll think about > that. > > Hmmm. Maybe I'll give you a 5th requirement. An emergency call can be > transferred. The result is an INVITE from the UE with a Referred-by, > which > is the PSAP. The urn:services:sos would not be in the ROUTE header, but > it's still an emergency call. Hmmmm. Lots of PSAPs won't REFER all the > way > back to the caller. They will use some form of B2BUA, but still, the > RIGHT > way to do it is REFER. Hmmmm. > > Brian > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of > > Hannes Tschofenig > > Sent: Monday, September 15, 2008 3:24 AM > > To: 'ECRIT' > > Subject: [Ecrit] [Fwd: I-D > Action:draft-patel-ecrit-sos-parameter-00.txt] > > > > Please take a look at this document. Milan would like to hear some > > comments! > > > > Ciao > > Hannes > > > > -------- Original Message -------- > > Subject: I-D Action:draft-patel-ecrit-sos-parameter-00.txt > > Date: Fri, 12 Sep 2008 09:45:01 -0700 (PDT) > > From: Internet-Drafts@ietf.org > > Reply-To: internet-drafts@ietf.org > > To: i-d-announce@ietf.org > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > Title : SOS Uniform Resource Identifier (URI) > parameter > > for marking of Session Initiation Protocol (SIP) requests related to > > emergency services > > Author(s) : M. Patel > > Filename : draft-patel-ecrit-sos-parameter-00.txt > > Pages : 9 > > Date : 2008-09-12 > > > > This memo describes requirements and protocol conventions for a new > > SIP (Session Initiation Protocol) URI parameter intended for marking > > SIP requests and responses related to emergency services. This > > proposal addresses issues that exist in the current 3rd Generation > > Partnership Project IP Multimedia Subsystem (IMS) Emergency services > > solution, but is not precluded from being used by other SIP-based > > emergency services solutions. It is not intended as a replacement > > for the service URN. > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-patel-ecrit-sos-parameter-00.t > xt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 18 21:28:22 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F40A3A687B; Thu, 18 Sep 2008 21:28:22 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B8773A65A5 for ; Thu, 18 Sep 2008 21:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.823 X-Spam-Level: X-Spam-Status: No, score=0.823 tagged_above=-999 required=5 tests=[AWL=-0.575, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZelSpcMqrBF for ; Thu, 18 Sep 2008 21:28:15 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id E6EC43A68FA for ; Thu, 18 Sep 2008 21:28:14 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_09_18_23_44_53 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 18 Sep 2008 23:44:53 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Sep 2008 23:28:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 18 Sep 2008 23:28:24 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 3G Americas warns against text warning systems Thread-Index: AckaECdxQyh9u29tQdy3ub5sX7vFdQ== From: "Winterbottom, James" To: X-OriginalArrivalTime: 19 Sep 2008 04:28:26.0206 (UTC) FILETIME=[28BD3FE0:01C91A10] Subject: [Ecrit] 3G Americas warns against text warning systems X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0476297219==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0476297219== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C91A10.283E2E23" This is a multi-part message in MIME format. ------_=_NextPart_001_01C91A10.283E2E23 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable http://www.theregister.co.uk/2008/09/18/emergency_text/=0D=0A=0D=0A=20=0D=0A=0D= =0AI thought that this was interesting given some of the discussion that=0D= =0Ahas gone on recently on this topic.=0D=0A=0D=0A=20=0D=0A=0D=0ACheers=0D=0A=0D= =0AJames=0D=0A=0D=0A=20=0D=0A=0D=0A----------------------------------------= --------------------------------------------------------=0D=0AThis message = is for the designated recipient only and may=0D=0Acontain privileged, propr= ietary, or otherwise private information. =20=0D=0AIf you have received it = in error, please notify the sender=0D=0Aimmediately and delete the original= =2E Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A----------= ---------------------------------------------------------------------------= -----------=0D=0A[mf2]=0D=0A ------_=_NextPart_001_01C91A10.283E2E23 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =0D= =0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A= =0D=0A=0D=0A=0D=0A=0D=0A=
=0D=0A=0D=0A

http://www.theregister.c= o.uk/2008/09/18/emergency_text/

=0D=0A=0D=0A=

 

=0D=0A=0D=0A

I thought that this was interesti= ng given=0D=0Asome of the discussion that has gone on recently on this topi= c.

=0D=0A=0D=0A

 

=0D=0A=0D=0A

Cheers

=0D= =0A=0D=0A

James<= /span>

=0D=0A=0D=0A

 

=0D=0A=0D=0A
=0D=0A=0D=0A

=

------------------= ---------------------------------------------------------------------------= ---
=0D=0AThis message is for the designated&nb= sp;recipient only and may
=0D=0Acontain privileged,&= nbsp;proprietary, or otherwise private information.&nbs= p; 
=0D=0AIf you have received it in = error, please notify the sender
=0D=0Aimmediately&nb= sp;and delete the original.  Any unauthorized=  use of
=0D=0Athis email is prohibited.
=0D=0A= ---------------------------------------------------------------------------= ---------------------
=0D=0A[mf2]
=0D=0A=0D=0A=0D=0A ------_=_NextPart_001_01C91A10.283E2E23-- --===============0476297219== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --===============0476297219==-- From ecrit-bounces@ietf.org Mon Sep 29 12:27:43 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E83D03A68B0; Mon, 29 Sep 2008 12:27:43 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CA5B3A6808 for ; Mon, 29 Sep 2008 12:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppIoOKa7Snm1 for ; Mon, 29 Sep 2008 12:27:42 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 391CC3A68B0 for ; Mon, 29 Sep 2008 12:27:41 -0700 (PDT) Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id m8TJRwxQ012753 for ; Mon, 29 Sep 2008 14:27:59 -0500 (CDT) Received: from ILEXC1U02.ndc.lucent.com ([135.3.39.4]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Sep 2008 14:27:58 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 29 Sep 2008 14:27:57 -0500 Message-ID: <7D096A439A3D0D48A3D10872022CFD090318D401@ILEXC1U02.ndc.lucent.com> In-Reply-To: <7D096A439A3D0D48A3D10872022CFD09030A3587@ILEXC1U02.ndc.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] [Fwd: I-D Action:draft-patel-ecrit-sos-parameter-00.txt] Thread-Index: AckXg6OCRW/U8MajRmOtBYMubYaiMAK5Z1MQ References: <7D096A439A3D0D48A3D10872022CFD09030A3587@ILEXC1U02.ndc.lucent.com> From: "GOLDMAN, STUART O \(STUART\)" To: X-OriginalArrivalTime: 29 Sep 2008 19:27:58.0469 (UTC) FILETIME=[7AD88350:01C92269] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Subject: Re: [Ecrit] [Fwd: I-D Action:draft-patel-ecrit-sos-parameter-00.txt] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0077157299==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0077157299== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C92269.7AE74FCF" This is a multi-part message in MIME format. ------_=_NextPart_001_01C92269.7AE74FCF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am reposting because I did not see this response pop up on the ecrit list. =20 Stuart Goldman Alcatel-Lucent=20 Stuart.Goldman@alcatel-lucent.com +1 602 493 8438 +1 480 414 1260 mobile P please save a tree by not printing this e-mail. =20 =20 =20 ________________________________ From: GOLDMAN, STUART O (STUART)=20 Sent: Monday, September 15, 2008 3:38 PM To: 'ECRIT'; milanpa@nortel.com Cc: Hannes Tschofenig Subject: [Ecrit] [Fwd: I-D Action:draft-patel-ecrit-sos-parameter-00.txt] =20 Milan, =20 As per Hannes request below, I am letting you know this draft looks really good and I can only encourage that it become a working group draft as soon as possible. The need for this parameter is quite clear. =20 Stuart Goldman Alcatel-Lucent=20 Stuart.Goldman@alcatel-lucent.com +1 602 493 8438 +1 480 414 1260 mobile P please save a tree by not printing this e-mail. =20 Date: Mon, 15 Sep 2008 10:24:15 +0300 From: Hannes Tschofenig Subject: [Ecrit] [Fwd: I-D Action:draft-patel-ecrit-sos-parameter-00.txt] To: 'ECRIT' =20 Message-ID: <48CE0D9F.8080406@gmx.net> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed =20 Please take a look at this document. Milan would like to hear some comments! =20 Ciao Hannes =20 -------- Original Message -------- Subject: I-D Action:draft-patel-ecrit-sos-parameter-00.txt Date: Fri, 12 Sep 2008 09:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org =20 =20 =20 A New Internet-Draft is available from the on-line Internet-Drafts directories. =20 Title : SOS Uniform Resource Identifier (URI) parameter for marking of Session Initiation Protocol (SIP) requests related to emergency services Author(s) : M. Patel Filename : draft-patel-ecrit-sos-parameter-00.txt Pages : 9 Date : 2008-09-12 =20 This memo describes requirements and protocol conventions for a new SIP (Session Initiation Protocol) URI parameter intended for marking SIP requests and responses related to emergency services. This proposal addresses issues that exist in the current 3rd Generation Partnership Project IP Multimedia Subsystem (IMS) Emergency services solution, but is not precluded from being used by other SIP-based emergency services solutions. It is not intended as a replacement for the service URN. =20 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-patel-ecrit-sos-parameter-00.t xt =20 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ =20 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. =20 =20 =20 =20 =20 ------_=_NextPart_001_01C92269.7AE74FCF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am = reposting because I did not see this response pop up on the ecrit = list.

 

Stuart = Goldman

Alcatel-Lucent =

Stuart.Goldman@alcatel-lucent.com

+1 602 493 = 8438

+1 480 414 1260 = mobile

P please save a tree by not printing this e-mail.

 

=

 

=

 

From: = GOLDMAN, STUART O (STUART)
Sent: Monday, September = 15, 2008 3:38 PM
To: 'ECRIT'; = milanpa@nortel.com
Cc: Hannes Tschofenig
Subject: [Ecrit] [Fwd: = I-D Action:draft-patel-ecrit-sos-parameter-00.txt]

 

Milan,

 

As per Hannes request below, I am = letting you know this draft looks really good and I can only encourage that it = become a working group draft as soon as possible. The need for this parameter is = quite clear.

 

Stuart Goldman

Alcatel-Lucent

Stuart.Goldman@alcatel-lucent.com

+1 602 493 8438

+1 480 414 1260 mobile

P please save a tree by not printing this = e-mail.

 

Date: Mon, 15 Sep = 2008 10:24:15 +0300

From: Hannes = Tschofenig <Hannes.Tschofenig@gmx.net>

Subject: [Ecrit] = [Fwd: I-D

          Action:draft-patel-ecrit-sos-parameter-00.txt]

To: 'ECRIT' <ecrit@ietf.org>      =

Message-ID: <48CE0D9F.8080406@gmx.net>

Content-Type: = text/plain; charset=3DISO-8859-1; format=3Dflowed

 

Please take a = look at this document. Milan would like to hear some comments!

 

Ciao

Hannes

 

-------- Original = Message --------

Subject:       I-D Action:draft-patel-ecrit-sos-parameter-00.txt

Date: Fri, 12 Sep = 2008 09:45:01 -0700 (PDT)

From:           = Internet-Drafts@ietf.org

Reply-To:     internet-drafts@ietf.org

To: =     i-d-announce@ietf.org

 

 

 

A New = Internet-Draft is available from the on-line Internet-Drafts = directories.

 

          Title           : SOS = Uniform Resource Identifier (URI) parameter for marking of Session Initiation = Protocol (SIP) requests related to emergency = services

          Author(s)       : M. = Patel

          Filename        : draft-patel-ecrit-sos-parameter-00.txt

          Pages           : = 9

          Date            : 2008-09-12

 

This memo = describes requirements and protocol conventions for a new SIP (Session Initiation Protocol) URI parameter intended for marking SIP requests and responses = related to emergency services.  This proposal addresses issues that exist = in the current 3rd Generation Partnership Project IP Multimedia Subsystem (IMS) Emergency services solution, but is not precluded from being used by = other SIP-based emergency services solutions.  It is not intended as a replacement for the service URN.

 

A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-patel-ecrit-sos-para= meter-00.txt

 

Internet-Drafts = are also available by anonymous FTP at:

ftp://ftp.ietf.org/internet-= drafts/

 

Below is the data = which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the = Internet-Draft.

 

 

 

 

 

------_=_NextPart_001_01C92269.7AE74FCF-- --===============0077157299== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --===============0077157299==-- From ecrit-bounces@ietf.org Tue Sep 30 08:42:33 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B386B28C150; Tue, 30 Sep 2008 08:42:33 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB2443A6B98; Tue, 30 Sep 2008 08:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kusN+dq78ycD; Tue, 30 Sep 2008 08:42:28 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id D71F53A6B52; Tue, 30 Sep 2008 08:42:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,338,1220227200"; d="scan'208";a="165872499" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 30 Sep 2008 15:42:48 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m8UFgk0d032145; Tue, 30 Sep 2008 08:42:46 -0700 Received: from [192.168.0.101] ([10.21.118.216]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m8UFgjmT023556; Tue, 30 Sep 2008 15:42:45 GMT Message-Id: <9067906D-1AE1-464E-B505-BD5F59BB8AAA@cisco.com> From: Cullen Jennings To: SIP List , sipping , IETF AVT WG , ECRIT Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 30 Sep 2008 11:42:44 -0400 References: <552C9CF9-94FB-42D4-875F-0D2440951DCB@cisco.com> X-Mailer: Apple Mail (2.929.2) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2466; t=1222789366; x=1223653366; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Fwd=3A=20[RAI]=20Making=20RAI=20work=20better |Sender:=20; bh=9tL+bWl+KYrrdaQVh4dmslfCrKpV2xOONJjCzrp7prU=; b=JbJPAZKcPRXzgroCivEGZVeHgdBBrZXxMnunpf1M6BZvYoC3dcVd+PUMrW oowRVe+RqPTYi31JjYPNhvbrShuzifWjzuSBI2m59HIyHjEYJnmXWe8RsTgf Y5gAyYjRRX; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [Ecrit] Fwd: [RAI] Making RAI work better X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I'm sorry for the duplicate emails but just as a FYI ... I sent the following email to the rai@ietf.org list. If you want to reply, please do not reply to this email but go reply to the original on the rai list. Thanks Begin forwarded message: > From: Cullen Jennings > Date: September 30, 2008 11:37:29 AM EDT (CA) > To: rai@ietf.org > Subject: [RAI] Making RAI work better > > > Over the past year or so, Jon and I have heard concerns about the > efficiency and organization of the RAI Area. We have both observed > that > the larger working groups, particularly SIP and SIPPING, continue to > have difficulty tackling some of their more complex projects. The more > critical a document seems to be from a dependency perspective, the > more > late surprises seem to emerge in its development and the longer it > takes > to escape from the working group process. A relatively small number of > the working groups in the RAI Area seem to encompass the lion's > share of > our documents in their scope, which may concentrate too much of our > work > in too few areas and cause distracting parallelization. > > Ultimately, these problems might result from any number of causes. > There > might be structural problems with the manner the RAI Area is divided > into working groups, issues with chartering or focusing of the > efforts, > snarls intrinsic to the technology, personnel problems at any number > of levels, questions of participant energy, or any of a number of > combinations thereof. > > What we'd like to do is kick off a discussion about ways that we can > make RAI work better. As a part of that discussion we are reserving > one > of our precious timeslots for a RAI Area open meeting in Minneapolis > (at > least the Friday afternoon experiment will give us one more slot than > usual). In order to help set an agenda for that meeting, we'd like to > invite any comments and discussion on this list (rai@ietf.org), > or if necessarily in private correspondence to Jon and I. We're > interested to learn to what degree people believe there are problems > that need to be addressed, and what sorts of problems and potential > solutions the community can identify. > > Cullen Jennings > Jon Peterson > RAI Area Directors > _______________________________________________ > RAI mailing list > RAI@ietf.org > https://www.ietf.org/mailman/listinfo/rai _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit